Veel Linuxdistributies zijn vatbaar voor kwetsbaarheid in glibc

Veel bekende Linuxdistributies zijn vatbaar voor een bug in de GNU C Library die een buffer overflow kan veroorzaken. Kwaadwillenden kunnen zowel lokaal als op afstand de kwetsbaarheid misbruiken, zo waarschuwen beveiligingsonderzoekers van Qualys.

De onderzoekers kwamen de bug tijdens een audit op het spoor. Ze troffen de kwetsbaarheid aan in een functie van GNU C Library, kortweg glibc. Daardoor konden de beveiligingsonderzoekers malafide code uitvoeren, zo schrijven ze dinsdag.

Qualys beweert dat de impact van de bug, die ze 'Ghost' noemen, enorm is. Veel bestaande Linuxdistributies zijn namelijk kwetsbaar. Het gaat onder meer om Debian 7, Red Hat Enterprise Linux 6 en 7, CentOS 6 en 7 en Ubuntu 12.04. Die distro's worden onder meer gebruikt voor het in de lucht houden van maildiensten, websites en andere belangrijke toepassingen.

De bug zou er volgens Qualys vijftien jaar geleden in zijn geslopen. De glibc-ontwikkelaars zouden het lek twee jaar geleden hebben gedicht, maar opmerkelijk genoeg voerden niet alle organisaties achter de Linuxdistributies de softwarepleister door. De bug stond namelijk niet als kwetsbaarheid bekend.

De beveiligingsonderzoekers hebben inmiddels een exploit ontwikkeld die op een Exim-mailserver is gericht. De exploit omzeilt bestaande beveiligingen op zowel 32- als 64-bit-apparaten. Binnenkort brengt Qualys de exploit uit als module voor de populaire Metasploit-hackerstoolkit.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (164)

Meer info hierrrr:
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235
https://threatpost.com/gh...-all-linux-systems/110679
http://www.openwall.com/lists/oss-security/2015/01/27/9

Eerdere berichten (van verschillende bronnen, incl RedHat's eigen tracker) dat het probleem opgelost zou zijn in de repositories van RedHat/CentOS zijn niet correct. Die moeten nog bijgewerkt worden.
Als het goed is kun je op Ubuntu wel reeds updaten naar de patched versie.

De gewenste versie is in principe glibc 2.18.x.
(Noot: niet voor CentOS/RHEL, daar is gewoon een 2.12.x variant released.
Dat is op CentOS 6 bijvoorbeeld "glibc-2.12-1.149.el6_6.5" (plus arch.); niet 6.4! 6.4 is vulnerable.)

Het leipe is, dat met die exploit die ze gemaakt hebben ze dus via een e-mailtje een shell kregen op de server. Geniaal.
Wel moet er bij opgemerkt worden dat de standaard configuratie van exim niet vatbaar lijkt te zijn. Het is dus even wachten wat ze precies gedaan hebben, maar de kwetsbaarheid is er. (En ligt niet aan exim, er zijn vele manieren om glibc te misbruiken.)

En voor de mensen die willen checken of hun systeem kwetsbaar is, voila:
https://gist.github.com/amlweems/6e78d03810548b4867d6
(-edit- Voor mensen die niet weten hoe dat werkt (foei!), zet de code van bovenstaande link in een bestandje met (bijvoorbeeld) de naam GHOST.c en draai dan het commando: gcc GHOST.c -o GHOST
Daarna ./GHOST als commando geven. Je krijgt meteen resultaat op het scherm )

-edit2-
Let op; het lijkt er op dat FreeBSD servers die libc in compat draaien ook kwetsbaar kunnen zijn.

-edit3-
Vergeet niet te rebooten nadat je je systeem gepatched hebt.

-edit4-
Ik heb begrepen dat er wat mensen lui zijn en vinden dat 3 stappen teveel werk is...
Voer dan dit uit:
wget -q http://bit.ly/1ByRhXz -O ghost.c && gcc ghost.c -o GHOST && ./GHOST
(Ik zelf ben geen voorstander van zomaar iets downloaden & uitvoeren zonder te bekijken wat ik precies download om uit te voeren, maar alas... U vraagt versimpeling: u krijgt het. )

-edit5-
Als je wilt weten of PHP mogelijk vatbaar is voor het probleem, run:
php -r '$e="0";for($i=0;$i<2500;$i++){$e="0$e";} gethostbyname($e);'
"Segmentation fault" betekent dat je kwetsbaar bent.
NOOT: Als je glibc geupdate hebt, zal je geen segmentation fault krijgen, maar PHP processen die reeds in 't geheugen aanwezig waren al sinds *voor* de update (en om wat voor reden dan ook dat ook blijven), zijn dan nog *wel* vatbaar... En gezien WordPress bijvoorbeeld gethostbyname gebruikt, kan dat een probleem zijn. Let dus goed op en installeer echt die patch & reboot zsm!

[Reactie gewijzigd door WhatsappHack op 29 januari 2015 06:52]

Ik denk dat de belangrijkste les van deze bug misschien wel is dat alle software ontwikkelaars gewoon over moeten naar getaddrinfo. Dan heb je gelijk een thread-safe en ipv6 compatible implementatie van dezelfde functie als gethostbyname.

- The gethostbyname*() functions are obsolete; with the advent of IPv6,
recent applications use getaddrinfo() instead.

Bron: http://www.openwall.com/lists/oss-security/2015/01/27/9

Dat lost natuurlijk problemen met oude systemen en software niet op, maar nieuwe software zou gewoon niet vatbaar meer moeten zijn voor deze bug door het gebruik van de bij tijdse funcies.

Ik wil hiermee niet impliceren dat ik het overal goed doe

PS.
Grappig is dat PolarSSL (onlangs nog in het nieuws hier) nog wel vatbaar is door het gebruik van gethostbyname:
https://github.com/polars...opment/library/net.c#L224
Alleen als je ipv6 support uitzet tijdens de compilatie.

Mongoose:
https://github.com/cesant...ob/master/mongoose.c#L597
PR: https://github.com/cesanta/mongoose/pull/463
Ik gebruik beide libraries in pilight. Morgen maar even een Pull-Request doen, done

[Reactie gewijzigd door CurlyMo op 27 januari 2015 22:51]

Er is een fix voor CentOS 5 maar nog niet voor 6 & 7, Debain 7 en Red Hat zijn al gepatched.

mogelijk kwetsbaar zijn:
- Mailserver die reversed DNS gebruiken op verbonden clients
- Formulieren op website die een DNS check doen waaronder WordPress XML-RPC pingback
- MySQL servers die een authenticatie check doen gebaseerd op hostname
- zelfde voor SSH server die een authenticatie check doen op basis van hostname

http://ma.ttias.be/critic...0235-gethostbyname-calls/
https://twitter.com/CentOS
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235

Edit:
ook CentOS 6 & 7 is ook gefixed nu wachten op de publish:
https://twitter.com/CentOS/status/560138182441070592

Edit 2:
Ook CentOS 6 & 7 staan nu live in de mirrors:
https://twitter.com/CentOS/status/560236518057709569

Updaten voor CentOS:
yum clean all && yum update

Update voor Debian:
apt-get clean && apt-get update && apt-get upgrade

Daarna kan je kijken welke services gebruiken maken van de glibc doormiddel van:
lsof | grep libc | awk '{print $1}' | sort | uniq

Deze services dien je te restarten om er zeker van te zijn dat het systeem niet kwetsbaar meer is (een reboot kan echter ook)

en om te kijken of je nog kwetsbaar bent:
cd /tmp
wget --no-check-certificate -O gistfile1.c http://tinyurl.com/ghostcheck
gcc gistfile1.c -o GHOST
./GHOST

[Reactie gewijzigd door xleeuwx op 28 januari 2015 14:28]

Centos nog niet binnen, ubuntu wel.

Ik heb CentOS 6 update al wel binnen.

Ja ik heb de centos servers gepatched nu. Ubuntu was dus eerder.

De gepatche versie voor Debian net geïnstalleerd op mijn server (gisteren was die nog niet binnen)
Tsja.... op mijn desktop gebruik ik Arch, de voordelen van een rolling distro, glibc 2.20.... geen problemen daar... maar ja... zo'n rolling distro is niet handig op een productieserver.

CentOS heb ik al binnen en gepatched.

CentOS

sudo yum update glibc
sudo reboot

als ge nie erg vind doe ik geen reboot op live server. Echter dien je dan wel alle services die direct / indirect verbonden zijn met het internet te restarten.

vorige reactie heb ik even bijgewerkt

[Reactie gewijzigd door xleeuwx op 28 januari 2015 14:09]

1: Update the glibc and nscd packages on your system
2: Restart vulnerable services that use glibc (since so many services use glibc, the safest option is to reboot the system).

For example, /sbin/init uses glibc, and restarting that without a reboot is non-trivial.

Check wat je moet herstarten met
lsof | grep libc | awk '{print $1}' | sort | uniq

[Reactie gewijzigd door trogdor op 28 januari 2015 23:20]

Ik ben wel benieuwd hoe iemand van plan was init te misbruiken voor een gethostbyname(); aanval.
Toch zou ik liever even rebooten.

[Reactie gewijzigd door WhatsappHack op 29 januari 2015 06:56]

Ik denk dat de belangrijkste les van deze bug misschien wel is dat alle software ontwikkelaars gewoon over moeten naar getaddrinfo.

Waar, maar ik denk dat de belangrijkste les iets anders is: laat je server processen in een sandbox draaien of als dat niet kan, in een zo laag mogelijk user-acount. Dus niet als admin of system. Te vaak draaien dit soort processen gewoon in root of system. Zeker bij semi-embedded systemen waar user-afscheiding lastig is zie je soms alles als 'system'.

Bij shell-shock had dat ook problemen voorkomen. En ook worden vrijwel alle ernstige gevolgen van deze bug voorkomen als je dat deed.

Omdat dit niet de eerste of laatste bug zal zijn is dat een nog belangrijkere les dan de jouwe (die op zich overigens ook helemaal correct is).

Op veel webservers is dat natuurlijk ook het geval, veel draait gewoon netjes als user account of een lowpriv accountje als nobody. Sandboxen is met sommige van die processen wat lastiger, al kan je afbakeningen doen...

Ik kan me absoluut niet vinden in je statement "processen draaien vaak als root". Dat is echt security 101 om niet te doen, veel processen weigeren dan zelfs te starten... Nee. Gewoon onzin, en als dat zo is: dan is de system administrator sowieso al een laml*l, dan heb je waarschijnlijk wel meer zorgen.
Mijn ervaring is dat veel mensen heel goed doorhebben dat ze dit soort software niet als root moeten draaien. En als ze het toch doen is het vaak enkel voor een thuisservertje ofzo voor hun films. Woopdidoo.

Hoewel het in theorie natuurlijk erg leuk klinkt, is het in de praktijk met dat soort systemen vaak een stuk lastiger om het *echt* in een sandbox te gooien omdat er zoveel van elkaar afhankelijk is, en mensen vaak moeten werken met gelimiteerde resources.
Wat je dan veelal krijgt zijn mensen die gewoon een beetje met een chroot-jail gaan lopen klooien, en dan serieus denken dat ze veilig zitten en goed bezig zijn... Nou, super... Als je jezelf maar veilig voelt, denk ik dan.

Dan heb je nog de problematiek met diensten die met elkaar verbonden moeten zijn. Stel je wilt het wat makkelijk doen, een soort van sandbox creeeren; maar dat het nog wel werkzaam is en niet al teveel moeite kost. Dan kies je bijvoorbeeld voor vserver of OpenVZ. (Terwijl OpenVZ eigenlijk ook gewoon een fancy chroot is, maarja... 't werkt wel wat veiliger. ) Daar donder je Apache + PHP in. En dan...? Er moet toch nog gecommuniceerd kunnen worden met mySQL (Die ook in z'n eigen instance draait) en toegang tot de bestanden.
Dat houdt dus in dat als jij die Apache instance infiltreert, men alsnog z'n weg omhoog kan werken naar zowel bestanden + mySQL; en dat zonder per se toegang tot die systemen te hebben; al weet je ook meteen waar die staan en kan je kijken of daar een point of entry is met dezelfde kwaadaardigheid...
Wat ben je dus *werkelijk* opgeschoten? De hacker heeft 't belangrijktste gehad, die root naar 1 systeem verkrijgen zal hem/haar een rotzorg zijn.

Het is lang niet altijd goed mogelijk en ook lang niet altijd nuttig om alles *werkelijk* te sandboxen. Maar een under-privileged user gebruiken voor de processen... Tja, dat weten de meeste mensen gelukkig ondertussen wel. Alle mensen in een beetje serieuze positie dan, laat ik het zo zeggen.

Het is lang niet altijd goed mogelijk en ook lang niet altijd nuttig om alles *werkelijk* te sandboxen. Maar een under-privileged user gebruiken voor de processen... Tja, dat weten de meeste mensen gelukkig ondertussen wel. Alle mensen in een beetje serieuze positie dan, laat ik het zo zeggen.

Inderdaad, per-service user accounts hebben Unix mensen wel al een tijdje door.

Dat is echt security 101 om niet te doen, veel processen weigeren dan zelfs te starten... Nee. Gewoon onzin, en als dat zo is: dan is de system administrator sowieso al een laml*l, dan heb je waarschijnlijk wel meer zorgen

Shellshock bewees je ongelijk

Met name embedded en semi-embedded sytemen hebben problemen. Die hebben soms niet eens user-accounts.

Maar ook de defaults zijn vaak slecht. MySQL in combinatie met Apache draait bijvoorbeeld standaard NIET afgeschermd om maar wat te noemen. Het komt dus wel degelijk heel vaak voor en is verre van onzin.

Je spreekt jezelf namelijk verderop tegen:

Hoewel het in theorie natuurlijk erg leuk klinkt, is het in de praktijk met dat soort systemen vaak een stuk lastiger om het *echt* in een sandbox te gooien omdat er zoveel van elkaar afhankelijk is, en mensen vaak moeten werken met gelimiteerde resources

En dat is het probleem. Een process kan dan toch opeens allerlei andere data van andere processen bereiken zelfs als het aan apart user-process is. Juist omdat het moeilijk is draait men vaak op hogere privileges dannodig. Lekker makkelijk. Niet bij een grote UNIX mainframe server, maar wel bij de kleine *nix PC/rack die de webserver moet draaien. Zeker als bedrijven

Men kan bijvoorbeeld bepaalde devcie drivers benaderen, of men kan bijvoorbeeld het intranet op. Dat is laatste hoe men vaak bedrijfsnetwerken infiltreert. Je hackt een process, dat vervolgens niet afgeschermd is en een socket kan openen naar het interne netwerk.

Vandaar dat ik bj mijn stelling blijf, dat "De Les" is dat je procesen moet afschermen en een zo laag mogelijk privilege moet geven. Liefst een sandbox, maar als dat niet gaat echt zoveel mogelijk afgeschermd. En daar is helaas nog steeds veel te veel bij te winnen.

Shellshock bewees je ongelijk

Ummm... Nee.
Volgens mij moet je nog een keertje de papers en uitleg over Shellshock bekijken.

Als ik zo je 2 reacties nog eens lees, lijk je te denken dat Shellshock enkel gebruikt kon worden als er toegang was tot een proces dat als root draaide, of dat het enkel dan een groot gevaar vormde.
Niets is minder waar, ook bij diensten die netjes under-privileged draaiden kon (kan als je niet gepatched bent ) bizar veel gevaar opleveren.

Ik stel voor dat je jezelf overnieuw inleest in wat nou werkelijk het probleem is met Shellshock.
Processen die als root draaien zijn verre van het enige risico factor.

Maar ook de defaults zijn vaak slecht. MySQL in combinatie met Apache draait bijvoorbeeld standaard NIET afgeschermd om maar wat te noemen. Het komt dus wel degelijk heel vaak voor en is verre van onzin.

Met alle respect: ik weet niet op welke manier jij je servers installeert, maar mySQL start standaard als de mySQL user en niet als root. En Apache als de http user of als nobody; ook niet als root, en bij een goede configuratie werk je bij Apache vervolgens nog met suexec ook; en voor processen als PHP zorg je dat ze niet buiten hun basedir kunnen komen (en gebruik je ook weer een vorm van phpSuExec, plus 't liefst een aantal extra beveiligingsmaatregelen).
Apache die standaard als root zou draaien is werkelijk de grootste onzin die er is, and I mean no offense.

Ze draaien niet sandboxed nee, dwz dat ze niet in een geheel eigen environment draaien. Maar dat wilde ik ook helemaal niet suggeren... Als je m'n post goed had gelezen dan zie je ook dat ik zelfs uit zit te leggen in wat voor een scenario dat bijvoorbeeld *wel* zou kunnen: maar hoe je daar vervolgens vrij weinig mee opschiet omdat de diensten alsnog met elkaar moeten kunnen communiceren om een effectieve stack te hebben, waarbij een compromise bij de een dus tot gevolg kan hebben dat ook informatie/data van de ander opgehaald kan worden: of je zelfs je weg verder (omhoog) kan vinden.
(En dat komt niet door teveel privileges, maar omdat ze elkaar gewoon moeten kunnen benaderen om hun werk te kunnen doen. Simple as that.)

Webservices die als root draaien komen standaard absoluut *niet* heel vaak voor.

Je spreekt jezelf namelijk verderop tegen:

Nee, sorry, je hebt of niet goed gelezen of me gewoon niet goed begrepen met wat ik probeerde duidelijk te maken.

En dat is het probleem. Een process kan dan toch opeens allerlei andere data van andere processen bereiken zelfs als het aan apart user-process is. Juist omdat het moeilijk is draait men vaak op hogere privileges dannodig. Lekker makkelijk. Niet bij een grote UNIX mainframe server, maar wel bij de kleine *nix PC/rack die de webserver moet draaien. Zeker als bedrijven

1.) Dat is geen probleem, want dat proces *moet* data van een ander proces kunnen bereiken, anders werkt het niet. Zonder dat dat kan, kunnen de diensten niet met elkaar communiceren. Dan krijg je dus dat je PHP proces bijvoorbeeld geen verbinding meer kan leggen met je mySQL server. Of dat je Apache niet meer kan lezen van je NFS share en uit pure wanhoop maar een 404 of 500 tevoorschijn tovert. Dan kan je net zo goed de stekker uit de server trekken; dan weet je zeker dat je veilig bent en heb je ongeveer evenveel nuttige diensten draaien...

2.) "Juist omdat het moeilijker is draait men vaak op hogere privileges dan nodig".
Ik blijf erbij: Neen.
Ik ben benieuwd... Op deze manier blijven we heen en weer gaan; wat zij jou bronnen dat dit soort diensten standaard hele hoge privileges (volgens jou zelfs als root!) hebben en/of dat heel veel mensen ze in hele hoge privileges laten draaien? Zeker op webservers (bij bedrijven)? Ik herken het beeld echt *totaal* niet.
Misschien 10 jaar geleden, maar tegenwoordig echt niet meer.

En *juist* bij bedrijven is men steeds meer gaan focussen op security. (niet altijd met succes, maar het gros wel.)
Niet lullig bedoeld, maar volgens mij leef je nog ergens in het verleden waar dit nog veel voorkwam omdat toch (bijna) niemand een computer had, of enkel voor tekstverwerken , en dit soort apparatuur puur werd ingezet voor bijv bedrijf-bedrijf communicatie of applicatie servers voor bijvoorbeeld het controleren van gegevens in een databank bij de gemeente, om maar wat te noemen. Maar op de webservers van tegenwoordig, zoals de genen die het gros van de websites op de interwebz serveren? Nah uh... Geen denken aan dat die vitale webservices als root draaien, misschien hier en daar een uitzondering: maar dan heb je 't wel gehad.
Zoals ik al zei: de meeste software *weigert* zelfs als root te draaien.

Men kan bijvoorbeeld bepaalde devcie drivers benaderen, of men kan bijvoorbeeld het intranet op. Dat is laatste hoe men vaak bedrijfsnetwerken infiltreert. Je hackt een process, dat vervolgens niet afgeschermd is en een socket kan openen naar het interne netwerk.

Ah, maar dat is toch echt weer een heel ander verhaal.
Ik vind dat trouwens meer de schuld van een achterlijke netwerk engineer dan van de server beheerder, maar goed.
Dat kon je goed zien bij KPN... De servers konden nog zo veilig zijn, maar op netwerk niveau kon men gewoon vanaf public interfaces ook bij het interne netwerk komen... En dan op dusdanige manier dat de sjaak die toegang kreeg (vanuit een datacenter van KPN, trouwens) zelfs toegang had tot routers die 112 afhandelden.
Dat heeft vrij weinig te maken met een Apache servertje in een sandbox flikkeren, want als die netwerk connectiviteit heeft en het netwerk staat het toe: waarom zou ie dan niet, als het process 't opgedragen wordt, daar verbinding mee maken...? Apache weet niet dat dat fout is, dat moet *of* in de firewall op de server goed geregeld worden of, en dat is nog beter, gewoon netjes in het netwerk goed ingesteld worden.


Ik zie ook niet in hoe dat voorkomen kan worden met een sandbox, even serieus.
Je kan 't wel leuk gaan sandboxen, maar als het proces in de sandbox netwerk connectiviteit nodig heeft en het is vervolgens mogelijk om met het intranet te verbinden: dan heeft dat helemaal niets te maken met teveel rechten voor dat process of dat het niet in een sandbox staat (immers staat het *wel* in een sandbox): nee, dat is gewoon een brakke netwerk configuratie en/of je hebt je sandbox gewoon niet goed ingericht. (Of je firewall (acl) regels sporen niet.)

Een sandbox is niet het heilige middel dat alles direct oplost; ook daar kan je de configuratie gewoon op een manier in orde brengen dat er alsnog heel hard om gejankt kan worden. Elk proces is onderhevig aan goede configuratie van het bovenliggende systeem/netwerk; als je sandbox dingen mag doen die je niet wil dat het zou mogen doen: dan is je configuratie gewoon slecht; niets meer, niets minder...

Vandaar dat ik bj mijn stelling blijf, dat "De Les" is dat je procesen moet afschermen en een zo laag mogelijk privilege moet geven. Liefst een sandbox, maar als dat niet gaat echt zoveel mogelijk afgeschermd. En daar is helaas nog steeds veel te veel bij te winnen.

Nou, ja... Dat is een les die het overgrote deel van de mensen, althans: in een enigszins redelijke positie (en zelfs na een jaartje MBO niveau 3 systeembeheer...) wel weten. En te hoge privileges is niet per definitie waar de GHOST kwetsbaarheid haar bestaansrecht aan te danken heeft... Shellshock ook niet.
De stelling dat te veel privileges het probleem is bij die hacks en dat daardoor de grote problemen mogelijk zijn wijs ik echt van de hand.

Vandaar dat ik bij m'n stelling blijf dat de meeste mensen prima weten (nogmaals: mensen in een enigszins redelijkse positie, Sjaak die thuis z'n DLNA servertje op een Ubuntu bak heeft gegooid en de "Do not run me as root! Use --force to override." negeerd boeit heel weinig.) dat ze processen niet als root moeten draaien, en de meeste notabele processen _weigeren_ dat ook gewoon of geven grove waarschuwingen en een echt gevecht voordat ze 't wel doen: zoals het hoort.
Er is maar heel weinig nog aan te winnen op dat gebied, en nogmaals: dan nog. Een sandbox is niet de heilige graal, en underprivileged users gebruiken biedt ook helemaal niet per definitie een werkelijke oplossing om lekken, data theft en misbruik van grove kwetsbaarheden te voorkomen.

Zoveel mogelijk afschermen is een heel goed iets, de meeste mensen weten dat (sure, er zijn vast een paar incompetente sjaakies die het niet kunnen); maar je moet niet doorslaan: zeker niet als het geen werkelijk nut heeft. ... Op geld verdienen aan de tijd die je eraan verspild na misschien.


Trouwens, ik geloof graag dat embedded systemen daar best kwetsbaarder voor kunnen zijn hoor; of het (veel) vaker doen. En *daar* zal misschien nog best wat te winnen zijn. (Zoals het voorkomen van het draaien van bitcoin miners op je smartkoelkast! )
Maar ik heb het puur over webservices in m'n posts.

[Reactie gewijzigd door WhatsappHack op 29 januari 2015 04:45]

Leuk in theorie, maar in praktijk moet in een embedded settop box de gebruiker de netwerkconfiguratie aan kunnen passen, en directe toegang tot de PVR functies hebben.

Niemand gaat de effort betalen om dat netjes in subprocessen en accounts te verdelen, dus dat gebeurt niet. Ga er maar gerust vanuit dat alle "smart TVs" en settop boxen die Linux draaien alles onder "root" doen.

Niemand gaat de effort betalen om dat netjes in subprocessen en accounts te verdelen, dus dat gebeurt niet. Ga er maar gerust vanuit dat alle "smart TVs" en settop boxen die Linux draaien alles onder "root" doen.

Exact!

En dat is dus waarom bugs als Shellshiock en nu deze potentieel zo gevaarlijk zijn. Ik zei niet voor niets "zeker bij semi-embedded systemen waar user-afscheiding lastig is zie je soms alles als 'system'."

Toch zal dat moeten gebeuren wil je dit soort bugs qua ernst een beetje in bedwang houden. Dat zal echter een process van vallen en opstaan worden.

Ik houd mijn hart daarom vast bij 'internet of things' waar patches zo goed als nooit plaatsvinden omdat het ook nog eens tegen bodemprijzen moet. Als je nu al ziet hoe Linux routers vaak niet geupdate worden en dus bol van de bugs staan...

Op de open-source boxen heb je tenminste nog inzicht wat er draait en welke kwetsbaarheden er zijn. OpenPLi heeft al glibc 1.20 en dus geen last van deze kwetsbaarheid. Van een smart TV weet je wel dat hij wel iets van Linux zal draaien, maar welke versies erin zitten (en ga er maar vanuit dat die vaak stokoud zullen zijn) van dit soort kritische libs kom je eigenlijk alleen maar achter door 'm aan te vallen.

Ik blijf erop hameren dat je idioot bent als je de webinterface van zelfs een opensource settop aan het internet hangt. Ik raad altijd aan om alles via SSH te tunnelen, dan heb je maar een pakket dat je in de gaten moet houden, en in SSH zijn nog steeds geen kwetsbaarheden ontdekt.

Zo'n settop die alles als root draait is prima op je thuisnetwerk verder. Dichttimmeren heeft geen zin, je kunt er gewoon fysiek bij...

Ja, natuurlijk dingen niet als root draaien, maar in een user account met zo min mogelijk rechten. Maar ik denk niet dat daarmee "vrijwel alle ernstige gevolgen" voorkomen kunnen worden. Dat beperkte user account waaronder (bijvoorbeeld) je webserver draait, heeft misschien nog steeds toegang tot databases of andere data, die nodig is voor het functioneren van de applicatie. En misschien is data nou juist waar een hacker naar op zoek is...

Precies.
Sterker nog: vaak is het *juist* de data die ze willen hebben en interesseert de machine zelf ze verder vrijwel geen ene hol. Vaak hebben ze daar geen enkele interesse in, of als ze toegang krijgen: dan mollen ze hem. (Van die eikels die rm -rf /* gaan draaien en meer van dat soort klote geintjes.)

Daarom hoor je zo vaak dat er complete databases zijn gejat.
En via de data (mits de database groot is met veel mensen erin) kan men vaak ook weer elders inbreken, of op andere accounts van die mensen, et cetera.
Data is voor het gros van de hackers het belangrijkste (zeker als er credit cards om de hoek komen kijken ), niet de volledige root/administrator toegang tot het systeem. (Al is dat een welkome bonus natuurlijk als 't wel lukt... Zeker als je het type hacker bent dat wil proberen zoveel mogelijk malware te verspreiden, maar die zijn er minder dan data diefjes.)

[Reactie gewijzigd door WhatsappHack op 29 januari 2015 04:44]

Voor de mensen die het met 1 commando willen testen:

wget https://gist.githubuserco...021db8db1d26e/gistfile1.c && gcc gistfile1.c -o GHOST && ./GHOST

Voor de mensen die het met 1 commando willen testen:

Dat zijn er *3* en wat shell conditionals .

Idd, je hebt gelijk. Maar ik bedoelde meer in de trend van: "1 lijn kopieren en plakken, en dan direct het resultaat zien".
Was bedoeld voor de luie mensen (waaronder ikzelf)

Jammer dat de link is afgebroken.

[Reactie gewijzigd door trogdor op 28 januari 2015 23:40]

Haha, sjesus wat een lui volk hier soms
Vooruit, copy/paste dit maar naar je commandline:

wget -q bit.ly/1ByRhXz -O ghost.c && gcc ghost.c -o GHOST && ./GHOST

[Reactie gewijzigd door WhatsappHack op 29 januari 2015 05:09]

+2 :-)

Hier heb ik nog een python voorbeeld gevonden om te checken of de gebruikte glibc kwetsbaar is. Er zijn twee verschillende proof-of-concepts afhankelijk van welke versie van Python geïnstalleerd is.

http://the-s-unit.nl/ghost-py-checker

Usefull! Dit kan je temninste gewoon in een script jagen! ++

Yaay. Debian 8 zegt hier keurig netjes

not vulnerable

[Reactie gewijzigd door sfranken op 28 januari 2015 04:25]

Dan is je check niet goed want Debian 7 is wel degelijk kwetsbaar. Ik heb er net een stuk of honderd gepatched. Je moet versie 2.13-38+deb7u7 van libc6 hebben om veilig te zijn.

Code van de gist hierboven gepakt, door GCC gehaald en daarna uitgevoerd. Daar krijg ik toch écht te zien "not vulnerable", ik kan er niks aan doen.

Edit: sorry, foutje, het is Debian 8, niet 7

[Reactie gewijzigd door sfranken op 28 januari 2015 14:23]

Het kan best hoor, als je updates al gedraaid hadden. Debian had het eerder op de dag al als patch naar de repositories gepushed. Als je automatische updates aan hebt staan (in een cronjob oid) heb je een grote kans dat ie al gepatched is.

Je kan voor de zekerheid even de nieuwste gepatchete versie controleren tegen het versienummer van de installatie op jou Debian bak.

Ik heb een foutje gemaakt. Het is Debian 8, niet 7

MOet je systeem natuurlijk wel benaderbaar zijn om kwetsbaar te zijn. Ik handel bv geen mail af maar wel http.

Mail is niet het enige dat kwetsbaar is, dus als je http bereikbaar is kan daar ook mogelijk een point of entry in gevonden worden. Zeker als je iets als PHP draait.

Leg uit? Zolang je webapp geen andere hosts contacteert via een user-supplied hostname zie ik niet in hoe je hier vulnerable kan zijn. Het enige scenario dat ik kan bedenken als je PHP script als een soort van reverse-proxy functionaliteit aanbiedt, maar dat lijkt me in de meeste webapps eerder uitzondering dan regel.

En ik zie niet hoe PHP dan meer vulnerable zou zijn. Ik ben zelf ook geen fan van PHP vanwege de security-issues, maar dat wil niet zeggen dat we nu alles op PHP moeten gaan steken :-)

De enige protocollen die me echt kwetsbaar lijken zijn SMTP (door dns-check tijdens het HELO commando) en HTTP (in een reverse proxy omgeving). En misschien ook FTP als deze niet in PASSIVE mode werkt (maar kan me vergissen, heb dat nog niet in detail bekeken).

edit: ik heb het enkel over services die remote benaderbaar zijn natuurlijk. Als een user shell-access heeft, zal de impact van deze bug veel groter zijn. Daar is elke setuid-applicatie die een hostname als parameter aanneemt mogelijk kwetsbaar.

[Reactie gewijzigd door sithlord2 op 28 januari 2015 10:48]

Ze vertellen gelukkig zelf al wat de Exim-server verder moet doen, in je openwall-linkje.

The Exim mail server is exploitable remotely if configured to perform
extra security checks on the HELO and EHLO commands ("helo_verify_hosts"
or "helo_try_verify_hosts" option, or "verify = helo" ACL); we developed
a reliable and fully-functional exploit that bypasses all existing
protections (ASLR, PIE, NX) on 32-bit and 64-bit machines.

Dus ironisch genoeg als je een dubbelcheck op authenticiteit van commandos laat uitvoeren, creeer je juist een gat.

Exim zelf is het gat. Dit is maar 1 van de kwetsbaarheden die ze hier oplossen.

Bij Debian als je 'm als firewall wilt installeren, dus als root, dan draait de service 'exim' op 1 of ander wonderbaarlijke manier ook, zelfs als het geen mailserver is. Dus dat is de eerste die je eruit sloopt natuurlijk als service.

Feitelijk gesproken de firewalls en ftp servers hier die op modified debian kernel draaien (enkel dingen eruit gesloopt, niks toegevoegd), daar staan ALLE services uit, op 1 na.

Als je een netstat -a doet wil je idealiter simpelweg niks meer zien dat luistert op ENIG port.

Bedankt WhatsappHack!
Mijn VPS met CentOS 6.6 was kwetsbaar, maar er was gelukkig een update:

$ wget https://gist.githubuserco...021db8db1d26e/gistfile1.c
$ gcc gistfile1.c -o GHOST
$ ./GHOST
vulnerable
$ yum list updates | grep glibc
glibc.x86_64 2.12-1.149.el6_6.5 updates
glibc-common.x86_64 2.12-1.149.el6_6.5 updates
glibc-devel.x86_64 2.12-1.149.el6_6.5 updates
glibc-headers.x86_64 2.12-1.149.el6_6.5 updates

Dus kwetsbaar, maar er is een update beschikbaar
Dus updaten:

$ yum update glibc*
..
$ ./GHOST
not vulnerable

En deze update heeft dat gat gefixt. Op naar de volgende..

[Reactie gewijzigd door Barryke op 28 januari 2015 08:57]

Toppie! You're welcome.

Vergeet niet te rebooten...!
Er kunnen namelijk nog applicaties draaien die de oude versie in 't geheugen houden...
Nieuwe applicaties (en de GHOST check dus ook) zijn dan niet kwetsbaar, maar spul dat reeds draait is dat nog wel, helaas. Hence: ff rebooten.

[Reactie gewijzigd door WhatsappHack op 28 januari 2015 09:47]

De test voor php werkt niet op debian 7.8, geeft een false negative.

Het staat niet in het het artikel, maar de gethostbyname() functie waar de kwetsbaarheid in zit is om het IPv4 adres op te halen aan de hand van een domeinnaam. Afhankelijk van de configuratie in /etc/nsswitch.conf onder het kopje 'hosts' kunnen hiervoor /etc/hosts (files) en DNS (dns) geraadpleegd worden Op vrijwel alle systemen worden beide gebruikt. Hierdoor is de bug mogelijk remote exploitable. Ook wordt gethostbyname() in veel programmeertalen beschikbaar gemaakt, waardoor er meer aanvalsvectoren zijn. Het is dus zaak dat deze bug snel geplet wordt.

Op ze minst onderandere Wordpress is ook kwetsbaar hierdoor, en ook MySQL
zie:
http://ma.ttias.be/critic...0235-gethostbyname-calls/

Wordpress draait op PHP; het zou dan beter zijn om te stellen dat PHP "kwetsbaar" is.

Nee, php maakt gebruik van gethostbyname zoals vele andere script talen. Het lek zit dus niet in de PHP versie zoals ik het hierboven lees.

Dat Wordpress specifiek genoemd wordt snap ik wel, vele maken gebruik van wordpress. Gelukkig zelf geen last van, als er iets een rotzooi is, dan is het wel wordpress haha. Leuk wanneer je een simpel blogje in elkaar wilt klikken, maar zodra je iets serieus bouwt wil je daar niet aan beginnen

Vandaar dat ik kwetsbaar tussen aanhalingstekens heb gezet.

Vanwege de heimelijk aard van de bug noemt Qualys de fout dan ook 'Ghost'.

It is called as the GHOST vulnerability as it can be triggered by the GetHOST functions.

https://community.qualys....7/the-ghost-vulnerability

Moet ik nou uit het artikel opmaken dat recentere distro's niet kwetsbaar zijn ? Ik heb Ubuntu 14.04.1 die dagelijks zonder interactie wordt bijgewerkt.

Net even nagekeken; de glibc-versie die ik momenteel heb is 2.19-1. Die zou dus niet meer kwetsbaar moeten zijn. Zolang je dus zorgt dat je distro up-to-date is en je je systeem regelmatig bijwerkt is er dus feitelijk weinig aan de hand.

Dat dergelijke problemen bij oudere software voor kunnen komen is op zich niet vreemd.

[Reactie gewijzigd door Titan_Fox op 27 januari 2015 21:59]

Debian 7 is "recent", maar kwetsbaar. Dat komt omdat Debian niet heel veel moeite doet om bij te blijven. Debian 7 is dan wel de nieuwste Debian versie, maar heeft een fors verouderde glibc.

Dat is ook bekend over Debian. Ze liggen over het algemeen achter qua updates en ondersteuning. Aan mij is dat systeem ook niet besteed omdat het minder gebruiksvriendelijk is als bijvoorbeeld Ubuntu en Linux Mint.

Zal er misschien mee te maken hebben dat de Debian-community relatief klein is in tegenstelling tot Ubuntu ?

Debian/stable is software die "bewezen" stabiel is, om specifieke software, en nog veel belangrijker het geheel aan onderling afhankelijke packages, stabiel te verklaren kost veel tijd (in het verleden jaren). In een stabiel verklaarde release worden de software versies dan ook niet meer aangepast tenzijn er een heel groot risico zit op niet updaten naar een nieuwere versie (dat komt zeer sporadisch voor (ssh is het enige voorbeeld dat ik kan herinneren)). Wat wel gebeurd is dat het security team z'n uiterste best doet om de fixes te backporten.

Wat jij schijnbaar niet weet is dat Ubuntu leeft op snapshots van de Debian/unstable tree. Dat is dus niet software die onstabiel is, maar nog niet bewezen stabiel.

Het probleem daarmee is dus dat ze een heleboel tijd verdoen om zaken stabiel te krijgen met glibc 2.13, terwijl de rest van de wereld glibc 2.20 gebruikt. Dat betekent dus ook nog eens dat de Debian community al dit soort fixes moet backporten.

Daar staat tegenover dat het onderhoud van een serverpark met Debian/stable peanuts is. Er zijn als het goed is geen overwachte gerelateerde bugs voor deze update.

Maar ik hoor graag welke belangrijke/nuttige features er tussen 2.13 en 2.20 (voor servers) de upgrade rechtvaardigen

De reden dat al mijn Debian servers de upgrade naar tenminste glibc 2.18 krijgen? Support voor niet-antieke GCC versies.

Visual Studio ondersteunt C++11 grotendeels, ook op 10 jaar oude Windows XP machines. Dat komt omdat Microsoft heel erg duidelijk heeft gemaakt dat de runtime geen deel van het OS is.

GCC doet aannames over de inhoud van glibc, die problematisch blijken op systemen van 10 dagen oud - de huidige Debian 7 Stable met z'n glibc 2.13 ondersteunt alleen C++03 van 12 jaar geleden.

Debian/stable is geen plaform voor zo'n nieuwerwetse standaard, wheezy werd frozen 2012-06, de tijd tussen de C++11 release (10 maanden) en de freeze was schijnbaar te kort.

Unstable ("bleeding edge") of testing (minder flux, maar wellicht ook langer last van bugs) zijn wellicht interessanter voor nieuwe jou werkzaamheden.

Voor iemand die Debian/stable targetted software moet onderhouden: het zal me wordt wezen wat nieuwe specs zeggen, m'n software is oude meuk.

Je weet dat je onder linux ook pakketten kan symlinken? Oftewel:

Je hebt bijvoorbeeld GCC 1.01 nodig en hebt zowel 1.00 als 1.01 geïnstalleerd.

Zie ook: http://askubuntu.com/ques.../choose-gcc-and-g-version

Misschien handig?

De reden dat al mijn Debian servers de upgrade naar tenminste glibc 2.18 krijgen? Support voor niet-antieke GCC versies.

Als je GCC gebruikt is dat misschien een goede keuze, maar dat is een kleine minderheid van de servers. De meeste servers hebben GCC niet eens geinstalleerd staan; die compilen nooit iets.

Ik draai geen GCC op de productie server. Het probleem is dat GCC op mijn build machine linkt tegen de libc van de build machine, en vervolgens een compatible libc op de productie server verwacht.

Ter vergelijking: Met MSVC link ik tegen de MSVCRT van de compiler, en die MSVCRT deploy je met je programma mee op de server.

hmm, je hebt gelijk, ik zat te suffen

Misschien de filosofie van Debian eens opzoeken? Na een release word nooit nog een nieuwe versie van een pakket toegevoegd. Bugfixes worden gebackport zodat systeembeheerders zeker zijn dat er NOOIT iets kan breken door een pakket of zelfs maar een optie die verwijderd word in een nieuwe versie.

C++11 wil je dan ook echt in grote bedrijven gebruiken he.

Oh comeon.

Dat is alleen om mensen BEZIG te houden.

Wij zijn een klein bedrijf. We gebruiken C++11 omdat we het ons niet kunnen veroorloven om alle nuttige dingen uit C++11 zelf te herschrijven.

je werk is mensen bezig houden met overheidssubsidie?

Want nuttige nieuwe features zijn er niet in al die addities.

Je wilt overzichtelijke code KISS principe en geen houdinipraktijken in talen waarbij je van de ene grap en truuk in de andere vervalt.

Het ultieme rampscenario is dat je code een soort van Adobe codebase wordt natuurlijk (ja dat is C++).

Overheidssubsidies? Je weet echt niet waarover je praat. Microsoft krijgt niet bepaald subsidies voor Visual Studio.

En dat jij alle nuttige features niet ziet zegt meer over jouw beperkte capaciteiten.

Dat Debian veel tijd en moeite steekt in het stabiel maken (en houden) van hun OS is bekend. Het zit ook niet zo simpel in elkaar zoals ik het net zei; daar heb je gelijk in.

Het resulteert er echter in dat ze stukken langzamer zijn met updaten. Ze kiezen dus voor kwaliteit i.p.v. kwantiteit. Daar is natuurlijk wat van te zeggen.

Nu moet ik wel toegeven dat ik met Ubuntu 14.04.1 geen enkel probleem ben tegen gekomen. In de 14.10 versie zaten een paar eigenaardigheden en wat vervelende bugs, dus die heb ik overgeslagen. Denk dat ik pas upgrade bij de volgende LTS versie.

ik gebruik zelf Debian, maar MSalters heeft wel 1 punt en dat is dat Debian HOPELOOS achterloopt overal.

Het ligt er maar aan wat je doel is. Heel vaak is het helemaal niet nodig om de nieuwste versie te hebben, tenzij je een bepaalde feature nodig hebt.
Bij servers wil je vooral dat ze betrouwbaar en voorspelbaar zijn.

Met als klein probleem dat er race condies in Debian zijn, dus multiple socket machines, die kunnen met regelmaat niet booten omdat zo'n race bug optreedt. Bijvoorbeeld de 8 core Xeon servers hier (2 sockets).

Op die machines heb ik dan maar gentoo geinstalleerd, maar dat is ook geen grote pret (hoezo een typing contest?).

Weet je net beetje hoe de runlevels van Debian werken en wat er geklooid is in de kernel, bij gentoo werkt' t weer anders natuurlijk

Mja glibc verander je niet zo maar. Je compiler is daarmee verbonden en ook je kernel.

Dat niet alleen. Nog veel meer haakt in op glibc.
Het gaat er niet eens zozeer om dat je het niet "zo maar" kan updaten, want dat kan wel.
Het probleem is dat de kans dan groot is dat andere software kapot kan gaan, en OS distributies zoals RedHat en Debian, die nog al eens op "stable" productie servers worden gebruikt (en vaak ook jaaaaaaren dezelfde software willen draaien) kunnen dat dus niet zomaar doen.

Daarom ook vaker rolling releases op een desktop, dan kan je de nieuwste spulletjes en leuke gimmicks draaien; terwijl de stabiele distros lekker op het oude spul blijven hangen zolang 't bewezen goed werkt en dan gewoon met een geheel nieuwe versie komen (Eg: CentOS 6 -> CentOS 7) waarin al het nieuwe (doch uitgebreid geteste) materiaal zit voor de mensen die 't willen hebben.

Ieder z'n zin!
Debian 7 heeft het dus niet, vanwege dit soort redenen, maar Ubuntu bijvoorbeeld wel; want die krijgen gewoon de nieuwste packages.

Ieder z'n zin!
Debian 7 heeft het dus niet, vanwege dit soort redenen, maar Ubuntu bijvoorbeeld wel; want die krijgen gewoon de nieuwste packages.

Wel ik gebruik Slackware. Ik moet dus ook wachten op packages van een gepatchte glibc net zoals RH/CentOS .

Een Slackware gebruiker die compileert glibc toch zeker gewoon zelf van de source-tarball in plaats van te wachten op een packaged versie?

En een gentoo gebruiker kijkt eerst nog of z'n C-flags wel geheel optimaal zijn, zodat ook die laatste 0,001% uit de oude AMD Athlon geperst kan worden.

Sorry, kon 't niet laten...

Om ze een dag eerder te hebben en dan toch te vervangen met Pat's packages ?

En daar heb je precies het probleem: libc heeft geen goede multi-versioning support. Daardoor ben je geforceerd om precies 1 versie tegelijk te draaien waar al je software (inclusief het OS zelf) dan afhankelijk van is. Ter vergelijking: onder Windows is het geen enkel probleem om 10 C libraries in parallel geïnstalleerd te hebben, inclusief een mix van release en debug versies, Microsoft en Borland, voor x86 en x64 etc.

An sich geen probleem nee, maar dan moet je wel de trade-off accepteren dat je meerdere runtimes moet gaan supporten.

Debian/stable is al gefixed:
https://security-tracker.debian.org/tracker/CVE-2015-0235
Het is nog even wachten op oldstable (squeeze/tls) updates

Vanochtend voor 06:00u waren de patches al op Squeeze LTS doorgevoerd:

Reading changelogs...
--- Changes for eglibc (libc6 libc6-i386 libc-bin locales) ---
eglibc (2.11.3-4+deb6u4) squeeze-lts; urgency=medium

* Non-maintainer upload by the Squeeze LTS team.
* debian/patches/any/cvs-gethostbyname.diff: new patch from upstream
to fix a buffer overflow in gethostbyname (CVE-2015-0235).

-- Holger Levsen <[e-mail]> Tue, 27 Jan 2015 23:57:55 +0100

Debian zorgt net wel voor bugfixes en veiligheidsupdates, dus dat is relatief. Zoals jij het formuleert klinkt het alsof Debian je aan je lot overlaat als je de stabiele versie gebruikt.

Dat komt omdat Debian niet heel veel moeite doet om bij te blijven.

Wtf? Debian is meestal de eerste met een security patch.

Dat vind ik ook vaagjes blijven, want ik zie mensen met Ubuntu wel snel updaten (en rapporten dat ze kwetsbaar zijn); maar ik zelf heb niet gelet op de versie die ze noemden. (Gebruik Ubuntu zelf niet, dus boeide me niet zoveel
Als je wilt weten of je kwetsbaar ben, zie m'n eerste post in dit topic voor instructies.

Het staat sowieso reeds in de Ubuntu repositories, dus als je apt-get update moet je direct de update binnen krijgen, als die nodig is voor die versie.

[Reactie gewijzigd door WhatsappHack op 27 januari 2015 21:59]

Bij mij worden optionele updates ook zonder mijn tussenkomst geïnstalleerd. Zo hoef ik er zelf niet aan te denken. Mijn glibc-versie is 2.19-1, dus dat zit wel snor.

Dus ja, het is op zich wel een vrij ernstig probleem, maar alleen als je oude software draait. Desondanks voel ik me bij Ubuntu stukken veiliger dan bij Windows. Het aantal ernstige Linux exploits die ik de laatste paar jaar voorbij zag komen waren op een hand te tellen en werden in de regel binnen de kortste keren gepatched.

Apt-get update doet niet je distro updaten.

werkt apt-get dist-upgrade tegenwoordig nog?

Zeker. Mits je het als sudo/root doet.

alias fucking=sudo
fucking apt-get dist-upgrade

Debian. En zoals het hoort, daar is apt-get/aptitude upgrade/dist-upgrade voor.

Dan heb je nergens last van, de bug is in 2013 al geplet, maar blijft nog hangen in heel veel oude systemen, die alleen kritieke updates draaien (deze is toen niet als kritiek neergezet omdat ze niet doorhadden dat er een bug was)

RedHat 6/7 en CentOS 6/7 zijn behoorlijk recente distributies. Aangezien ze vaak op servers gebruikt worden die als ze ingericht zijn niet direct van een nieuwe versie van de distributie worden voorzien (wel als het goed is maandelijks de patches krijgen) is het bericht met behoorlijke implicaties.

Idd, ben ik blij dat ik automatisch updates push. Indien dat verkeerd gaat dan los ik dat achteraf wel op (is me nog nooit overkomen).

Dat is mooi, maar eigenlijk moet je voor deze bug ook nog een keertje rebooten.

t mooie van opensource is dat het meteen gefixed word...

Yep, bij Windows moet je vaak wachten tot de volgende "patch tuesday" omdat Microsoft veel (in mijn ogen belangrijke) patches als niet-essentieel betekend.

Het verschil tussen MS en Ubuntu is dat de programmeurs volgens een verschillend principe werken. Bij Microsoft gaat dat volgens een strak schema terwijl de Linux community gewoon zo snel mogelijk probeert om het probleem op te lossen. Het komt dan wel eens voor dat een patch in eerste instantie slechts gedeeltelijk werkt, maar dat is altijd beter dan lang zonder bescherming zitten. Het perfectioneren kan altijd nog.

De Linux gemeenschap is simpelweg sneller vanwege de dynamische werkwijze. Ik weet ook niet hoeveel programmeurs Microsoft in dienst heeft en of dit er meer of minder zijn dan bij grote Linux-distro's als Ubuntu. Daarbij komt dat een Ubuntu patch ook vaak op forks geïnstalleerd kan worden zoals Linux Mint en Moon OS. Je hoeft de betreffende library dus veelal maar 1x te herschrijven.

[Reactie gewijzigd door Titan_Fox op 27 januari 2015 22:13]

Bij Microsoft gaat dat volgens een strak schema terwijl de Linux community gewoon zo snel mogelijk probeert om het probleem op te lossen. Het komt dan wel eens voor dat een patch in eerste instantie slechts gedeeltelijk werkt, maar dat is altijd beter dan lang zonder bescherming zitten. Het perfectioneren kan altijd nog.

De Linux gemeenschap is simpelweg sneller vanwege de dynamische werkwijze.

Dat is toch wel de grootste bull* die ik dit jaar op tweakers gelezen heb.

Of een patch gedeeltelijk werkt danwel later te perfectioneren is is niet waar bedrijven mee zitten. Die zitten met de continuiteit van hun bedrijfsvoering en dus hun inkomsten. Je kunt discussieren of dat een wenselijke situatie is, maar geen geld hebben om de huur te kunnen betalen vinden medewerkers van die bedrijven in ieder geval zeer onwenselijk. Aan het einde van de dag moeten die patches gewoon getest worden, wil een bedrijf voorkomen dat het door een foutieve patch stil komt te liggen. Het patch schema van MS is een van de mogelijke aanpakken om dat testen behapbaar te houden. Eentje die overigens na grote vraag vanuit de bedrijfswereld is ingevoerd door MS.

Op distributies als RHEL/CentOS wordt er wel degelijk uitgebreid getest, moge dat wel duidelijk zijn. Heb maar 1 keer meegemaakt dat een patch voor een probleem slechts 1 van de 2 gaten dichtgooide. Binnen 30 minuten lag de 2e patch klaar. (Dat was de bash bug; shellshock.)

Maar er wordt zeker wel zeer uitvoerig getest of de werking goed is, er geen problemen ontstaan met andere software, instabiliteit veroorzaakt, et cetera; want die distro's hebben een reputatie hoog te houden. En toch zijn ze over het algemeen veel en *veel* sneller dan Microsoft. Bij hele moeilijke patches waar veel haken en ogen aanzitten (ook om te testen omdat het andere software mogelijk zou kunnen breken) is meestal binnen enkele dagen een patch beschikbaar en in omloop.
Bij makkelijk te fixen zaken is het vaak binnen minuten tot uren gefixed...

... En daar heeft het bedrijfsleven natuurlijk ook wat aan.
En dat is denk ik de dynamiek waar titan_fox het over had.
Ik kan me niet vinden in het beeld dat hij heeft van "zo snel mogelijk oplossen terwijl 't maar deels werkt". Misschien in rolling releases zoals Fedora en Ubuntu, maar niet in de production "stable" OS'es zoals CentOS/Debian/FreeBSD, etc..

Fedora en Ubuntu zijn niet rolling. Arch en gentoo zijn rolling.

Ik had het met name over de Bash-patch die eind vorig jaar werd uitgebracht voor Linux. Ze hadden er toch 2 of 3 pogingen voor nodig om het probleem geheel op te lossen omdat er toch gebruikers waren die na de eerste patch nog steeds kwetsbaar waren.

Soms moet een patch heel snel worden uitgebracht om een lek te kunnen dichten. Door de versplintering van het Linux-ecosysteem kan het dus gebeuren dat niet iedereen gabaat is.

Dat is toch wel de grootste bull* die ik dit jaar op tweakers gelezen heb.

Of een patch gedeeltelijk werkt danwel later te perfectioneren is is niet waar bedrijven mee zitten. Die zitten met de continuiteit van hun bedrijfsvoering en dus hun inkomsten.

Je hoeft patches niet onmiddelijk te installeren, maar je hebt de keuze om dat wel te doen. Omdat alle code en de communicatie daar over open is kun je als IT'er veel beter beoordelen hoe belangrijk een bepaalde patch voor jouw organisatie is en welke risico's je neemt.

[Reactie gewijzigd door CAPSLOCK2000 op 28 januari 2015 02:09]

Bedrijven zitten ook relatief vaak bewust op oude systemen te werken en nemen een breuk op de koop toe omdat de omzet veel zwaarder weegt dan een incidentele hack wat statistisch gezien toch wel een keer moet gebeuren.Om het maar niet te hebben over brakke in house oplossingen.

Of je een patch installeerd of niet wordt je niet door Microsoft opgedrongen.Microsoft kan rustig veel sneller patches uitbrengen zonder dat een bedrijf genoodzaakt is om het tempo aan te passen.Een beetje bedrijf heeft een of meerdere update servers in het netwerk staan.Als Microsoft binnen twee dagen een patch heeft dan kun jij rustig de resterende 88 dagen gaan testen.

Bovendien erkend Microsoft zelf dat windows update verre van ideaal is.Niet voor niets gaat zij waarschijnlijk een splitsing gaan doorvoeren.

Waarom moet iemand op een desktop langer wachten opdat de bedrijven eerst moeten testen?

Oke, MS pushed regelmatig updates buiten de patch tuesdays, afhankelijk of MS de exploit in het wild ziet of niet.
Dit is trouwens gekomen naar aanleiding van het enorme gezeik van "bijna,dagelijks windows moeten updaten" een argument wat voornamelijk uit de Linux wereld geschreeuwd werd. Komisch want meeste Linux distros hebben elke paar dagen of bijna dagelijks patches, en sinds MS is begonnen met patch tuesday is het dagelijks patchen op geheel magische wijze ineens een pluspunt......

MS heeft idd een dikke bureaucratische laag waar MS hun eigen devs ook over klagen. Maar er hebben 10duizenden mensen toegang tot de Windows broncode. Maar het security team van Windows staat los van de main developers.

Tevens bied MS de patches die wachten op patch tuesday gewoon aan als hotfix en kan je die altijd handmatig downloaden zodra ze klaar zijn.

En boeiend dat patches op forks werken, een windows 8 patch werkt 9/10 keer ook op windows 2012 en vice versa. In tegenstelling tot meeste FOSS OSen, ondersteund MS rustig een 10jaar oude versie.
Overigens komt het meeste in Ubuntu, inclusief de patches 9/10 keer van Debian af. Altijd Ubuntu zo op een stoel dragen

Dit is trouwens gekomen naar aanleiding van het enorme gezeik van "bijna,dagelijks windows moeten updaten" een argument wat voornamelijk uit de Linux wereld geschreeuwd werd.

Ja mooi niet, het updaten is geen probleem maar het telkens moeten rebooten wel.En laat dat juist lang altijd niet hoeven bij *nix snappie?

Precies ! Ik hoef enkel opnieuw op te starten bij een update van de kernel. De rest van de tijd krijg ik gewoon een melding "Het systeem is nu up-to-date".

Kijk ook maar eens hoe lang je bij Windows bezig bent om een schone Windows 7 installatie op de nieuwste stand te krijgen. Daar ben je op sommige systemen enkele uren mee bezig en moet daar diverse keren opnieuw opstarten. Vooral de .NET updates duren heel erg lang, die je nodig hebt om bijvoorbeeld AMD's Catalyst drivers te installeren. Daarbij moet je ook nog tijdens het afsluiten of opstarten wachten tot bepaalde updates worden geïnstalleerd.

Bij Ubuntu ben ik binnen 10 minuten klaar en hoef ik slechts 1x opnieuw te starten. Bovendien hoef ik niet te gaan zoeken naar driver-updates e.d. omdat tot nog toe alle apparaten out-of-the-box werkten. Bij een schone Windows 7 installatie werkt vaak de netwerk en/of WLAN driver niet, die je weer m.b.v. een andere PC moet downloaden en met een USB stick moet overzetten (nadat je hebt uitgezocht welke je moet hebben) alvorens je je Windows-updates kunt installeren.

Nee, bij Ubuntu snappen ze beter hoe systeemupdates horen te werken.

[Reactie gewijzigd door Titan_Fox op 28 januari 2015 09:48]

Dat moeten rebooten is een afweging tussen risico en gemakzucht. De NT kernel kan net als Linux on the fly zijn modules loaden, unloaden en updaten. Het is geen technische beperking.
Om deze bug/exploit te fixen is op Linux ook aan te raden te rebooten ook al "moet" het niet.

To each their own, mijn debian herstart ik ook als er een dikke batch updates word geïnstalleerd. Al genoeg meegemaakt dat live updaten de boel verneukt heeft.

Steeds maar dat update-reboot argument, en nog een +2 krijgen ook.lol

Er is anders nog geen fix voor CentOS

Is er wel, maar moet nog naar de mirrors gepushed worden.

Is er voor Red hat idd al wel beschikbaar (op de mirrors) maar voor CentOS nog niet, en ook glibc zelf update heeft nog geen nut.
http://ma.ttias.be/critic...0235-gethostbyname-calls/

[Reactie gewijzigd door xleeuwx op 27 januari 2015 22:22]

CentOS 5 is ondertussen wel gepatched zo te zien.
Waarom 6 & 7 nog achterlopen is even een raadsel, maar hopelijk krijgen die ook spoedig hun patches. Vooral 6 heeft tegenwoordig, dacht ik, een groter marktaandeel gekregen dan 5.

6 en 7 zijn ook gepatched:
https://twitter.com/CentOS/status/560138182441070592

"Building" is helaas niet 't zelfde als "fixed".
De updates zijn dus nog steeds niet naar de mirrors gepushed omdat de pakketen niet klaar zijn, in tegenstelling tot CentOS 5.

Naja, ik moet maar wat meer geduld hebben denk ik.
Het zal binnen nu en een uurtje wel op de repositories beschikbaar staan lijkt me.

Vreemd, ik zie ook nog geen update voor CentOS5, waar twee servertjes van me op draaien. Misschien dat mijn mirror toch nog niet bijgewerkt is...

[Update] Krijg nu net pas de mailing list melding binnen. Zal dus zo wel overal binnenkomen.

[Reactie gewijzigd door eborn op 28 januari 2015 00:08]

Kan. Veel mirros sync'en om de 4 of 6 uur hun content. Vraagt de CentOS tier1 ook van je om de servers aldaar niet te hard te stressen.

Ze vragen zelfs vaak of je van tier2 machines wil trekken, dan heb je met pech 12 uur later je zooi....

Ondertussen krijg ik ze overal binnen, trouwens.
Even "yum clean all" als ie nog blijft mekkeren dat er niets te updaten valt.

Het probleem is een beetje dat het al twee jaar geleden is gefixed...

Volgens mij is dit een storm in een glas water. De security clubs als Qualys moeten hun bestaansrecht wel bewijzen...

Het gaat hier over een gethostbyname_r() (is al IPv4 only) op een hostnaam die leeg (!) is. Dat kan alleen als de eindgebruiker dit in kan voeren en 1:1 naar glibc zou gaan. Veel programmeurs zullen nog eerst controleren of name niet leeg is (name != NULL && *name != '\0'). Hoop ik dan.

En dan nog: je krijgt hiermee niet zomaar root rechten. Je kunt nooit meer data overschrijven dan dat je mag (anders krijg je een segmentation fault, je mag niet buiten je eigen adress space wat wijzigen).

Kortom: dit is een beetje telegraaf stijl. Kijk eens wat we gevonden hebben !!!. Het is inderdaad iets dat fout is, maar ik zou eerst een CVE classificatie willen zien hoe ernstig het is. Mijn inschatting is dat het niet verder komt dan tot medium impact.

Gezien de reacties van diverse distro's met directe patches zal het geen storm in een glas water zijn. Als je zelf al twijfelt geeft het al aan dat je er (nog) niet genoeg over weet.

Je wensdenken / aanname dat veel programmeurs controleren of een hostname leeg is is ook geen goede attitude met betrekking tot security.

Betreft CVE kwallificatie, kost je 10 seconden googlen> https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235

Priority urgent
Severity urgent

Dat er zoveel reacties komen is logisch; zo beperk je imago schade. Het zegt niet noodzakelijkerwijs iets over de ernst van het lek.

Het lek is slechts enkel als ernstig te bestempelen als root processen een gethostbyname() aanroepen. Gezien de brede support van IPv6 in Linux verwacht ik niet dat er veel van deze aanroepen zullen zijn. Zolang je geen root bent, is de impact van een buffer overflow veel kleiner. Je komt zeer zeer zelden uit je eigen rechten boom. Root worden is m.i. bijna onmogelijk op deze wijze.

Ik heb niet uitgezocht of getaddrinfo() uiteindelijk op dezelfde functie uitkomt.
Ik had geen tijd genomen om de CVE op te zoeken.

En attitude: ach, dat is wel een zwaar verwijt. Als je een publieke interface hebt, dan check je 1x op valide input. Low level, non-public functies herhalen die check niet uitentreuren. Code moet ook performen.

Er zijn nog best veel distro's niet gepatcht.

Debian 6 (met Long Term Support, dus squeeze-lts) nog niet, raspbian ook niet (ondanks dat er wel een nieuwe glibc werd geïnstalleerd met de laatste update). Best slecht

Ben wel benieuwd wanneer LTS een patch krijgt. Ik denk dat veel mensen toch op die versie zijn blijven hangen, puur omdat het kan. Updates ontvangen is voor veel productie servers toch altijd iets fijner dan een complete upgrade. Helemaal als je afhankelijk bent van oudere PHP versies.

In Debian 7 is het blijkbaar vanmiddag gefixt: https://lists.debian.org/debian-security-announce/2015/msg00025.html

Na het lezen van dit bericht ook gelijk maar even gecheckt op mijn Ubuntu 12.04. Bleek toch kwetsbaar te zijn. Inmiddels gelukkig zelf handmatig gefixed!
Mocht je bij apt-get update geen nieuwe glibc binnenkrijgen, ga zelf in synaptic Pakketbeheer de laatste versie binnenhalen. Zoek naar libc6 2.15-0ubuntu10.10

Ik heb begrepen dat de updates voor CentOS zolang op zich hebben laten wachten (meer dan 5 uur) omdat de meeste van de personen die deze kunnen signen momenteel onderweg zijn naar een conferentie (FOSDEM). Ook wel apart toch.

Daarnaast ook het vermelden waard: het artikel was onder embargo om nog niet gepubliceerd te worden maar een Franse dame van een of ander bureau heeft het te snel online gezet... die beleeft nu ook vast de dag van haar leven

Zonet ook een hoop servers geupgrade, gaf de allerlaatste natuurlijk een (unrelated) kernel panic na de reboot Gelukkig snel gefixt.