Spelende kinderen ontdekken bug waarmee Linux Mint kon worden ontgrendeld

Linux Mint bevatte een kwetsbaarheid waarmee de schermvergrendeling kon worden omzeild. De kwetsbaarheid zat in de libcaribou-library in de Cinnamon-interface. Opvallend is dat de bug werd ontdekt nadat een paar kinderen ermee speelden.

Het issue staat beschreven in een bug report dat een gebruiker indiende. Hij vertelt hoe hij zijn kinderen zijn desktop probeerde te laten hacken en dat zij door op willekeurige plekken te tikken en te klikken plotseling het vergrendelscherm wisten te omzeilen. De gebruiker wist het probleem ook meerdere keren te reproduceren.

Uiteindelijk bleek het probleem in de libcaribou-library te zitten. Dat is het onderdeel in desktopinterface Cinnamon waar het virtuele toetsenbord mee wordt opgeroepen. Specifieker komt de bug voor als gebruikers de letter ē typen op dat toetsenbord. Als dat toetsenbord openstaat op het vergrendelscherm crasht dat scherm en kunnen gebruikers bij de desktop komen.

De bug ontstond nadat Mint vorig jaar een beveiligingsupdate doorvoerde. Sindsdien zijn alle versies van Linux Mint met Cinnamon 4.2 of hoger kwetsbaar. Inmiddels is er wel een patch beschikbaar.

Reacties (114)

Als het lockscherm crasht... dan ben je ingelogd in je sessie, dat klinkt toch niet zo heel erg als goed design. Er zijn vast meer manieren om dat scherm te laten crashen zou je denken.

Natuurlijk ben je op de achtergrond 'al ingelogd', maar naar mijn idee, wat er ook gebeurt met het lockscreen, de sessie zou niet actief moeten worden, tenzij dat expliciet door het lockscreen aangegeven is. iOS en Android hadden op vergelijkbare aparte wijze lockscreenbugs. Toch jammer dat daar nog niet echt iets voor gevonden is.

[Reactie gewijzigd door fapkonijntje op 20 januari 2021 13:03]

Het is een heel oud en bekend probleem. De marker van de oorspronkelijke XScreensaver heeft er ook wat over te zeggen: https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition/

Omdat nuance ook belangrijk is, hier is de reactie van een Linux Mint member in de PR: https://github.com/linuxm...54#issuecomment-762261555

Beetje een vreemde reactie die nogal naast de kwestie antwoordt:
"I wish JWZ had thought about a design that combined safety and a rich greeter, because at the time it would have provided a solution along with the warning."
Dat kan allemaal wel zijn, maar het feit blijft dat door die rich controls er per se in te willen steken, er een zware security bug erdoor ingeslopen is terwijl hij zeer duidelijk en expliciet daartegen heeft gewaarschuwd. En het ene weegt zwaarder dan het andere.
En verder heeft die reactie het ook vooral over light-locker en KDE, terwijl het eigenlijk over cinnamon-screensaver gaat.

[Reactie gewijzigd door Neverwinterx op 20 januari 2021 18:58]

Dus als ik het goed begrijp zou er een optie moeten zijn: simpel maar veilig en mooi maar onveilig? Klinkt als iets dat moet kunnen?

Dit zijn toch wel de comments waarvoor ik Tweakers lees 😉

Thanks! Fijn om deze reactie te lezen.

Jwz en nuance, dat zou dan voor de eerste keer zijn

Ik hou wel van zijn schrijfstijl.

Het probleem is vooral dat 99% van de login screens geen 'echte' login screens zijn. Windows doet precies hetzelfde merkte ik laatst, toen een YouTube video die ik open had staan bij een plotselinge reboot ineens weer begon te spelen nog voor ik ingelogd was.

De oplossing in dit geval zal een tweede proces zijn dat controleert of inloggen gelukt is, of het generiek afvangen van fouten als gevolg van child processes, maar ook dat is niet waterdicht.

Het gaat hier ook om lockscreens, niet loginscreens. Dus voor het vergrendelen van je apparaat, niet in/uitloggen.

Het scherm van Windows na een "shutdown" (soft shutdown staat default aan) is ook een lockscreen. Hij slaat namelijk je system state op en laadt die weer. Dit is overigens uit te zetten, maar dan ben je je snelle opstarttijd ook kwijt.

Dus jullie hebben allebei gelijk.

Ach snelle opstart tijd... Die hybrid fast boot heb ik ook uit en heb een (soft) boot time van 7.2 seconde.

Beetje BIOS optimizen en geen unnecessary junk inladen ;-)

Hangt sterk af van de specs van je hardware. Op mijn vaste PC thuis is het net zo snel, op mijn laptop van het werk scheelt het anderhalve minuut

Hangt sterk af van de specs van je hardware. Op mijn vaste PC thuis is het net zo snel, op mijn laptop van het werk scheelt het anderhalve minuut

Specs vast, maar waarschijnlijk hangt die werk-laptop ook nog in een domein, worden er policies geladen enzovoorts.

Met de systemen van tegenwoordig merk je amper verschil tussen snel en normaal opstarten bij een standaard kantoorwerkplek.

Haha grappig, het is echt niet zo snel. Ik kom dit dagelijks tegen. als je Soft shutdown uitzet gaan de meeste (SSD) werkplekken van 10 seconden naar anderhalve minuut ofzo. En dat merkt de klant echt wel.
Ik heb een redelijk nieuwe standaard HP Probook, en daar is het ook echt een stuk langer qua opstarttijd.

Nou, in mijn lokale bibliotheek duurt het anders behoorlijk lang voordat hun Windows 10-pc's zijn opgestart en dat zijn toch nog niet zulke oude nuc's (2019)...

dat zegt meer over de manier waarop de werkplek is ingericht (of juist het gebrek eraan )

@dasiro wat zou jij dan veranderen aan die werkplek?

hangt van de omgeving af, daar kan je zo geen uitspraken over doen

Ik bedoel dat ze voor mijn eigen gebruik snel genoeg opstarten zonder de snelstartfunctie. Ik heb meer baat bij afsluiten is daadwerkelijk uit dan bij een opstarttijd <10 seconden.

Dit is in de meeste gevallen gewoon één scherm, of je nou ingelogd bent of niet. Als het goed is vraagt je lockscreen ook om opnieuw je wachtwoord in te voeren.

Beide zijn gewoon een scherm dat fullscreen opent over wat er ook open staat, doorvoer van input naar andere software blokkeert, en als het goed is zorgt dat niemand zomaar je apparaat kan gaan gebruiken.

Het gaat niet om het scherm zelf gelijk is aan login of lock of whatever, maar als je niet ingelogd bent en je crasht een loginscreen dan is er erg weinig aan de hand, want je authenticatie heeft niet plaatsgevonden. Ben je wel ingelogd en crash je het lockscreen, dan verwacht ik geen toegang tot een desktop/startscherm. Dat is bij iOS/Android en Linux duidelijk wel het geval. Pijnlijke ontwerpfout wat mij betreft.

Ik weet niet of dat bij Windows beter/anders is, maar die heeft voor zover ik weet nog nooit een bypass voor de lockscreens gehad.

https://i.imgur.com/rG0p0b2.gif

Windows 95 had een Network authenticatie scherm, zonder kon je gewoon op de pc zonder netwerk. Dit is ook zoals het bedoeld was en geen bypass. je had wel tools omdat te voorkomen.

Dat is het nadeel van een gifje zonder context. Dat staat er niet bij.

Ik weet niet of dat bij Windows beter/anders is, maar die heeft voor zover ik weet nog nooit een bypass voor de lockscreens gehad.

Zeker wel. Een vriend van mij heeft in een ver verleden eens een migratie uitgevoerd van Windows 2000 naar Windows XP. Daarbij is hij aardig diep in het systeem gedoken en zo kwam hij achter een methode om gebruikersapplicaties zoals Internet Explorer op zowel het inlogscherm als het lockscreen te laten verschijnen, in het eerste geval zelfs zonder dat er een gebruiker was ingelogd.

Zolang je lockscreen of loginscreen een userspace proces is blijf je het probleem houden dat in deze blogpost wordt beschreven, ook al gelinkt door @elmuerte

Dat wat jij omschrijft is iets heel anders dan een lockscreen bypass naar een ingelogde gebruiker. Een applicatie kunnen starten over je lockscreen heen, kan nu ookal. Het schermtoetsenbord is bijvoorbeeld zoiets. Maar via dat schermtoetsenbord kom je niet bij gebruikersgegevens en ben je ook niet ingelogd als gebruiker. Misschien is het vergelijken met software uit 2001, 20 jaar geleden dus, ook een beetje vergezocht.

Echt wel, hahaha, vroeger kon je via de help doorklikken tot je in een explorer kwam zonder ingelogd te zijn. Kon je gewoon het wachtwoord verwijderen of waar je zin in had. Was wel 2004 toen ...

1998. Volgens mij lukte dit in Windows XP al niet meer.

Niet alle computers waren up-to-date op scholen

Ik weet niet of dat bij Windows beter/anders is, maar die heeft voor zover ik weet nog nooit een bypass voor de lockscreens gehad.

Het is wel heeel lang geleden, maar ooit kon ik Windows systemen hacken op de volgende manier:
- selecteer op het wachtwoordscherm een stukje tekst
- kies uit het rechter muisknop menu voor "Print"
- klik in de print dialoog op "Help"
- klik in het Help scherm op File -> openen
- blader naar de windows map en open explorer.exe
- start vanuit explorer als wat je wil

Toegegeven, dat was nog in de vorige eeuw en is vast niet representatief voor een modern Windows systeem, maar het was een mooi moment voor een oorlogsverhaal (Om het af te maken: de beheerder heeft het "opgelost" door het draadje van de rechter muisknop door te knippen. Dat hield deze toetsenbordheld uiteraard niet lang tegen want CTRL+P werkt ook )

[Reactie gewijzigd door CAPSLOCK2000 op 20 januari 2021 16:22]

(Om het af te maken: de beheerder heeft het "opgelost" door het draadje van de rechter muisknop door te knippen. Dat hield deze toetsenbordheld uiteraard niet lang tegen want CTRL+P werkt ook )

Dan ofwel de P-toets ofwel de <CRTL>-toets blokkeren, dat wordt handig voor de receptioniste, er kunnen geen brieven meer geschreven worden met een P- er in (Meneer Pietersen krijgt nooit te horen waarom hij geen klant mag worden) en een ontbrekende <CRTL>-toets heeft ook nogal wat bijwerkingen.

En dan nog, gaan mensen misschien een eigen muis of toetsenbord meenemen.

Ik weet niet of het bij iOS nog steeds zo is, aangezien de secure Enclave tegenwoordig alles lockt, en de FBI/CIA nog steeds Apple proberen te overtuigen om een backdoor in te bouwen.
Maar als het net als OS X werkt (waar iOS op is gebaseerd), dan is het tegeonwoordig wel meer een login screen dan lockscreen.

Het is bij Windows niet heel veel beter, alleen is er minder goede documentatie over. Zo kwam er heel toevallig vorige week een blogpost van iemand met een zeer interessante methode (inmiddels al een half jaar gepatched) om het login screen te bypassen die toevallig ook werkt op systemen met passwordless/TPM-only Bitlocker Device Encryption.

Het is wel een andere klasse dan dit soort exploits waarbij de greeter ook het lockscreen is en een crash van het ene het andere wegvaagt, maar er is nog steeds veel te veel vertrouwen tussen de onderdelen.

Dat het hetzelfde eruit ziet betekent niet dat het functioneel hetzelfde doet of zou moeten doen. Dat is wel het argument wat je hier maakt.

Het gaat hier ook om lockscreens, niet loginscreens. Dus voor het vergrendelen van je apparaat, niet in/uitloggen.

Bij een reboot zou het toch een volledig login-scherm moeten zijn, dan is ook dit weer een punt waarop Windows design meer flawed is dan een Linux-distro.

@StackMySwitchUp bij een reboot zou het geen soft shutdown moeten zijn.

Dit is wel typisch een Windows 10 dingetje. Die laat de laatst ingelogde gebruiker automatisch weer inloggen om eventuele Windows Updates af te kunnen ronden. Je kunt die optie overigens (per gebruiker) uitschakelen. Ga naar Instellingen -> Accounts en klik dan aan de linkerkant op Aanmeldingsopties. Dan zie je rechts ergens onderin een schakelaartje "Configuratie van mijn apparaat automatisch voltooien op basis van mijn aanmeldingsgegevens na een update of herstart.".

Ik heb dit uitgeschakeld omdat als je de pc aanzet en je wederhelft was als laatste aangemeld je bij het uitzetten van je pc de melding krijgt "Er zijn nog andere gebruikers ingelogd". Terwijl dat natuurlijk onzin was.

Dank je, dit kan wel eens helpen met mijn probleem thuis.

Om een of andee reden starten enkele van mijn computers spontaan weer op na een shutdown. Volledig uit, wacht 10-20 seconden en de computer start weer op. Bij het afsluiten komt de melding dat er nog een gebruiker is ingelogd

Die melding is er altijd. Voor snel wisselen tussen users, syncen van OneDrive etc. logt Windows op een beperkte manier een sessie tegenwoordig gewoon in. Hierdoor krijg je altijd die melding.

Maar jouw probleem met reboot heeft met andere zaken te maken. Klinkt als een BSOD of een hardware issue bij shutdown. Kan een probleem met het moederbord zijn bijvoorbeeld. Het eerste wat ik aan zou raden is fast startup uitschakelen, mogelijk helpt dat.

Een shutdown logt jou niet uit Windows.
Als je dat wil voorkomen dan zou je dus eerst moeten uitloggen en daarna een shutdown moeten doen.
Het valt ook gemakkelijk te zien als er meerdere accounts op een computer gebruikt worden. Als een gebruiker een shutdown doet en een andere gebruiker de computer opstart en inlogt dan zal deze een waarschuwing krijgen dat er nog een gebruiker is ingelogd als hij een shutdown doet.

[Reactie gewijzigd door Pim_t op 20 januari 2021 13:27]

Een shutdown logt jou niet uit Windows.

Wel als je dat gewoon instelt, dat maakt je workaround onnodig.

Ja, soms zelfs na een shutdown openen mijn browsers/apps zichzelf weer. Echt ** irritant.

Dan zet je dat uit. Is gewoon een vinkje/schuifje onder Aanmeldingsopties in Windows 10.

Voor jou irritant, voor mij noodzaak. Verschillende gebruikers, verschillende wensen

Windows doet precies hetzelfde merkte ik laatst,

Windows heeft het volgens mij een stuk beter geregeld.. het is wel zo dat tegenwoordig de sessie automatisch herstart wordt voordat je zelf inlogd.

Wat ik ook wel eens heb in Windows, is dat wanneer ik mijn systeem uit power save mode haal, waarbij vooral het scherm uitgeschakeld is en mijn desktop gelockt was vóór power save, dat ik dan in een fractie van een seconde wel mijn complete desktop te zien krijg. Dit wordt direct gevolgd door de verwachtte desktop-lock scherm van Windows. Ik krijg het niet iedere keer gereproduceerd, maar het dit wel al diverse keren waar genomen. Lijkt dus erop dat wanneer je het lock screen onder windows kunt laten crashen, je wellicht ook in een ontgrendelde omgeving bevind.

Dat zou nog wel eens kunnen komen door dat Windows ingesteld heb dat wie er laatst ingelogd is dat die account tijdens het opstarten van Windows al inlog, zodat je sneller in Windows zit. Je merkt het heel snel als voordat je aanmeld de computer te herstarten. Dan krijg je de melding dat er nog iemand is aangemeld. Dit kan je ook uitzetten.

Maar of dat Windows op die manier werkt, zou ik niet weten. Maar wat je ervaren heb is dat je account al inlog voordat je zelf echt aangemeld heb denk ik.

Is dat niet gewoon een Windows feature, het laten doorgaan van multimedia wanneer het scherm locked is.
Zit ergens in de instellingen.

Het was na een volledige reboot, waarbij je dus meteen ingelogd wordt op de achtergrond en een lock screen te zien krijgt

Ook dat is toch een instelbare keuze.
Uitloggen bij reboot.

Bij Windows is het wel iets anders. Als winlogon.exe crasht wordt vanwege de veiligheid je systeem afgesloten.

Bij windows is dit overigens een instelling, of je windows je programma’s na een reboot zover mogelijk al wilt laten opstarten voordat je bent ingelogd.

Daar is iets voor, het noemt uitloggen

Het is sneller als er al wat zaken op starten voordat je ingelogd bent.

Als het een fysieke machine is kan je Linux Mint lokaal gewoon rebooten, de boot loader bash laten openen en jezelf toegang tot root verschaffen door een nieuw wachtwoord in te stellen voor root.

Linux is best veilig, maar het beveiligingsmodel gaat er vanuit dat de persoon met toegang tot de hardware, ook de eigenaar is:

args="ro resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.luks.uuid=luks-93b1a572-00d4-4a13-a5d8-40bcd4af29a1 rd.lvm.lv=fedora/swap rhgb quiet rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1 systemd.unified_cgroup_hierarchy=0 1"

Die 1 is een shortcut voor systemd.unit=single-user.target en daarmee boot je meteen als Root. Het enige wat een Linux computer daartegen kan beschermen, is full-disk encryptie.

Wat ook nog alarmbellen zou kunnen doen rinkelen, is SELinux. Als je via 'creatieve' manieren aanpassingen maakt aan het systeem en je update de SELinux caches niet goed, dan gaat hij alarm slaan en vraagt hij je of alles geherindexeerd moet worden.

[Reactie gewijzigd door Eonfge op 20 januari 2021 16:04]

Full-disk encryptie is tegenwoordig niet extreem lastig meer (sterker nog de Ubuntu grafische installer geeft die optie) Daarnaast wat betreft SElinux/APParmor staat of valt dat toch wel bij de gebruiker. Legio beheerders en gebruikers die denken: "wat vervelend" en het gewoon uitzetten of op permissive mode zetten.

Toegegeven echt correct SElinux inregelen is ook vrij lastig. Vooral als je ergens een keer een foutje hebt gemaakt maar niet meer weet waar...

kleine nuance, de standaard ubuntu optie is GEEN full-disk encryptie. Je home directory is dan encrypted. Full-disk kan zeker en is ook geen rocket science, maar is niet hetgeen wat in de installer zit.

Zeker wel. Sinds (tenminste) 18.04 zit dit ingebouwd in de grafische installer.

screenshotje van installer
https://onlinehelp.opswat...image-20200103-075459.png

full-disk encryptie met uitzondering van de /boot partitie (heel technisch gesproken dus full partition encryption.)

[Reactie gewijzigd door coolkil op 21 januari 2021 11:01]

full-disk encryptie met uitzondering van de /boot partitie (heel technisch gesproken dus full partition encryption.)

Dit gedeelte is idd correct en zoals ik zei dus geen full-disk encryption.

Hier nog verdere uitleg: https://superuser.com/que...0/ubuntu-20-04-encryption

Screenshot heeft hier verder weinig invloed op

je versleuteld wel je complete Linux installatie. dus het is wel degelijk meer dan homedirectory encryptie

dat laatste gedeelte de initrd en kernel in /boot kan je ook niet echt gemakkelijke encrypten en inderdaad alleen signen met secure boot. maar das geen encryptie

zolang je dat niet hebt zou een aanvaller een geïnfecteerde initrd kunnen laden en daar schade kunnen aanrichten.

[Reactie gewijzigd door coolkil op 21 januari 2021 22:47]

Stukje over de home directory was door de snelheid wat snel getikt. Doel wat ik wou zeggen is dat het een deel is en niet de hele disk en dat is hoe je het ook draait geen full-disk encryption. Wat uiteindelijk het punt is waar ik op reageerde.

dat laatste gedeelte de initrd en kernel in /boot kan je ook niet echt gemakkelijke encrypten en inderdaad alleen signen met secure boot. maar das geen encryptie

Gemakkelijk is natuurlijk subjectief, maar als je even doorklikt in de eerdere link die ik stuurde vind je deze:
https://help.ubuntu.com/c...isk_Encryption_Howto_2019

Keurige uitleg hoe je daadwerkelijk full-disk encryption kan krijgen. Of je dat verder makkelijk vindt is aan jou.

kijk zo leer je nog eens wat. niet extreem lastig maar ik vraag me wel af of het echt daadwerkelijk iets brengt. je doet dit om te voorkomen dat wanneer je laptop gestolen wordt de dieven de data kunnen lezen. daarvoor maakt de /boot partitie weinig uit. kwestie van keuzes maken. thnx voor de discussie!

Arg editing is in zowel Grub als systemd-boot uit te zetten, hoewel het in veel distros inderdaad by default aanstaat

Zolang je niet je /home/ partitie encrypted hebt kan dat met de meeste linux distro's wel. Is wel weer een stukje ingewikkelder. Bovendien is dat toch weer wat anders dan bij een actieve open sessie kunnen, waar iemand wellicht gevoelige info open heeft staan.

Dat soort attacks echt goed dichttimmeren kan alleen als je met secureboot alles goed dicht zet. En gezien de puinhoop die EFI is is het meestal niet triviaal om het echt goed dicht te krijgen.

/home encrypteren gaat hier niets aan veranderen. Aangezien je init (/bin/bash) hier toch op een ander ongeencrypteerd filesystem staat (/ of /bin). Je kan die andere filesystems natuurlijk ook encrypteren maar je kernel, initrd indien nodig en bootloader moeten uiteraard wel leesbaar blijven tijdens opstart (aparte /boot).

je veranderd niks aan de mogelijkheid om het wachtwoord te wijzigen maar het encrypten van je /home maakt het wel onmogelijk voor een aanvaller om dan je gegevens te roven.

Daarnaast kan je tegenwoordig ook gewoon de hele schijf versleutelen en tijdens opstarten laten vragen om het decryptie password. Daarmee fix je ook gelijk het 'security issue' wat @Cobalt beschrijft.

je veranderd niks aan de mogelijkheid om het wachtwoord te wijzigen maar het encrypten van je /home maakt het wel onmogelijk voor een aanvaller om dan je gegevens te roven.

Inderdaad, maar je kan een trojan user account toevoegen (met sudo privileges indien nodig) waarmee je dan later ingelogd en /home mee besnuffelt.

Daarnaast kan je tegenwoordig ook gewoon de hele schijf versleutelen en tijdens opstarten laten vragen om het decryptie password. Daarmee fix je ook gelijk het 'security issue' wat @Cobalt beschrijft.

Is dat dan met een aparte ongeencrypteerde /boot, een specifieke bootloader op de bootsector van een filesystem/hd of een apart boot device (usb key) ?

Persoonlijk ben ik nooit overtuigd geweest van de voordelen van schijf encryptie tov de vele nadelen, zeker op desktops of servers. Je kan niet of niet ten volle genieten van veel features van zeg maar ZFS op LUKS of WHATEVERFS over LUKS over ZFS (zvol) erover gesmeten (snapshots, compression, dedup, decent performance, ...). En het is nog de vraag of wanneer het fout gaat of dit nog herstelbaar wordt.

Alleen de boot partitie is onversleuteld en zodra het systeem verder opgestart wordt wordt om een password gevraagd. Ongeacht of je in single user mode start of niet. Ofwel alle data is onleesbaar.

Je kan de luks headers keurig backuppen en eventueel recoveren zodra je luks gefixt heb mag je de rest van de partities herstellen. In de jaren dat ik het gebruikt heb is het me echter nog nooit overkomen dat er een luks partitie kapot ging.

Performance hit is tegenwoordig nihil vanwege ingebouwde hardware acceleratie voor crypto

Daarnaast zodra je decrypt heb werken alle features van je bovenliggende filesysteem bij mijn weten. Bij lvm in ieder geval wel. Zfs heb ik dan weer geen ervaring mee

[Reactie gewijzigd door coolkil op 20 januari 2021 23:52]

Deze bug zit in de Cinnamon desktop omgeving die van Linux Mint komt. Het probleem doet zich niet alleen bij LM voor, zoals te zien is in het bug report. De melder draait Fedora en geen LM.

Lijkt me een kwalijke zaak dat een crashend lockscreen de desktop onthult.

Als het lockscreen per se een apart proces moet zijn, moet de desktop daarvan afhankelijk zijn. Maw, als het lockscreent crasht, moet de desktop ook crashen.

Hoe lang heeft het geduurd voordat dit gepatcht was? Dat lijkt me toch ook relevante informatie.

23 dagen geleden inderdaad gemeld zoals @bytemaster460 al aangaf, maar 7 dagen geleden is dit al gepatcht.
Dus 16 dagen

https://github.com/linuxm...54#issuecomment-759431797

De bug is 23 dagen geleden aangemaakt.

Het probleem is hier dat als het lock screen crasht, je gewoon terug bij de desktop komt. Dat is slecht software design.

Ik ben er zelf tevens ook al meerdere malen in geslaagd Linux Mint op deze manier te ontgrendelen. Deze (of een soortgelijke) bug is al minstens 6 jaar aanwezig.

[Reactie gewijzigd door RobinJ1995 op 20 januari 2021 13:18]

Helaas zit Linux er vol mee.
Het open source idee is leuk, maar het maakt het wel zo dat er teveel persoonlijke dingen prioriteit krijgen ipv dat er op de bigger picture wordt gelet.
Tel daarbij op dat bijna elk onderdeel weer door aparte groepen of zelfs individuen worden ontwikkeld, en het resultaat is iets waar zulk soort bugs helaas heel veel voorkomen.
In veel gevallen zijn ze al jaren bekend, maar vind men simpelweg het niet nodig om het te patchen.

Het tegenovergestelde gebeurt ook vaak. Dat bepaalde onderdelen prima werken, maar hier en daar wat kleine bugs vertonen. Besluit men ineens om het dan maar helemaal weg te slopen.

Niet voller of minder vol dan Windows en MacOS. Waar was je toen je op MacOS root-toegang kon krijgen zonder een wachtwoord in te typen, of het wachtwoord van geëncypteerde volumes opgeslagen werdt in het password hint veld? Was het toen ook de schuld van open-source (wat MacOS helemaal niet is)?

Fouten gebeuren, het enige nadeel dat open-source heeft is dat ze die problemen niet zoals grote bedrijven stilletjes onder de mat kunnen schuiven.

ik durf toch wel te zeggen dat een Linux machine in een groot gedeelte van de gevallen veiliger is dan Windows.

Ik ook, hoe kom je erbij dat ik dat niet denk?

ik meende een bepaalde negatieve houding jegens Linux/opensource op security gebiedt te lezen. mocht dat niet het geval zijn excuses.

[Reactie gewijzigd door coolkil op 20 januari 2021 16:03]

Hoezo excuses? Hij hakt duidelijk op Open Source in, in zijn algemeenheid. Je moet het vergelijken met het iets anders (als je 't nergens mee vergelijkt, dan heeft het hele verhaal van B_Force weinig zin); dus Closed Source. Het lijkt mij vrij duidelijk dat je dan inderdaad vnl. op Linux vs. Windows uitkomt.

dit lijkt mij ook. het is niet zo gek dat het mogelijk is om expres en onderdeel van het OS te laten crashen, daar kan je zelfs als ontwikkelaar vrij weinig tegen doen. het is vooral belangrijk hoe zo'n crash dan afgevangen wordt.

in dit geval zit daar dus het grootste probleem. van een beveiligingsperspectief is dit ontwerp natuurlijk compleet idioot.

Slecht software design of niet, het is zoals het vroeger werkte. Andere optie was er niet met X. X zelf doet geen screen locking dus ben je afhankelijk van een overlay-programma. Als je kijkt naar XScreensaver is dat niet anders. Verschil is dat XScreensaver z'n lockscreen met alleen Xlib heeft gebouwd, om zo weinig mogelijk afhankelijk van externe libraries met mogelijke bugs te zijn.

GNOME heeft het lockscreen inmiddels in gnome-shell geïmplementeerd, gnome-screensaver wordt niet meer gebruikt. Als je dan je lockscreen laat crashen is je shell en je sessie dood en sta je weer op het loginscherm. Maar ook gnome-shell heeft naar mijn weten wel bugs gehad waarmee je het lockscreen kon omzeilen.
Cinnamon is een fork van GNOME. Zo nu en dan integreren ze wat wijzigingen uit GNOME in Cinnamon, maar meestal duurt dat even of gebeurt dat helemaal niet omdat ze het niet eens zijn met keuzes in GNOME.

War ik me afvraag, of zo'n screenlocker als process met een child process geïmplementeerd kan worden. De fancy dingen stop je in het subprocess, en als die crashed start het parent process gewoon een nieuw subprocess op.

Typische ‘fuzzing’ attack!

https://en.m.wikipedia.org/wiki/Fuzzing

[Reactie gewijzigd door Keypunchie op 20 januari 2021 13:01]

Fuzzing or fuzz testing is an automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program.

Sinds wanneer valt de inzet van kinderen onder geautomatiseerd werk? dan zouden er heel wat mensen botten in WoW

Normaal gesproken zit er enige coördinatie in een fuzzing aanval. In dit geval was die coördinatie basaal te noemen.

[Reactie gewijzigd door Jerie op 20 januari 2021 13:36]

Ik denk dat het enigszins grappig bedoeld was.

Ook nog wellicht interessant context: dit soort problemen komen wel vaker voor. De maker van xscreensaver heeft vanwege deze bug een blog geschreven (met verwijzingen naar andere gevallen) hoe dit kan gebeuren, en dat dit soort bugs precies de reden zijn dat hij geen UI toolkit integratie heeft.

Ook nog wellicht interessant context: dit soort problemen komen wel vaker voor. De maker van xscreensaver heeft vanwege deze bug een blog geschreven (met verwijzingen naar andere gevallen) hoe dit kan gebeuren, en dat dit soort bugs precies de reden zijn dat hij geen UI toolkit integratie heeft.

Ik kan me ook herinneren dat eind jaren 90 er op de Sun Unix workstations met Solaris ook een dergelijke bug zat in de 'xlock' utility, dus het is echt werkelijk van alle tijden . Wanneer er een stuk tekst in de mouse-copy buffer zat kon je dat met de middelste muisknop pasten, en als je dan snel heel veel op de middelste knop klikte crashte de locking tool. Waarschijnlijk een buffer overflow van het password veld... niet veel later was de bug gefixed. Maar indertijd was het wel handig als iemand weer eens een workstation had gelocked in een volle computerzaal op de Universiteit...

Maar indertijd was het wel handig als iemand weer eens een workstation had gelocked in een volle computerzaal op de Universiteit...

Hehehe dat herken ik. Ik heb zelf 9 jaar lang PC klassen mogen proberen te onderhouden en op het einde van de dag was je al blij als ze hun etensresten in de vuilnisbak smeten. De slordigheid van andere (studenten) en een opgelegde laisse-faire attitude dwingden ons tot hele discutabele compromissen.

Ik meen mij ook te herrineren dat Windows problemen had met copy-paste omdat zij programmatisch de paste buffers niet kunnen weigeren. Dit leidde destijds tot een hele klasse van aanvallen (shatter attacks) waarme gepoogd werd om processen draaiende met hogere privileges (mcafee virus scanner bv) te injecteren met user supplied code in een copy-paste buffer.

Gelijkaardige problemen manifesteren zich ook op een Linux GUI desktop, dat nooit echt veilig kan zijn. Iedere X applicatie kan immers communiceren met andere X applicaties onder dezelfde server. Maakt niet uit of de processen onder verschillende accounts draaien (https://theinvisiblething...cus-on-gui-isolation.html).

Krijgen die kinderen nu ook een leuke Bug Bounty uitgekeerd

Ze kunnen een lekkere Bounty krijgen.

Ah een analoge fuzzer