Nieuwe fout in Zlib treft groot aantal applicaties

Er is een gemene beveiligingsfout ontdekt in de code van de compressiebibliotheek Zlib. De routines worden in heel wat programma's gebruikt, waaronder Microsoft Office en The Gimp, veelal om plaatjes van het bestandsformaat 'png' te hanteren. Vooral Linux- en BSD-applicaties maken gebruik van deze open-sourcebibliotheek. Tavis Ormandy, lid van het Gentoo Linux Security Audit Team, ontdekte dat in de decompressieroutine de ingevoerde data niet wordt gecontroleerd, waardoor met de juiste tekenreeks een buffer overflow kan worden uitgevoerd.

Het patchen van de bibliotheek is in Linux en BSD redelijk eenvoudig. Op deze besturingsystemen staat maar een exemplaar van Zlib, waarnaar de programma's die ervan gebruik maken dynamisch linken. Gebruikers van dit besturingssysteem hoeven alleen een fix toe te passen op een bestand. In andere besturingsystemen wordt de bibliotheek statisch gelinkt, wat inhoudt dat ieder programma een eigen exemplaar van de bibliotheek bezit. Hier moeten gebruikers voor ieder programma apart een patch bemachtigen om het lek te kunnen dichten.

Mark Adler heeft laten weten dat er binnenkort een nieuwe versie van Zlib uit zal komen, waarin de bug opgelost is. Voor veel open-sourcebesturingsystemen, waaronder Gentoo, Ubuntu en FreeBSD, zijn al patches beschikbaar die de fout in de programmacode kunnen herstellen. In 2002 had Zlib ook al met een kritieke kwetsbaarheid te kampen. Toen betrof het een fout in het toewijzen van geheugenplaatsen. Afgelopen september kwam ook een soortgelijk probleem aan het licht toen er een bug in de bibliotheek voor jpeg-compressie werd ontdekt die een bufferoverflow kon veroorzaken.

Reacties (29)

[Mayco]

Inderdaad, dat is de 4e juli al gepatcht in mijn ubuntu, mooi toch, opensource?
-> http://lists.ubuntu.com/archives/breezy-changes/2005-July/007717.html

[Brent]

Ook Hoary kwam hier vanmorgen netjes met een update-melding

[sid3windr]

Vergeet ook de Linux kernel niet te vermelden als gebruiker van zlib

[Verwijderd]

Het patchen van de bibliotheek is in Linux en BSD redelijk eenvoudig. Op deze besturingsystemen staat maar een exemplaar van Zlib, waarnaar de programma's die ervan gebruik maken dynamisch linken. Gebruikers van dit besturingssysteem hoeven alleen een fix toe te passen op een bestand. In andere besturingsystemen wordt de bibliotheek statisch gelinkt, wat inhoudt dat ieder programma een eigen exemplaar van de bibliotheek bezit. Hier moeten gebruikers voor ieder programma apart een patch bemachtigen om het lek te kunnen dichten.

Hieruit blijkt maar weer dat microsoft gelijk heeft met de stelling dat windows goedkoper te beheren is dan een linux machine. Je hoeft bij windows alleen alle applicaties te vervangen die gebruik maken van die library.

En op een linux machine hoef je alleen de zlib library te vervangen.

Goede PR is niet hetzelfde als de praktijk blijkt maar weer.

[Verwijderd]

DLL's in Windows zijn ook gewoon dynamisch, en als de gebruiker zo slim geweest waren de al bestaande DLL versie van ZLib te gebruiken i.p.v. statisch te linken, was er geen enkel probleem geweest in Windows.

Overigens is er geen enkele garantie dat op Linux/BSD's ZLib ALLEEN maar dynamisch gebruikt wordt, technisch is zowel dynamisch als statisch mogelijk, soms is het ivm compatibility problemen of beveiligings risico's (een dynamische library is makkelijker te hacken) zelfs aan te raden libraries statisch te linken.

Wat dit punt betreft verschillen Windows/*nix niet wezenlijk (behalve dat de gemiddelde *nix ontwikkelaar wat meer aandacht besteed aan dit soort punten), dus om hier Windows op af te kraken is onjuist.

[Verwijderd]

Waar slaagt die stelling op?
Als je op een Unix systeem enkel de zlib moet patchen en alle programma's zijn ook gepatched en beveiligd tegen deze exploit. Dan is het toch juist omgekeerd en zijn Unix systemen makkelijker te onderhouden dan windows systemen.
Want in een windows systeem zou je elk programma dat die zlib gebruikt moeten gaan patchen.
Lijkt mij veel meer werk dan 1x die zlib te patchen bij Unix systemen.

[twiFight]

sar·cas·me (het ~)
1 bittere, bijtende spot

Niet aan iedereen besteed blijkbaar

[kidde]

Euhm, dat was cynisch bedoelt van Bill Gaetes voor jou, hij bedoelde hetzelfde als jij

[chielsen]

Hoe zit dat met php, die maakt toch ook gebruik van een zlib module?

[TheAnimaL]

php maakt gebruik van de zlib library. Is de library gepatched, dan kan de fout vanuit php ook niet meer ge-exploit worden.

Prachtig toch die UNIX achigen? Bijna voor alle unices is er een aantal dagen na ontdekken van de fout een patch beschikbaar. Hopla, "apt-get update && apt-get upgrade" en klaar is kees voor het hele systeem ( op debian en derivaten dan ).

[84hannes]

En tot die patch er is is praktsich ieder programma dat je gebruikt kwetsbaar, in tegenstelling tot closed source programma's die de neiging hebben t wiel telkens zelf uit te vinden.

[_JGC_]

in tegenstelling tot closed source programma's die de neiging hebben t wiel telkens zelf uit te vinden.

Nee, die nemen gewoon de statische versie van een lekke zlib en compileren dat statisch in hun programma. MS doet dit, Mozilla doet dit, etc. Alles statisch compileren, lekker grote binaries, want windows heeft alleen .dll, wat een ergernis is tov de veel betere .so.x die gebruikt wordt op unix systemen. Installeer maar eens 2 verschillende versies van een DLL die incompatible zijn, maar toch dezelfde .dll meeleveren, lukt je alleen met statisch linken of ergens in een searchpath voor c:\windows\system neer te zetten.

Aangezien het BSD licentie is, zal je ook geen spoor van zlib terugvinden in de documentatie van een closed source programma en mag je maar raden of je vatbaar bent voor de bug, want je weet immers niet of je o zo veilige closed source software nou wel of niet statisch een zlib library heeft ingebakken...

Edit: Flame tegen BSD licentie niet, feit is gewoon dat veel mensen gewoon de BSD licentie uitbuiten alsof het gewoon niet bestaat. Zelfs de GPL overkomt dit soort praktijken vaak genoeg, echter staat de BSD licentie zoals gebruikt in zlib dit gewoon toe. Het is eerder een flame tegenover de bedrijven die zonder kennisgeving de BSD licentie uitbuiten.

[Verwijderd]

zlib wordt ook in heel veel closed source programma's en libraries gebruikt, aangezien het een kleine, efficiente en minimale compressie library is. Dit mag omdat het onder een BSD achtige licentie is vrijgegeven.

[Michael]

Aangezien het BSD licentie is, zal je ook geen spoor van zlib terugvinden in de documentatie van een closed source programma en mag je maar raden of je vatbaar bent voor de bug, want je weet immers niet of je o zo veilige closed source software nou wel of niet statisch een zlib library heeft ingebakken...

Dat ligt er maar net aan welke versie van de BSD licentie gebruikt word. De 4-clause BSD licentie verplicht het programma om te melden dat er gebruik gemaakt is van de code. De 3-clause, welke zlib gebruikt, echter inderdaad niet

Je reactie komt in iedergeval een beetje flamerig over ten opzichte van de BSD licentie.

[Olaf van der Spek]

die de neiging hebben t wiel telkens zelf uit te vinden.

Als je dat doet heb je nog veel en veel meer kans op gaten in de beveiliging.

[Sir_Eleet]

Reactie op Jan de Groot

Hoezo BSD licentie uitbuiten? Je zegt het zelf ze doen gewoon wat de licentie toestaat, daar is niks mis mee. Als je een software uitgeeft onder de BSD licentie weet je dat dit kan gebeuren en dan moet je achteraf niet klagen dat het in closed source software gebruikt wordt. Dat OSS profeten daar niet blij mee zijn is een andere zaak.

[Olaf van der Spek]

dist-upgrade werkt iets beter dan upgrade
En "@daily apt-get -qq update && apt-get -dqq dist-upgrade && apt-get -sqq dist-upgrade" in root's crontab is ook handig, dan worden updates automatisch gedownload en krijg je een email als er updates zijn zodat je ze kunt installeren.

[The Noid]

nog makkelijker:
apt-get install cron-apt

[martijnvanegdom]

Heeft Microsoft al een patch uitgebracht..??

mm.. opensource is toch sneller.......

[ILUsion]

Dat Windows op meer plaatsen gepatcht moet owrden, hangt niet helemaal vast aan het closed-sourcekarakter van Microsoft. Dat hangt gewoon vast aan de beslissing van de meeste devvers om zo veel mogelijk benodigdheden in hun binaries in te steken. Dat zorgt ervoor dat je relatief weinig problemen hebt met afhankelijkheden in Windows. Jan Modaal koopt een cd, opent de executable en het werkt in 95% van de gevallen, dus is hij blij.

In Linux heeft men ervoor gekozen om zo veel mogelijk met kleine modulletjes of libraries. Bij het installeren kan dit vaak wel problemen geven omdat je het een of ander bouwsteentje niet hebt en die bouwsteentjes zijn ook weer gebaseerd op andere bouwstenen, enzovoorts. Het voordeel is dat je bij een fout of een andere verbetering aan één functie, je slechts op één plaats moet aanpassen dus zijn aanpassingen wel degelijk mogelijk.

Als je in elke binary statisch een functie oproept, moet je dus honderden of duizenden binaries gaan aanpassen als je in een kleine functie een verbetering gaat toevoegen. En dan moet je je indenken dat programma's niet op één enkele library gebaseerd zijn, dus voor elke wijziging aan een library zou je in het beste geval een andere binary moeten compileren.

Dat voordeel heeft Linux en de rest van Unix dus door met kleine bouwstenen te werken en Windows heeft dat voordeel minder (daar heb je inderdaad wel DLL's maar echt handig zijn ze toch niet beheerd). Maar dat heeft heel weinig met open/closed source te maken. Het enige dat je kan toeschrijven is dat oepn-source meer geneigd is om functies publiekelijk te beschrijven en beschikbaar te maken voor anderen, terwijl closed-source meer de idee heeft om zelf je ontwikkelingen voor jezelf te houden.

Of het ene of het andere nu beter is, laat ik in het midden; vanuit gebruiksgemak is het eerste het beste omdat je executables hebt die 'altijd' werken. Vanuit technisch punt is het tweede natuurlijk beter.

@martijn vanegdom en whizzwhizz:
Hou in het vervolg dus jullie trolls voor je, alsjeblieft. Microsoft kan trouwens niet zelf al die patches afleveren, maar dat moet voor ieder programma gebeuren.

Dit was enige tijd geleden ook al het geval met een fout in GDI+ waarbij veel programma's gepatcht moesten worden.

[DwarV]

Ook voor debian sarge is er sinds gister een patch beschikbaar

*edit*
@Sid3WiNDR betreffende kernel is 2.4.30

[Verwijderd]

Update is ook voor Fedora Core gebruikers beschikbaar via yum update
Update: zlib.i386 0:1.2.1.2-2.fc3 - updates-released
Update: zlib-devel.i386 0:1.2.1.2-2.fc3 - updates-released

[DwarV]

Je hoeft bij windows alleen alle applicaties te vervangen die gebruik maken van die library.

Maak jij dan per machine een lijst van de software die die library gebruikt??
Hoe dan ook is het microsoft met de in het artikel genoemde probleem met de jpeg library ook gelukt om alles te patchen.

Ik mis in de eerder genoemde opsomming an ook APPLE.

In de eerder genoemde opsomming is apple niet van belang, aangezien (naar ik mij meen te herinneren) de modernere versies van Mac OS op een *nix achtig systeem draaien (darwin toch?) Zij zouden in theorie dus ook door 1 enkele patch van dit probleem kunnen worden verlost.

[RedPixel]

Gelukkig heeft Windows over 6 maand ook een update klaarliggen

[Martinus]

is emule nu ook fukked?