Veelgebruikte libpng-bibliotheek is kwetsbaar door bug - update

Er is een kwetsbaarheid vastgesteld in de libpng-bibliotheek. De eerste patch is voor een aantal versies beschikbaar. De bibliotheek zit echter in veel toepassingen en het zal niet eenvoudig zijn de kwetsbaarheid overal te herstellen.

Libpng-custodian Glenn Randers-Pehrson heeft een cve voor de kwetsbaarheid aangevraagd onder nummer CVE-2015-8126. Het zou gaan om een buffer overflow waarmee aanvallers met gemanipuleerde png-afbeeldingen applicaties kunnen laten crashen en kwaadaardige code kunnen uitvoeren. Wanneer png-bestanden met een bitdiepte van minder dan 8 worden gelezen of geschreven, ontbreekt er een check voor geldige waardes waardoor een crash kan optreden. De kwetsbaarheid heeft een cvss-score van 7,5 uit 10 en is via het netwerk uit te voeren.

Het is een problematische bug omdat libpng aanwezig is in zo goed als elke applicatie die png-afbeeldingen verwerkt, waaronder browsers, muziekspelers en spellen. Een andere factor is het feit dat er geen centrale versie van libpng is die in een keer aangepast kan worden. Veel programma's gebruiken hun eigen versie van de bibliotheek. Het zal dus geruime tijd duren tot de kwetsbaarheid in alle systemen is opgeheven. Voor versies 1.6.19, 1.5.24, 1.4.17, 1.2.54, en 1.0.64 van libpng is een patch uitgebracht.

De term cve staat voor 'common vulnerabilities and exposures'. Dit is een database waarin kwetsbaarheden in systemen en netwerken worden bijgehouden en een nummer toegewezen krijgen.

Update: Het blijkt dat een aantal applicaties niet getroffen zijn door deze kwetsbaarheid. Het gaat hierbij om PHP en Google-producten als Android, Chrome OS en Chrome. De laatste drie maken gebruik van de Skia-bibliotheek. Hetzelfde geldt voor Firefox en Firefox OS.

Reacties (101)

Na een korte zoektocht op google zie ik dat Android ook gebruik maakt van libpng, dit zou dus betekenen dat in elke simpele app in de Play Store gebruik kan worden gemaakt van deze exploit. Ik ben benieuwd hoelang het gaat duren.

Zie https://android.googlesou...ibpng/+/master/Android.mk

En: https://android.googlesou...orm/external/libpng/+refs

Op de laatste link is te zien dat het in zo'n beetje elke Android versie wordt gebruikt dus dit gaat echt een groot probleem worden.

[Reactie gewijzigd door benjamin94 op 16 november 2015 11:19]

Android gebruikt Skia, en zover ik heb gelezen is Skia niet kwetsbaar. Onder andere Google Chrome, Chrome OS, Chromium OS, Mozilla Firefox, Android en Firefox OS gebruiken Skia.

Het probleem onstaat als mensen te weinig geheugen toewijzen voor het kleurenpallet in het png bestand, omdat ze de bitdiepte voor het pallet rechtstreeks uitlezen, en er een groter pallet in het bestand kan zitten.

1. Een hoop applicaties zijn echter 'lui', en wijzen altijd geheugen toe voor een volledig pallet van 256 kleuren.
2. Daarnaast is er een grootte groep (misschien wel de grootste) die png_get_PLTE gebruiken om de palletgrootte te bepalen. Deze zijn dus ook niet kwetsbaar. Onder andere PHP met libgd doet dit.
3. Een aantal andere applicaties gebruiken een totaal andere manier om de palletgrootte te bepalen, en zijn dus ook niet kwetsbaar. Skia valt hieronder.

EDIT: hier is de betreffende code: https://android.googlesou...ec/SkCodec_libpng.cpp#171
EDIT2: foutje met png_get_PLTE , png_get_PLTE is wel veilig. Het is de IHDR chunk die onveilig is.
EDIT3: PHP is veilig https://github.com/libgd/...79fcc24/src/gd_png.c#L321

[Reactie gewijzigd door AtoxHybrid op 16 november 2015 13:45]

Oppassen met de informatie die je hier verspreidt, Skia gebruikt ook gewoon libpng dus dat is geen garantie dat het niet kwetsbaar is. Voor zover ik kan zien is Skia master gefixt in Maart 2015 in deze commit:(https://android.googlesou...64a89fa7207195d1a79efc0c3)

Maar genoeg google applicaties, telefoons, etc. zullen niet op een skia master zitten van na 2015.

Firefox gebruikt Skia op sommige platformen wel voor rasterisatie, maar nooit voor image decoding. Firefox gebruikt libpng direct, maar doet voor zover ik kan zien geen allocaties op png_get_PLTE (tenminste niet op release), en is dus niet kwetsbaar.

Hiervoor alloceerde skia ook gewoon altijd ruimte voor 256 kleuren, dus was ook niet kwetsbaar. Firefox zal ik nog even in gaan duiken.

Tot nu toe heb ik nog geen enkele kwetsbare applicatie gevonden (ze zijn er ongetwijfeld, maar waarschijnlijk niet veelvoorkomend). Alleen applicaties die de bitdiepte van het pallet rechtstreek uit de IHDR chunk lazen en vervolgens libpng gebruikten om het pallet uit te lezen zijn kwetsbaar. Normaal gebruik je natuurlijk libpng om het aantal kleuren te bepalen, en niet rechtstreeks. Als je het wel rechtstreeks bepaald zul je waarschijnlijk je eigen library gebruiken, en ben je dus ook niet kwetsbaar. Hoe dan ook lijkt het voorlopig mee te vallen.

EDIT: Firefox is niet kwetsbaar: https://bugzilla.mozilla.org/show_bug.cgi?id=1224244#c0

[Reactie gewijzigd door AtoxHybrid op 16 november 2015 18:12]

Je hebt gelijk. Skia moet je inderdaad nog een stuk verder terug om voor de workaround te zitten. En zelfs toen lijkt het niet dat het echt tot een exploit zou kunnen leiden inderdaad.

Neemt niet weg dat Skia niet gebruikt wordt voor image decoding in Firefox of Firefox OS .

Update: Ik heb nog eens even gekeken naar Skia van voor Maart. Maar hoewel daar altijd 256 werd geallocate werd is de write die vervolgens gedaan werd voor zover ik kan zien niet gecapped op 256. Wellicht dat er dus wel degelijk een mogelijkheid voor een OOB write/read bestond. Wellicht dat ik het niet juist zie, maar op het eerste gezicht zie ik niet met zekerheid dat dit veilig is. De kwetsbaarheid beperkt zich hier niet tot de allocatie.

[Reactie gewijzigd door BasSchouten op 16 november 2015 19:52]

Een palette in png kan nooit meer dan 256 kleuren bevatten. Deze bug gaat dan ook over wanneer er bijvoorbeeld 16 kleuren (bit depth 4) worden aangekondigd maar er wordt een palette van 256 kleuren (bit depth 8 ) meegeleverd. In dat geval gaan er 240 kleuren out-of-bounds. Daarom is simpelweg 256 kleuren alloceren een simpele, veelgebruikte en veilige oplossing.

EDIT: Ik ga er vanuit dat de correctheid van de palette, en dus de grootte kleiner dan of gelijk aan 256 kleuren, ergens anders gecontroleerd wordt. De CVE heeft het ook alleen over minder dan 8 bits.

[Reactie gewijzigd door AtoxHybrid op 16 november 2015 20:28]

Ja. Het zou kunnen dat die controle er is. Alsnog kwalijk dat de array fixed size op de stack gezet wordt en dat vervolgens de write niet expliciet gelimiteerd wordt waar die gebaseerd wordt op een return value uit een externe API.

Als ik het artikel zo lees gaat het over véél meer dan alleen Play Store apps. Namelijk ook over automatisch gedownloade albumcovers (die mogelijk ook de server kunnen infecteren), de images die door de appstores geladen worden voordat je de app download, reclames en andere plaatjes op websites. Oftewel libpng is zo breed ingezet dit valt misschien wel in dezelfde klasse als de heartbleed bug.

Waarbij de Play store dan 'gelukkig' nog iets is wat door Google aangepakt kan worden. Er vanuit gaande dat je deze foute afbeeldingen kunt herkennen, kan Google voordat je afbeeldingen voor je app upload een validatie uitvoeren. Uiteraard is dat een lapmiddel. Maar dat voorkomt wel het grootste probleem, waarbij wilekeurige zoekopdrachten in de store een exploit kunnen triggeren.

Uiteraard er vanuit gaande dat het openen van een afbeelding op Android al voldoende is en je dan ook echt iets kunt. Ik weet bijvoorbeeld niet onder welke user Google Play standaard draait en welke rechten die user heeft.

Apple gebruikt ook libpng voor zowel Max OS X als iOS.
Voor zever ik hier (http://www.apple.com/opensource/) kan zien gebruiken ze geen versie waar een patch voor is, maar dat zal wel prima te poorten zijn.

Het is dus eigenlijk een mooie cross-platform exploit. In Windows zal het ook zitten dmv browsers.
Dus het gaat interesant zijn om te zien hoe snel de patches uitrollen.

"mooi"... Beetje ongelukkig verwoord

99% van de applicaties die PNG kunnen lezen en schrijven maken gebruikt van LibPNG.
PNG is namelijk geschreven bij een groepje Nerds al jaren geleden uit een aantal bestaande libaries en wat zelf geschreven code. Hoe PNG werkt is goed beschreven, maar de kleine implementatie details zoals de bits in de compressie-database niet.

Hierdoor is het niet mogelijk om zelf een 100% compatible PNG read/writer op te zetten. Ook bevat de code nog erg veel 16-bit instructies en andere legacy meuk, omdat het onmogelijk is iets uptedaten zonder dat je iets breekt.

Onmogelijk is het niet, het kost alleen wat tijd

99% van de applicaties die PNG kunnen lezen en schrijven maken gebruikt van LibPNG.
PNG is namelijk geschreven bij een groepje Nerds al jaren geleden uit een aantal bestaande libaries en wat zelf geschreven code. Hoe PNG werkt is goed beschreven, maar de kleine implementatie details zoals de bits in de compressie-database niet.

Libpng doet zelf niet aan compressie, daarvoor gebruikt het zlib. Beide zijn uitstekend gedocumenteerd.

Hierdoor is het niet mogelijk om zelf een 100% compatible PNG read/writer op te zetten.

Bullshit. PNG zit heel simpel in elkaar. Hoe weet ik dat? Ik heb ooit een programma gemaakt wat de iPhone 'Crushed' PNGs omzette naar normale PNGs en dat moest met de hand aangezien libpng ze niet snapte.

Ook bevat de code nog erg veel 16-bit instructies en andere legacy meuk, omdat het onmogelijk is iets uptedaten zonder dat je iets breekt.

Ook bullshit aangezien libpng cross-platform is en ook prima draait op niet-intel architecturen. Het is geschreven in C, niet in assembler.

99% van de applicaties die PNG kunnen lezen en schrijven maken gebruikt van LibPNG.

Is dat zo?
Bijvoorbeeld .NET gebruikt toch een eigen PNG bitmap encoder of decoder class

Je reactie doet vermoeden dat je denkt dat dit een unieke situatie is. Echter als je opzoekt welke gaten er in graphics libraries als libpng (libjpeg enz) zitten en hoe ze gebruikt zijn (jailbreaken/rooten van devices) is dit geen verassing. Deze libs zijn zeer populair en worden op zowat alle platformen gebruikt.

Zelfs in mijn eigen C++ game engine gebruik ik libPNG met aanpassingen..
Ik hen gelukkig libPNG uitgeschakeld en een andere importer/exporter gebruikt.

Waarom gebruiken apps dan geen 'centraal' pakket? Als ik zo in de repo's kijk worden deze door diverse (Linux-)distro's geleverd.
Waarom zou je dan toch nog een eigen versie meeleveren, als je ook op de package-manager kan vertrouwen (die libs bijhoudt)? Als bijvoorbeeld een versie vereist is, kan je deze nog altijd in een (custom)repo aanbieden, i.p.v. los 'erbij gooien'. Maar begrijp dat dit voor Windows, Apple, Android, etc. iets moeilijker is te realiseren.

Zelf gebruik ik deze (libpng) ook voor het kleiner maken van png's, enz., en zie ik het ook bij Wine gebruikt worden.

[Reactie gewijzigd door HollowGamer op 16 november 2015 11:38]

Waaruit trek je die conclusie?

Op de meeste systemen zal gewoon een shared "libpng" staan. Die bijwerken is voldoende, software hoeft verder niet aangepast te worden.

Veel Windows applicaties maken er een zootje van en zullen wel een eigen versie meesleuren. Die moeten dan wel handmatig bijgewerkt worden.

Van Android/Apple weet ik niks, maar aangezien dat gewoon posix systemen zijn, zullen die wel een shared lib hebben die je makkelijk kunt bijwerken.

Ook onder Linux kan je gewoon een eigen versie meecompileren, de shared lib gebruiken is een optie, geen eis.

Op Windows heb je een native PNG API (Windows Imaging Component), daar hoef je libpng helemaal niet te gebruiken, tenzij je per se crossplatform met Linux wilt blijven.

[Reactie gewijzigd door Dreamvoid op 16 november 2015 13:41]

Ik schreef ook heel bewust "meeste systemen". Het woord "Linux" heb ik niet gebruikt.

Het gros gebruikt een shared lib, op elk willekeurig OS. Dat bedoel ik. Applicaties met eigen versies of die statisch linken zijn de uitzondering, niet de regel.

Het gros gebruikt een shared lib, op elk willekeurig OS.

Onzin dit. Als je een beetje open source apps op je WinDoos hebt staan, ben je al de sjaak :
- GIMP
- Inkscape
- Krita
- Avidemux
- VLC
etc. etc. En dan heb je 't nog niet eens over de applicaties waar het verstopt zit in een andere bin...

Static linked libraries worden gebruikt omdat de softwaremaker bijvoorbeeld om wat voor reden dan ook een specifieke (oudere) versie van de library nodig had. Of omdat hij een "drop and use" binary wil aanbieden (gewoon de binary downloaden en uitvoeren, zonder verdere installatie/configuratie). Er zijn (helaas) tal van redenen waarom mensen voor static linking kiezen.

Ik vermoed dat dit op Windows helemaal gebeurd, omdat er voor dit soort centrale libraries geen update manager actief is.

Wel voor alle Windows en .NET gerelateerde libraries die op Windows natuurlijk het meest gebruikt worden.
Die worden gewoon door windows update bijgehouden.

[Reactie gewijzigd door Anoniem: 80466 op 16 november 2015 14:22]

Omdat je sowieso niet zomaar vanuit kunt gaan dat de library al op het system staat, en daarbij dan ook niet met zekerheid kunt zeggen dat het ook de library is die compatible is met jouw applicatie (ofwel de dll-hell), zal niet de eerste keer zijn dat een nieuwere library wordt overschreven door een oudere, of een nieuwere library niet meer compatible is met de oude..

"Een andere factor is het feit dat er geen centrale versie van libpng is die in een keer aangepast kan worden. Veel programma's gebruiken hun eigen versie van de bibliotheek."

Lijkt me een nogal platform afhankelijk "feit", meeste applicaties op linux distributies gebruiken shared ipv static libraries.

Maar dat heeft niets met de bug zelf te maken. Het maakt het wel iets gemakkelijk om de library te updaten, maar versie 1.6.19 is vulnerable ongeacht of je gebruik maakt van static linked libraries of van shared libraries..

Op mijn Debian systemen staat momenteel versie 1.2.50. Maar Debian heeft momenteel nog geen update klaar staan.. Maar mijn Linux systemen zijn niet zo vatbaar voor deze exploit als mijn gewone Windows desktop. Mijn systemen doen niets met images, Chrome, Firefox en Thunderbird zijn natuurlijk wel erg vatbaar. Zeker als men slim is en de images embed in de mail (zodat ze direct worden getoond door Thunderbird)..

Klopt, maar met een shared libary is 1 update vanuit de distro genoeg om alle programma's weer veilig te maken.

Klopt, maar dan moet men daar dus wel gebruik van maken...... En zeker met een shared libary moet er heel goed rekening gehouden worden met compatibiliteit, want je wil niet dat zomaar bij een update van een shared library ineens een hoop applicaties niet meer werken. En dat is dus ook vaak de reden waarom er toch met eigen meegeleverde libaries werkt zodat je dat probleem van dllhell niet (of een heel stuk minder) hebt..

Kwestie van de externe API gelijk houden. Dan horen de applicaties (als ze zich netjes aan de API's houden) gewoon te blijven werken.

Yep, dat klopt, maar API dev's hebben nog wel eens de neiging om die dus te wijzigen en het zal niet de eerste keer zijn dat zo'n API-dev VINDT dat anderen maar hun software moeten aanpassen..
Ik ben het overigens helemaal eens dat je zo veel mogelijk de standaard libraries van het OS zelf moet gebruiken.

En de regel daar weer op is dat bij API-wijzigingen het major-nummer omhoog moet. Binnen 1 major horen public API's nooit te veranderen.

En ja je kan aan de package-manager opgeven dat je perse major x nodig hebt van een libary.

Bij mijn eigen framework waren ook flinke API-wijzigingen nodig voor modernisatie. Daarom gaat ook het versie-nummer van 1 naar 2.

[Reactie gewijzigd door hackerhater op 16 november 2015 15:10]

Niet met de bug zelf, maar wel met het in het door de auteur veronderstelde "feit".
Onder windows is het inderdaad gebruikelijker dat het static libs zijn doordat programma's niet binnen een systeem gepackaged worden. Daarnaast zijn shared libs vanuit het verleden gezien op windows ook niet zo'n succes gebleken (dll-hell). Dus daar zullen inderdaad alle applicaties die er gebruik van maken los moeten worden geupdate.

waarom zouden shared libs vanuit het verleden voor windows geen succes zijn maar voor andere OSsen wel? op alle OSsen heb je in principe hetzelfde probleem als het op shared libaries aan komt..

Meerdere redenen denk ik (vooral in combinatie met elkaar), maar het begint allemaal met:

• Geen centrale packaging
• Geen centrale update voor applicaties

Als je dat wel hebt kun je stable releases doen, je fixt alleen de bug en meer niet, dat beperkt het testen nogal. Als je gewoon de nieuwste versie pakt dan breek je allerhande applicaties. Bij centrale packaging wordt daar voor je op gelet.
Als je niet centraal update weet ook niemand welke subversie van de dll nou geupdate moet worden etc. Door dat de meeste applicaties closed source zijn is het opzetten van een centrale packaging / update ook niet echt mogelijk.

Dat is in het windows 3.1 / 95 / 98 / me tijdperk wel gebleken dat het delen van (verschillende versies) van DLL's een crime is. Omdat er niemand centraal over gaat, levert uiteindelijk liever *zelf* z'n dll mee.
Als applicatie maker wil je immers dat jouw applicatie goed werkt, de rest boeit je minder.

Bij linux distro's wordt de meeste software niet direct van de applicatiemaker gedownload en geinstalleerd. Updates en dependencies van applicaties worden dus door iemand anders verzorgd die daar specifiek op let. Daar komen ze opzich dezelfde problemen tegen als bij windows, maar die plooien strijken zij dus voor je glad, dat is dus werk wat alle packagers / maintainers doen die distributies onderhouden, want het gaat niet helemaal van zelf.
De "cultuur" is daar dus anders en applicatie makers zorgen er dus eigenlijk altijd wel voor dat er gebruik gemaakt kan worden van shared libraries (meestal ook de default).

Overigens is er soms wel kritiek, dat het installeren van losse packages buiten een distributie soms te lastig is. En of containers met alle dependencies dan niet beter zou zijn. Ja en nee dus .. you win some .. you loose some .. geen van beide modellen is zaligmakend.

[Reactie gewijzigd door gekkie op 16 november 2015 14:36]

Ubuntu wil die richting op met Snappy Apps, meen ik. Ik ben er geen voorstander van. Patchen van bugs als deze in libpng wordt daardoor flink tegengewerkt. Op Linux werkt het perfect met shared libraries, in ieder geval zo lang je binnen je package manager blijft.

Alsnog leveren de meeste leveranciers van proprietary software wél specifieke versies van libraries mee. Games bijvoorbeeld. Gelukkig kan dat wel gewoon op Linux; je moet enkel voor het starten van de binary even LD_LIBRARY_PATH aanpassen om te zorgen dat eerst tussen de meegeleverde libraries gezocht wordt en daarna pas in de systeemdirectories. Op Windows werkt dat ook natuurlijk, maar daarvoor hoef je niets te doen, Windows geeft sowieso de voorkeur aan DLL's in dezelfde directory als de executable.

Torvalds leek er ook voorstander van in z'n praatje tijdens Debconf (niet dat hij er iets over te zeggen heeft gelukkig) , probeerde min of meer alle effort die er in packaging wordt gestoken als overbodig te verklaren, dat is toch wel vrij kort door de bocht.
.
Maar goed je gooit dus wel een aardig werkend bestaand systeem daarmee weg, ik zou er in iedergeval nog even goed over nadenken wat als het eenmaal zo ver is dan kom je echt niet meer terug.

Je kunt idd wel meerdere versies hebben en ook van proprietary software, maar omdat die niet gemanaged wordt, ben je als je die software installeert wel opeens verantwoordelijk voor het updaten van die software en al haar libs (waar je dan wellicht weer niet op bedacht bent).

Onder Linux is het geen probleem meerdere versies van dezelfde libary tegelijk op je systeem te hebben. De package-manager regelt dit.

Inderdaad. Ik verwacht heel snel een update vanuit de repos van oa libpng

Het is een problematische bug omdat libpng aanwezig is in zo goed als elke applicatie die png-afbeeldingen verwerkt, waaronder browsers, muziekspelers en spellen. Een andere factor is het feit dat er geen centrale versie van libpng is die in een keer aangepast kan worden. Veel programma's gebruiken hun eigen versie van de bibliotheek.

Als je de pakketten goed bouwt, gebruik je de meegeleverde libpng niet, maar de libpng van je systeem. Dat betekend wel dat je de code in een aantal gevallen eerst moet patchen.

De originele libpng source code kun je via deze link vinden.

Zelfs als dat gebeurt is dit nog steeds een groot probleem. Élke embedded linux toepassing is kwetsbaar hierdoor, denk aan je router, printers met cloud functionaliteit, NAS, thermostaat......Of koopt iedereen alleen de duurdere merken waarvan bekend is dat ze nieuwe updates krijgen (en voor de Anti-Apple fanaten: nee, dan bedoel ik niet per se Apple)

Zelfs als dat gebeurt is dit nog steeds een groot probleem. Élke embedded linux toepassing is kwetsbaar hierdoor, denk aan je router, printers met cloud functionaliteit, NAS, thermostaat......Of koopt iedereen alleen de duurdere merken waarvan bekend is dat ze nieuwe updates krijgen (en voor de Anti-Apple fanaten: nee, dan bedoel ik niet per se Apple)

Er zijn heel veel embedded Linux devices die niet kwetsbaar zijn, zelfs met een niet gepatchte libpng.

Als je geen mogelijkheid hebt om een png file aan te bieden aan je device kun je onmogelijk gebruik maken van deze kwetsbaarheid.
Zo zal je thermostaat niet kwetsbaar zelf of je moet er een png skin op uploaden.
Het plaatsen van een aangepaste png file zal de kwetsbaarheid van je NAS ook niet triggeren want het is maar een file, waar het nas niets mee doet.

Simpelweg een png opslaan zal geen probleem zijn nee. Daar heb je zeker een punt.

Maar vaak halen dat soort apparaten weer een webpagina ergens op waar bijvoorbeeld een png in verwerkt zit en voilà. En zo zijn er ongetwijfeld nog meer aanvalsmogelijkheden.

Simpelweg een png opslaan zal geen probleem zijn nee. Daar heb je zeker een punt.

Maar vaak halen dat soort apparaten weer een webpagina ergens op waar bijvoorbeeld een png in verwerkt zit en voilà.

De data van de webpagina staat meestal op het device zelf.
Als dat niet zo is dan zal dit waarschijnlijk bij de fabrikant zijn. Deze zal echt geen exploit pngs plaatsen.

Sowieso zal als het device goed doordacht opgezet is, een programma alleen als root lopen as het niet anders kan.
Dar betekend dat bij een exploit de rechten die de code krijgt de rechten van de originele gebruiker zullen zijn.

Op je Linux systeem kun je firefox ed als een andere gebruiker dan je zelf starten. Waardoor het aanvalsrisico erg klein is, omdat er maar een klein aantal bestanden aangepast kunnen worden.

Ik heb graag de sourcecode voor alle Linux apparaten in huis.

De satelliet settop werk ik zelf wel even bij. Ben ik niet overgeleverd aan de grillen van een paar geldwolven. Dat is de gedachte van Open Source!

Mooi als je dat kunt. Voor 99.5% van de apparaatgebruikers is dat helaas niet haalbaar :-)

Die krijgen een update via de afstandbediening binnen nadat ik thuis een "git push" gedaan heb en de nieuwe feeds het internet op gaan.

Is libpng-1.2.49-1 ook lek ?

1.2.X Before 1.2.54 https://web.nvd.nist.gov/...tail?vulnId=CVE-2015-8126

Hiermee is iig alle Debian & Ubuntu distro's lek, deze hebben op moment van schrijven nog niet 1.2.54 uitgerold.

[Reactie gewijzigd door Phoenix_the_II op 16 november 2015 12:09]

1.2.X Before 1.2.54 https://web.nvd.nist.gov/...tail?vulnId=CVE-2015-8126

Hiermee is iig alle Debian & Ubuntu distro's lek, deze hebben op moment van schrijven nog niet 1.2.54 uitgerold.

Debian heeft de bug nog niet gefixed, zie Debian bugreport.

Het is wel erg kort door de bocht om te stellen dat omdat Debian libpng 1.2.54 nog niet uitgerold heeft, Debian kwetsbaar is.

Veel distro's patchen de huige software versie. In het geval van Debian zou het kunnen zijn dat de gepachte versie ook 1.2.50 blijft.

Het beste is het om in de changelog te kijken.

[Reactie gewijzigd door Anoniem: 112442 op 16 november 2015 12:27]

Hoe kan je veilheid in een bedrijf die Bring Your Own Device hanteert, garanderen met dit soort bugs?
Dit is puur gewoon een vraag, ik probeer hier wat van te leren.

Kort antwoord: niet. Ik ben persoonlijk van mening dat je er in een BYOD scenario van uit moet gaan dat de gebruiker's device besmet is. De diversiteit in devices is te groot, tel daar bij op dat mensen bijzonder onvoorzichtig zijn met het installeren van software op hun persoonlijke device.. Dus zorg dat zo'n device geen toegang heeft tot gevoelige informatie, want zodra een aanvaller zich daar op concentreert gaat het mis.

Dit soort vulnerabilities in veelgebruikte libraries tonen wel weer aan hoe belangrijk het is om snel softwarepatches te hebben en uit te kunnen rollen. Volgens mij gaan we nog lang horen van deze vuln.

Dit soort vulnerabilities in veelgebruikte libraries tonen wel weer aan hoe belangrijk het is om snel softwarepatches te hebben en uit te kunnen rollen. Volgens mij gaan we nog lang horen van deze vuln.

Het kan nog een tijd duren voor dat deze softwarepatches er zijn.

De eerste patch is voor een aantal versies beschikbaar.

Natuurlijk, het versprijden van die patch gaat lang duren, maar hij is er al wel. Dit is waarom ik zo veel meer hou van het model van bijv. linux dan Windows (alhoewel ik hier op Windows zit nu ), want al je dependencies zijn daadwerkelijk externe dependencies, i.p.v. dat alles een deel word van je programma.

Net zo veel of weinig als met door het bedrijf uitgegeven apparaten.

Beveiligingsproblemen en lekken kom je altijd wel ergens tegen, het gaat vooral erom hoe snel je het lek kan dichten.

Zelfs zonder byod is dit een ernstige bug. Ook gewoon je webbrowser kan kwetsbaar zijn. De enige manier om deze aanval tegen te gaan is simpelweg je internet toegang afsluiten.

Hoe kun je dit met BYOD garanderen?
Klinkt weer als een systeembeheerder die zijn kans schoon ziet om een regel waar hij het persoonlijk niet mee eens is van tafel te kunnen vegen.
Zowel mét als zónder BYOD is de veiligheid vrijwel niet te garanderen aangezien dit soort lekken de laatste tijd aan de orde van de dag zijn.

geen, het is YOUR device ;-) geen device wat door ict beheerd wordt

Maar wel een apparaat dat op jouw netwerk zit en gebruikt maakt van allerlei middelen.

En dus?

BYOD betekent simpelweg dat je devices op je netwerk niet vertrouwt. Die devices mogen niets op je netwerk, tenzij je iets expliciet whitelist. In een gesloten netwerk kun je met blacklists werken. Maar het concept van whitelists zou voor ICT geen probleem mogen zijn, je firewall gebruikt als het goed is ook al een whitelist.

Het gevolg is dat een device geen extra netwerk rechten kan krijgen, en dus ook niet door deze PNG bug.

[Reactie gewijzigd door MSalters op 16 november 2015 11:35]

BYOD betekent simpelweg dat je devices op je netwerk niet vertrouwt. Die devices mogen niets op je netwerk

Meestal mogen ze juist wel van alles.
Ze mogen meestal zich aanmelden bij het bedrijfsdomein en dan mail ophalen/versturen bij de mailserver, files lezen/plaatsen op persoonlijke en afdelingsshares en toegang tot applicaties waartoe de gebruikers van de apparaten toe gerechtigd zijn.
Dat betekent bijvoorbeeld dat die devices de .png files ook weer kunnen verspreiden via bedrijfmail en shares.
En wat te denken van bedrijven die op bedrijfstelefoon IM applicaties gebruiken waarin je png plaatjes aan collega's kan versturen.

[Reactie gewijzigd door Anoniem: 80466 op 16 november 2015 11:45]

daar wordt een fout gemaakt; het is bring YOUR device; geen device van/in de organisatie. zon ding mag never te nimmer op jouw lan / files etc.
daar heb je vlan e.d. voor. moet er niet aan denken dat ongeauthoriseerde devices deel maken van de bedrijfsomgeving ....

Het heeft weinig zin als iemand een eigen device meeneemt om op te werken als hij/zij daarmee niet bij bedrijfsrecources kan. Gebruikelijke definites van BYOD gaan ook uit van toegang tot bedrijfsrecources

Bring your own device (BYOD)—also called bring your own technology (BYOT), bring your own phone (BYOP), and bring your own PC (BYOPC)—refers to the policy of permitting employees to bring personally owned mobile devices (laptops, tablets, and smart phones) to their workplace, and to use those devices to access privileged company information and applications

https://en.wikipedia.org/wiki/Bring_your_own_device

Een relatief eenvoudige oplossing is werken met containers op mobile devices, waarmee je er voor zorgt dat alle gevoelige informatie in een beveiligde omgeving staat, waar het device zelf geen toegang tot heeft (met natuurlijk ook de mogelijkheid tot remote wiping etc). Dit kan ook bij laptops, door je medewerkers te laten werken in een virtuele omgeving, waarbij je dus geen interactie toelaat tussen de virtuele omgeving en het apparaat.

Als die container ook gebruik maakt van libpng, dan kan je buiten de container breken. Dat is het hele idee van buffer overflows, dat ze code injecteren buiten hun 'veilige' geheugengebiedje.

En dan is het hoe streng het OS hiermee om gaat.
Onderdelen als AppArmor en SELinux zijn juist bedoeld als beveiliging tegen aanvallen als dit.

Je kan dan hooguit een DOS veroorzaken (denial of service)

Dit zegt niet dat je automatisch bij alle Company informatie kan....

Dit zegt niet dat je automatisch bij alle Company informatie kan....

Dat zeg ik ook niet.

[Reactie gewijzigd door Anoniem: 80466 op 16 november 2015 13:27]

Dat is de compleet omgekeerde definitie.

Voordat BYOD als term uberhaupt bestond, waren netwerken al dichtgespijkerd, hopelijk. Het nieuwe aan BYOD is JUIST dat toegang verleend wordt aan devices die geen eigendom van het bedrijf zijn.

Of dat door een white of black list gerealiseerd wordt, staat hier los van.

Wat is een 'bring your own device' bedrijf?

Ik denk dat het simpele antwoord is.. Niet, je kan nimmer de garantie geven.
Het zal vaak te voorkomen zijn om met algemene lijstjes te gaan werken om te zien voor welke zaken exploits bekend zijn.

Een bedrijf zonder BYOD kan de veiligheid ook niet garanderen. "Officiele" smartphones die traag of niet van updates worden voorzien door hun leveranciers zijn een risico. Dat wordt erger door de "professionele" weerstand bij menig bedrijf tegen zoiets als Cyonagenmod. In CM zijn volgends CT magazine de veiligheidslekken eerder gerepareerd dan menig Samsung van de zaak.

Gezien de GDlibrary in PHP zal deze bibliotheek ook in PHP gebruikt worden? Lijkt me?

GD library requires libpng and libjpeg to compile.

http://php.net/manual/en/image.installation.php

Yep!

Hoe is dit via het netwerk uit te voeren? Staat ook niets over op de CVE pagina. Ik denk dat bedoeld wordt dat het gebruikt kan worden als je bv vanaf een webpagina een afbeelding download die de kwetsbaarheid gebruikt.

Een MITM-aanval die een malafide PNG serveert is genoeg, denk ik. Er zal vast nog een makkelijkere manier zijn. Als het netwerk van jou is kan je er natuurlijk alles mee doen.

"Het is een problematische bug omdat libpng aanwezig is in zo goed als elke applicatie die png-afbeeldingen verwerkt, waaronder browsers, muziekspelers en spellen."

Lijkt me een Linux probleem, Windows gebruikt Windows Imaging voor zover ik weet.

Je denkt dat cross-platform applicaties een windows-only libary gebruiken?
Niet dus.

"in zo goed als elke applicatie die png-afbeeldingen verwerkt" - misschien op Linux, maar hoeveel % van de applicaties op Windows zijn cross-platform? Niet "zo goed als elke applicatie".

Genoeg applicaties hoor. Sowieso al alle browsers die niet op IE gebaseerd zijn.
Daarnaast is Windows over het hele web maar een kleine speler. Windows is alleen op de desktop groot.

Als in de update, Firefox en Chrome dus al niet... Ik vraag me af of ik iets op m'n Win10 PC heb staan dat het gebruikt.

"Daarnaast is Windows over het hele web maar een kleine speler. Windows is alleen op de desktop groot. " want de desktop is maar een hele kleine markt

[Reactie gewijzigd door Anoniem: 558790 op 16 november 2015 15:27]

Vergeleken met alle apparaten met een OS is de desktop inderdaad maar een kleine markt. Het is alleen veel duidelijker dat je pc een OS draait dan je telefoon, je router, je smart-tv, schakelingen in fabrieken, centrales, etc.

En dit is belangrijk voor LibPNG op Windows omdat...?

Als teken dat er genoeg applicaties zijn die op meer OS'en dan alleen Windows moeten werken en die dus oa LibPNG zullen gebruiken ipv dat Windows-only ding.

Firefox en Chrome gebruiken dus NIET dat Windows-ding.
Dat ze wellicht nog geen patches gereed hebben is wat anders.

Het punt, waar je direct al off topic ging, was dus:
"Lijkt me een Linux probleem, Windows gebruikt Windows Imaging voor zover ik weet."

Erg leuk dat Windows volgens jou "een kleine speler is", en dat er dingen als cross platform apps de library gebruiken, maar hoe is het "een problematische bug omdat libpng aanwezig is in zo goed als elke applicatie die png-afbeeldingen verwerkt"? Lijkt me al duidelijk dat dat iig op Windows al niet zo is, omdat de meeste dingen de LibPNG library dus gewoon NIET gebruiken.

Voornamelijk een Linux probleem dus.

Edit:
"Firefox en Chrome gebruiken dus NIET dat Windows-ding."
Ik zei dat ze geen LibPNG gebruiken, niet dat ze Windows Imaging gebruiken... Lezen is een kunst.

[Reactie gewijzigd door Anoniem: 558790 op 16 november 2015 15:42]

https://www.mozilla.org/e...y/advisories/mfsa2012-11/
https://code.google.com/p/chromium/issues/detail?id=209778
You said?

Ze gebruiken dus weldegelijk libpng.
Het heeft niks met Windows of Linux te maken. Heel veel applicaties gebruiken Libpng, net als heel veel applicaties openSSL gebruiken.

[Reactie gewijzigd door hackerhater op 16 november 2015 16:27]

Links van drie jaar oud... Ze hebben ze vroeger idd gebruikt.

Bij mij depend iceweasel niet direct op libpng, maar wel op libcairo, welke weer depend op libpng.
Niet uitgesloten dat ze er op die wijze dus alsnog gebruik van maken.

Grote kans dat Iceweasel dan inderdaad indirect nog afhankelijk is van libpng.
Nadeel van deze goede libaries is dat ze zoveel gebruikt worden. Een bug verspreid zich dan helaas als een olievlek.

Voordeel van het nadeel is dan weer dat het niet dagelijks gebeurd bij 1000 matig onderhouden libs die +/- hetzelfde zouden moeten doen

[Reactie gewijzigd door gekkie op 16 november 2015 17:03]

Heb je wel eens naar de docu van dat gekeken?
Skia is een 2D-teken libary, ongetwijfelt bedoeld voor het canvas deel van HTML5.
Dat is wat anders dan plaatjes renderen.

https://skia.org

"Update: Het blijkt dat een aantal applicaties niet getroffen zijn door deze kwetsbaarheid. Het gaat hierbij om PHP en Google-producten als Android, Chrome OS en Chrome. Deze laatste drie maken gebruik van de Skia-bibliotheek in plaats van libpng. Hetzelfde geldt voor Firefox en Firefox OS."

Maar je hebt volledig gelijk hoor

"Jij hebt mischien alle tijd van de wereld, maar ik heb werk te doen. En dus geen tijd om 100'en pagina's door te kijken."

Raarste excuus om onzin als fact de wereld in te slingeren dat ik ooit gezien heb.

[Reactie gewijzigd door Anoniem: 558790 op 16 november 2015 17:14]

Ow ja :
https://github.com/google/skia/blob/master/gyp/libpng.gyp

Skia => libpng.

@Redactie. check die link

Zie ook deze reactie : BasSchouten in 'nieuws: Veelgebruikte libpng-bibliotheek is kwetsbaar door bug - update'

Nu zijn ze wellicht niet kwetsbaar voor specifiek deze bug, maar indirect gebruiken ze weldegelijk libpng

[Reactie gewijzigd door hackerhater op 16 november 2015 17:20]