'Zelf compileren Linux-kernel maakt kwetsbaar'

Op de Bugtrac-mailinglijst is een door zijn trivialiteit tamelijk opvallende kwetsbaarheid van bepaalde Linux-systemen aan de kaak gesteld. Ene 'Hadmut' legt op de lijst uit dat de sourcecode van versie 2.6.17.11 van de standaardkernel, zoals die door kernel.org wordt verspreid, niet minder dan 19.554 bestanden en 1201 folders bevat die 'world writable' zijn. Dat wil zeggen dat iedereen met toegang tot een systeem deze bestanden kan aanpassen of nieuwe bestanden op het systeem kan plaatsen. Bij de eerstvolgende compilatie van de kernel kunnen zo hele hordes malware aan het systeem worden toegevoegd. Uiteraard moet een aanvaller wel eerst 'eventjes' schrijftoegang op een systeem krijgen, maar daarvoor is een lek in een willekeurig php-script soms al voldoende. Ook andere versies van de archiefbestanden op kernel.org zouden met het probleem te maken hebben.

Een gebruiker die zelf zijn kernel op basis van de vanilla-code bouwt, haalt met die code dus een flink beveiligingsgat in huis. Hoewel het probleem door de zelfcompileerder met een paar korte statements op te lossen is, hoort dit probleem natuurlijk door de kernelmaintainers te worden opgelost. In hoeverre de 'world writable'-fout grote impact zal hebben is niet te zeggen. De meeste distro's zullen niet snel van een zelfgebouwde kernel worden voorzien; de standaardkernel voldoet in veel gevallen namelijk prima. Een korte controle leert verder dat ook de sourcecode die bij bijvoorbeeld Debian en Gentoo wordt meegeleverd, keurig is afgeschermd tegen zulk misbruik. Toch zullen er heel wat serversbeheerders en hobbyisten met de 'open' bestanden aan de slag zijn gegaan, en zal er dezer dagen daarom driftig gegrept moeten worden: deze source zal zelfs door de meest fanatieke openbronliefhebber als té open worden beschouwd.

Reacties (93)

[Tuxie]

Ik vind dit hele nieuwsbericht een beetje overdreven. Goed, het is een slordigheidje maar wie heeft er nu vanilla kernel sources met de hele gcc mikmak op een productie machine staan? De hele conclusie dat Linux nu opeens 'kwetsbaar' is zwaar overdreven, dat zou pas zijn als er een dikke bug in de kernel-code zelf staat die geexploit kan worden.
Je bent immers zelf verantwoordelijk voor de rechtenstructuur op je systeem en onder welke gebruikersnaam je kernel sources uitpakt. Dat ligt niet aan Linux....

[Olaf van der Spek]

als jij een serverpark met 40 servers hebt die op gentoo draaien, installeer je niet ff snel op alle 40 servers een openssl update oid.

Waarom niet?

[Sfynx]

Het is al even geleden dat ik gentoo heb gebruikt, maar destijds kon je met de -B optie van emerge een binary package maken die je vervolgens kan distribueren naar andere machines... voor het geval je niet de boel overal wil compileren (wat bij openssl nauwelijks tijd kost met een beetje recente machine).

[Jungian]

@Jan de Groot

Heel simpel. Je laat 1 systeem compileren voor de rest.
En als je echt een ¨stoere provider¨ bent die Gentoo gebruikt, gebruik je gentoo-sources ipv vanilla-sources.

[Verwijderd]

Het probleem bestaat, maar de diagnose is verkeerd. Het is geen Linux probleem, maar een probleem van roekeloze beheerders.

[Verwijderd]

Het komt allemaal neer op een gebruikersfout, niet op een fout die in Linux zit. Zolang je het gewoon niet uitpakt als root dan heb je idd nergens last van. Dit heet "onbekendheid" met het systeem, anders kan het niet voorkomen.

Of het nou Linux is, Windows, HP-UX, FreeBSD. Zolang je een OS niet goed genoeg kent dan heb je kans op dit soort misconfiguraties.

Ik vind het wel slecht van de Tnet redactie dat ze Linux zo zwart maken, ze moeten eens wat verder kijken dan meteen Linux de grond in stampen. Whoo Windows 2000 draait standaard met de Windows directory volledig open, komop, plaats dat ook even op Tnet dan?

[edit] Waarom flame? Ik ben gewoon van mening dat tnet iets objectiever had mogen zijn.

[Verwijderd]

Gelukkig worden we allemaal als expert geboren en komen dit soort fouten in de praktijk nooit voor...

[Verwijderd]

Elke kernel komt nou eenmaal met te veel nieuwe documentatie/changelogs, om alles nauwkeurig door te lezen... Tot op een bepaald moment was dit probleem er niet, daarna is het ontstaan.

[Verwijderd]

Over Windows wordt al zoveel negatiefs gezegd..
Tja en Linux.. tis *nix en het blijft *nix..

[Verwijderd]

Ik vind het wel slecht van de Tnet redactie dat ze Linux zo zwart maken, ze moeten eens wat verder kijken dan meteen Linux de grond in stampen.

Je wilt juist dat ze objectief zijn... Nou, dat is dit artikel, het is een reeel probleem bij het zelf downloaden, extracten en compileren van een kernel.

Het is sowieso een reeel probleem dat je kans hebt op misconfiguraties bij onvoldoende kennis, zoals je zelf ook al aangeeft.
Maar wat je even over het hoofd ziet, is dat *juist daarom* de software zodanig ontworpen moet worden dat een gebruiker zo min mogelijk fouten kan maken. Secure-by-default en dergelijke. Stel dat de kernel-bestanden helemaal geen rechten hadden, en dat je ze specifiek readable zou moeten maken om ze uberhaupt te kunnen gebruiken, dan zou je de gebruiker al dwingen (weliswaar op een nogal Spartaanse manier) om na te denken.
Het is algemeen bekend dat mensen niet altijd overal aan denken en fouten maken. Probeer dit dan uit te sluiten in je ontwerp.
Naar mijn mening is iets pas een gebruikersfout als de software de gebruiker gewaarschuwd heeft voor een potentieel probleem, en de gebruiker alsnog de verkeerde beslissing heeft genomen. Als je de gebruiker allerlei gevaarlijke dingen laat doen, zonder enige confirmatie of waarschuwing, dan faalt het ontwerp, niet de gebruiker.

[LauPro]

Beetje discutabel natuurlijk. Als het zo is dat sommige files standaard world-writable zijn dan is dat niet goed. Echter lijkt het me dat als je bijv. /usr/src/linux gewoon alleen schrijf-/leesbaar maakt voor root+de admin groep er geen mensen meer bij kunnen ook al zijn alle onderliggende files 777.

Daarnaast draait Apache (en dus php) natuurlijk niet onder de root-user maar onder een web-user (oid). Deze webuser mag natuurlijk ten alle tijden nooit toegang hebben tot belangrijke libs/includes.

Overigens zijn de vanilla-sources volgens mij ook niet echt bedoeld voor productieomgevingen. Maar meer voor developers en mensen die ermee willen testen. In de vanilla sources komen praktisch alle sources bijeen die men uit de normale 'linux-sources' weert (bijv. ReiserFS4 ivm codingstyle).

[_JGC_]

De rechten zijn niet recursief. Als je een directory niet binnenkomt is het helemaal niet erg of alles eronder 777 is. Probleem met de kernel source is echter dat /usr/src/linux over het algemeen gewoon 755 is, waardoor alle gebruikers op het systeem die map kunnen lezen, en dus ook de schrijfbare bestanden kunnen overschrijven.

Zelf gebruik ik ook custom kernels op produktiemachines, maar daar zijn absoluut geen kwetsbaarheden aan verbonden: over het algemeen gebruik ik de linux-source-2.6.x pakketjes van debian en bak ik die op een machine die vanbuitenaf niet te bereiken is. Je bent gewoon stom bezig als je kernels zit te compileren op je produktieserver als er een andere machine aanwezig is (in dit geval een afdankserver) die het ook kan doen.

[The - DDD]

Nu is de 755 op /usr/src/linux geen probleem. Het kan namelijk erg nuttig zijn om, ook als non-root user, de gebruikte broncode in te kunnen zien. Zal niet snel gebeuren lijkt mij. En op high security systemen zou je de broncode wel achter 700-root weg moeten zetten lijkt me.

[d3vlin]

Het is dan ook prima mogelijk om heel de kernel sources world readable te houden zonder dat de gemiddelde gebruiker iets kan wijzigen aan de source? (chmod -R o=rx /usr/src/linux)

[mxcreep]

Ik zou niet weten waarom je die sourcecode uberhaupt zou laten staan dan als het zo'n probleem is...
Kernel bakken en rotzooi opruimen, evt archiveren...

Overigens heb ik zelf de werkwijze, niet met kernels aangezien voor mij de standaard kernels prima werken, om van software die ik op meer machines gebruik eenmalige een compile te doen en er een package van te maken.
Die voeg ik vervolgens weer toe aan de lokale yum repository die we gebruiken (een mirror van de CentOS repository + eigen packages). Wel zo makkelijk met updaten...scheelt bakken werk.
Compilen gebeurt dan op een aparte machine die verder niets zinnigs te doen heeft. Dat heeft tevens als voordeel dat machines die al behoorlijk druk zijn ook niet nog eens lastig gevallen worden met forse compiles.

[Verwijderd]

Juist, alleen de .config bewaren, natuurlijk zet je die in /boot en tegenwoordig kan deze al gegenereerd worden met de boot, snap het probleem ook niet zo.

[webkiller71]

@d3vlin
zou het niet beter zijn om chmod -R o=-w /usr/src/linux te gebruiken? Je wil niet dat al je bestanden daarin ineens executable worden.

[Randal Peelen]

Echter lijkt het me dat als je bijv. /usr/src/linux gewoon alleen schrijf-/leesbaar maakt voor root+de admin groep er geen mensen meer bij kunnen ook al zijn alle onderliggende files 777

Dat is niet waar. Als je een map hebt waar niemand in mag schrijven, met daarin een file die world-writable is (zogenaamd '777' ge-chmod), dan kan iedereen die file gewoon aanpassen en executen.

Daarnaast draait Apache (en dus php) natuurlijk niet onder de root-user maar onder een web-user (oid). Deze webuser mag natuurlijk ten alle tijden nooit toegang hebben tot belangrijke libs/includes.

Ook niet aan de orde dus, want zolang apache als _een_ user draait, kunnen al zijn commandos op de world-writable files worden toegepast. Dus een goed gescript commandotje via een php injectie en je kunt de kernelsource in theorie aanpassen.

En voor de mensen die niet zozeer het gevaar inzien van het kunnen wijzigen van kernel sources: het gaat er natuurlijk om dat als jij een kernel compileert die, zonder dat je het doorhebt, is gewijzigd door iemand anders, je het risico loopt dat deze kernel onverwacht gedrag (lees virusactiviteit) gaat vertonen.

@ Zwerver

Wat een FUD. En niet zo'n klein beetje ook. Als ik een PHP-bestand aanmaak dan draait deze onder een user die niet uit zijn chroot kan komen. Daardoor kan deze echt niet zomaar in /usr/src/linux komen, dus al met al zit je hier paniek te zaaien om niks.

Maar jij weet ook dat een gros van de gebruikers geen chroot gebruikt voor elke door apache gehoste website. Het gaat hier om een voorbeeld, en het is nogsteeds een vaak voorkomend scenario voor wat betreft rootkits en dergelijke.

[teun-v]

Echter lijkt het me dat als je bijv. /usr/src/linux gewoon alleen schrijf-/leesbaar maakt voor root+de admin groep er geen mensen meer bij kunnen ook al zijn alle onderliggende files 777.

Juist wel, eerste 7 is user tweede 7 is group en de derde 7 is others, dus kortom nooit 777 gebruiken

[LauPro]

Dat is dus niet waar:
root:root 700 /usr/src/linux
root:root 777 /usr/src/linux/important

'important' is niet lees-/schrijfbaar voor anderen dan root op deze manier.

[teun-v]

laat maar, ik zag je 700 over het hoofd, als het 755 is kan het wel

[Olaf van der Spek]

Dat is dus niet waar:

Waarom zou een non-root user de code niet mogen lezen?
Jij offert bruikbaarheid op.

[LauPro]

@Olaf van der Spek: daar zat ik ook even aan te denken. Wat mij betreft zou ik het liefste als user zijnde een kernel kunnen compileren en deze dan als root naar de /boot kunnen kopiëren.

Maar ik denk dat in een non-multiuser omgeving zoals op een webserver het helemaal niet wenselijk is dat normale users die sourcecode kunnen lezen.

[Olaf van der Spek]

Maar ik denk dat in een non-multiuser omgeving zoals op een webserver het helemaal niet wenselijk is dat normale users die sourcecode kunnen lezen.

Ik dacht dat Linux het multi-user OS bij uitstek was?
De toevlucht tot dit soort 'beveiligingen' zoeken vind ik erg zwak. Bovendien is het dan een work around voor een webserver, maar niet voor een algemeen systeem.

[LauPro]

@Olaf van der Spek: Natuurlijk is Linux multi-user. Alleen als je als 'hogere' user in stelt dat 'normale' users ook toegang tot de bepaalde bestanden hebben dan heeft dat niets te maken met Linux op zichzelf, maar 'gewoon' met de gebruikers.

En nogmaals: dit type kernel is eigenlijk helemaal niet geschikt om te gebruiken op webservers (in productieomgevingen). Dus er is helemaal geen probleem er worden alleen spoortslags allemaal aannames gedaan welke in mijn ogen niet reëel zijn.

Wanneer de situatie het geval is zoals in het nieuwitem beschreven, dan zou die beheerder moeten worden ontslagen ipv het te blamen op 'Linux' in het algemeen.

Linux is wat je er zelf van maakt. Natuurlijk moet de mens tot op zekere hoogte tegen zichzelf worden beschermd. Maar het is nu eenmaal vereist dat je je verdiept in de techniek. Anders moet je een supportcontractje bij Redhat scoren oid.

[Olaf van der Spek]

Alleen als je als 'hogere' user in stelt dat 'normale' users ook toegang tot de bepaalde bestanden hebben dan heeft dat niets te maken met Linux op zichzelf, maar 'gewoon' met de gebruikers.

De 'bug' is nu juist dat je zelf helemaal niks expliciet instelt.

Maar het is nu eenmaal vereist dat je je verdiept in de techniek.

Ik zie toch liever dat zaken secure by default zijn, maar helaas wordt er als het om Linux gaat toch snel zaken richting de beheerder geschoven terwijl dat niet echt nodig is.

In dit geval gaat het trouwens inderdaad om het niet belangrijk issue.

[bassekeNL]

Als een normale user de code wil lezen doen ze dat maar ergens anders.

Zowiezo zou ik root niet de owner maken van de bestanden, maar een user speciaal voor builden, maar dat terzijde. Maar chmod -R 700 is wel verstandig.

[Verwijderd]

Ik heb even vlug

find / -perm +002 -type f 2> /dev/null > /tmp/worldwrite

gedaan toen ik dit las en kwam tot de conclusie dat in Gentoo in ieder geval er geen source files van de kernel world writable zijn. Hoe komt men hierbij?

Edit: never mind, dit wordt inderdaad gewoon in de tekst gezegd

[4VAlien]

Het wordt uitgelegd dat dit een probleem is met de vanilla kernel en niet met de meeste distributies, waaronder Gentoo en Debian. Doet es lezen!

edit: mijn vanilla 2.6.17.6 heeft ook geen world writeables! Foutje bij de maintainers dus. Nou upgrade ik ook niet altijd direkt, alleen als zo'n micro minor update op mijn systeem van toepassing is of ik tijd over heb

[Verwijderd]

Zal wel een microsoft medewerker zijn die dit gevonden heeft, daar hebben ze namelijk altijd lees en schrijf rechten in alle directories.

[Tijger]

Hopelijk heb jij van Linux meer verstand, van Windows weet je klaarblijkelijk erg weinig af.

[d3vlin]

Overigens zijn de vanilla-sources volgens mij ook niet echt bedoeld voor productieomgevingen.

Welke kernel had jij dan in gedachten voor een productieomgeving? Daarnaast; de vanilla-sources van kernel.org zijn toch gewoon de moeder van alle kernel-trees die je vervolgens kunt tweaken zoals je dat zelf wil? Kernel from scratch zogezegd...

[Verwijderd]

Volgens een thread op de Linux kernel mailing list echter schijnen dit soort vragen vaker naar voren te komen. Ook voor de kernel sources in Linux kernel 2.6.15.4 is dit al eens gemeld volgens mij.

Het schijnt echter een algemeen bekend feit te zijn dat het uitpakken van de Linux kernel sources niet als root user dient te gebeuren maar als een ongeprivilegeerde gebruiker, waardoor dit euvel niet kan optreden. Dit heeft de desbetreffende persoon niet gedaan.

Voor meer informatie:
http://www.gatago.com/linux/kernel/6136874.html

[TD-er]

Dat je het niet als root uitpakt heeft toch niet zoveel effect op dit probleem?
De hackert zal toch de files aan kunnen passen en ook al maak je die kernel als gewone gebruiker, je installeert 'm toch als root.
Je moet dus gewoon altijd de nieuwste kernel sources downloaden en gebruiken, of de boel zelf in een dir zetten waar niemand anders bij kan.
Vrijwel alle scripts die scriptkiddies gebruiken zullen echter gewoon naar /usr/src/linux-blaat gaan en dan daar kijken wat er staat, dus als dat elders staat, ben je al relatief goed beschermd hiervoor in de praktijk.

[QuarkuS]

Als je dat stukje had gelezen, had je gezien dat als root uitpakken precies het probleem oplevert, en als je het als normale gebruiker uitpakt, je geen world-writable files krijgt per default. Het ligt aan de lokale gebruikers-instellingen (umask) welke rechten tar aan bestanden toekent, en dat verschilt dus tussen root en een normale gebruiker.

[DataGhost]

Je bent m.i. wel _ERG STOM_ als je default een umask hebt zodat je files world writable worden, root of niet

helios vnc # touch test
helios vnc # ls -l test
-rw-r--r-- 1 root root 0 Sep 8 16:08 test

geen last van:)
Mja, ik draai Gentoo dus ik heb sowieso geen last van dit probleem, ik weet dan ook niet of het daadwerkelijk wordt veroorzaakt door het uitpakken met tar en een default umask (waardoor het dit nieuwsbericht niet echt waard is, eigen stomme fout dus) of dat het door de ontdekker van dit probleem standaard wordt uitgepakt met -p, waardoor de permissies intact blijven. Naar mijn weten... eh. nee.

helios vnc # chmod 777 test
helios vnc # tar zcf tar.gz test test2
helios vnc # rm test test2
helios vnc # tar zxf tar.gz
helios vnc # ls -l test*
-rwxrwxrwx 1 root root 0 Sep 8 16:08 test
-rw-r--r-- 1 root root 2 Sep 8 16:09 test2

permissies zet ie inderdaad standaard over. Dan zal het niet aan het umask liggen, maar het feit dat dit in jou opkomt baart mij toch zorgen

[QuarkuS]

Dan wil ik toch even quoten van de link hierboven:

Please do not extract the kernel tarball as the root user, especially if you do not know how tar command works for root user by default (hint: --no-same-permissions).

Setting g-w in the archive forces arbitrary policy on people who work with umask 002 as a non-root user. We can let that policy to be controlled by user's umask by being lenient in the tarball. For the same reason, if somebody has umask 0, there is no reason for us (as tarball creator) to impose o-w as a policy on him either, hence git-tar-tree output has 0666 or 0777 modes.

[DataGhost]

Nouja, ik pak dan ook nooit zelf een kernel source uit, dit laat ik inderdaad mijn (gentoo ) package manager afhandelen. Vandaar dat ik ook niet met dit probleem bekend ben inderdaad.

[deavatar]

Discutabel of niet: er is een tekortkoming betreffende Linux. Als ik nu reacties van medetweakers lees wordt deze tekortkoming een beetje weggemoffeld. Serieuze vraag van mijn kant: waarom wordt hier niet ingehakt op linux? Als er een tekortkoming in Windows genoemd wordt krijgt MS het namelijk per definitie zwaar te verduren.

[durian]

Het is geen tekortkoming van Linux - hoogstens van de manier waarop files gedistribueerd worden. Als ik op een windows systeem mijn soruce filesin een shared folder zet en schrijftoegang aan iedereen geef kan ook iedereen erbij en ze veranderen. Dat ligt niet aan Windows maar aan mij.

[Olaf van der Spek]

Als ik op een windows systeem mijn soruce filesin een shared folder zet en schrijftoegang aan iedereen geef kan ook iedereen erbij en ze veranderen. Dat ligt niet aan Windows maar aan mij.

Dat is niet waar.
Als je onder Windows een archive uitpakt, worden er (standaard) geen permissies uit dat archive gebruikt. Onder Linux gebeurd dat wel (als root).
Ik gok dat Linux tar niet veranderd vanwege backwards compatibiliteit.

[durian]

Dat ligt eraan hoe je het inpakt, aan de gebruiker dus. Heeft ook niks met backwardscompatibiliteitsproblemen te maken. Het enige Linux"probleem" is dat je als gebruiker moet nadenken bij wat je doet

[Gert]

Titel had moeten zijn "computergebruiker maakt alles kwetsbaar".

[Tijger]

Yep, da's een security probleem wat nooit opgelost zal worden.

[kimborntobewild]

Als je 't hebt over de beheerders: die kunnen altijd inderdaad altijd de boel (ongewild) vernaggelen.
Echter, de overgrote meerderheid is geen beheerder maar een simpele user. Als je dan uitgaat van compromisloze goede code, en je geeft de user gewoon niet teveel rechten, dan heb je 't security probleem van "computergebruiker" toch opgelost.

ONDANKS dat, dat het percentage 'beheerders' op Linux distro's VEEL groter is dan bij Windows, is Linux toch VEEL secureder. Dat zou toch wel te denken moeten geven bij die gasten die altijd roepen dat Linux veiliger is alleen omdat 't minder gebruikt wordt (dat is dan ook enorme grote kolder als je 't mij vraagt).

[kdekker]

Ik denk dat allemaal wel meevalt. Een paar C-source files erbij, worden echt niet 'zomaar' meegecompileerd. Je moet dus ook andere sources/Makefiles wijzigen, wil je jouw kwaadwillige code laten uitvoeren. Je moet dus al aardig wat weten om in een hackopzet te slagen. Anyway: het is niet fraai dat het zo zit.

P.s.
1. het plaatje bij dit artikel laat nu net geen worl write rights zien, alleen owner write rights
2. Op windows zijn er veel meer en vaak onkundiger gebruikers (met admin rechten), vandaar dat security holes daar veel meer 'effect' hebben.

[Netsensei]

En wat met het vervangen van bestaande bestanden door die worden voorzien van extra ui te voeren code en "features"?

[serkoon]

Ik snap eerlijk gezegd niet helemaal hoe men kan beweren dat dit geen probleem van 'Linux' is. De tarball pakt gewoon uit naar files met gigantisch foute permissies. Die tarball is dus gewoon verkeerd gebouwd. Dat dit al jaren bekend is doet daar niks aan af.

Wat ik persoonlijk het ergste van alles vind, is dat het de figuren die de tarball daadwerkelijk maken schijnbaar niks kan schelen en erger nog: compleet onzinnige aanbevelingen doen (lees: 'niet als root uitpakken').

Tijd dat ze eens wat security-clue krijgen daar.

[Olaf van der Spek]

Ook in de Linux wereld kom je eigenwijze persoonlijkheden tegen.

[PolarWolf]

Jammer dat het afbeeldingkje nou net een stukje listing laat zien waarvan de bestanden *niet* "world writeable" zijn

Anyway, goed punt, ik zal eens kijken waar ik de source heb gelaten. Volgens mij nou niet echt onder de standaard /usr/src, maar je weet het nooit.