'Ghostscript-lek maakt ImageMagick kwetsbaar voor op afstand uitvoeren van code'

Het Amerikaanse Cert waarschuwt voor kwetsbaarheden in Ghostscript, een opensource-interpreter voor PostScript, die het op afstand uitvoeren van code mogelijk maken. Doordat Ghostscript wordt gebruikt in andere software, waaronder ImageMagick, bestaat ook daar risico.

In zijn waarschuwing vermeldt het Cert dat ook Red Hat en Ubuntu zijn getroffen door de kwetsbaarheden, die nog geen cve-aanduiding hebben. Het maakt nog geen melding van patches, maar raadt aan om het verwerken van ps-, eps-, pdf- en xps-bestanden in ImageMagick uit te schakelen als work-around. Volgens de organisatie maken de lekken het voor een aanvaller mogelijk om Ghostscript of software die daarvan gebruikmaakt een aangepast bestand te laten verwerken, waardoor hij op afstand code kan uitvoeren met de rechten van de Ghostscript-code.

Het Cert verwijst naar een bericht op de Openwall-mailinglijst door Tavis Ormandy, een onderzoeker werkzaam bij Googles Project Zero, die de lekken heeft ontdekt. Daarin legt hij uit dat het gaat om verschillende manieren om de Ghostscript-instelling -dSAFER te omzeilen, die tot doel heeft om onveilige handelingen van PostScript te verhinderen. PostScript is een door Adobe ontwikkelde page description language, oftewel paginabeschrijvingstaal. Ghostscript dient als een interpreter of vertaler hiervoor, net als voor pdf. Het wordt behalve in ImageMagick ook gebruikt in software als GIMP en Evince, aldus Ormandy.

ImageMagick is een veelgebruikte beeldverwerkingsbibliotheek die onder andere ondersteund wordt door php, Ruby, NodeJS en Python. Veel contentmanagementsystemen, socialmediasites, blogs en dergelijke maken direct of indirect gebruik van ImageMagick voor uiteenlopende verwerkingshandelingen.

Reacties (28)

nasty, zijn toch veel diensten/services die gebruik maken van deze producten (ook hier)

'work around'

Disable PS, EPS, PDF, and XPS coders in ImageMagick policy.xml

ImageMagick uses Ghostscript by default to process PostScript content. ImageMagick can be controlled via the policy.xml security policy to disable the processing of PS, EPS, PDF, and XPS content. For example, this can be done by adding these lines to the <policymap> section of the /etc/ImageMagick/policy.xml file on a RedHat system:

<policy domain="coder" rights="none" pattern="PS" />
<policy domain="coder" rights="none" pattern="EPS" />
<policy domain="coder" rights="none" pattern="PDF" />
<policy domain="coder" rights="none" pattern="XPS" />

andere output publiseren, als tijdelijke 'oplossing'

[Reactie gewijzigd door himlims_ op 22 augustus 2018 11:36]

even gechecked, in ubuntu is het:
/etc/ImageMagick-6/policy.xml

Dit is zeker een 'work around' (vooral de ' ) voor ons is ImageMagick/Ghostscript de manier om EPS/PDF en AI bestanden om te zetten naar een wat browser vriendelijker formaat. We doen dit gelukkig op een CDN server waar verder geen kritieke informatie (puur en alleen visuals en fonts) staat maar alsnog wil je deze niet ineens overgenomen hebben door derden met alle gevolgen van dien. Hopen op een snelle fix, wij gebruiken niet de php plugin/extensie maar de executable dus is een update draaien daarop straks genoeg.

Vreemd dat er nog geen CVE hiervoor bekend is, dit lijkt me toch de manier om lekken te rapporteren zodat de ontwikkekaars deze kunnen dichten voordat deze op straat komen te liggen.

Voor mensen die Puppet gebruiken zou je met Augeas de wijziging globaal kunnen uitrollen:

augeas { "Ghostscript-disable-PS":
lens => 'Xml.lns',
incl => '/etc/ImageMagick/policy.xml',
context => '/files/etc/ImageMagick/policy.xml/policymap/',
changes => [
"set #text[last()+1]/ ' '",
"set policy[last()+1]/ #empty",
"set policy[last()]/#attribute/domain coder",
"set policy[last()]/#attribute/rights none",
"set policy[last()]/#attribute/pattern PS",
],
onlyif => "match policy/*/pattern[.='PS'] size == 0",
}

Complete script staat op https://gitlab.com/linqho...d_fix_Ghostscript_2018.pp.

Dus als ik het goed begrijp is een (web) applicatie alleen kwetsbaar als je met ps-, eps-, pdf- en xps-bestanden werkt en niet als je alleen maar met png- of jpeg-bestanden werkt?

een (web)applicatie is kwetsbaar als er ergens image files kunnen worden ge-upload (waaronder ps/eps/pdf/xps) en dat ze ergens bij imagemagick komen (al is het maar om informatie te krijgen zoals resolutie of image-format bijvoorbeeld).

De ImageMagick installatie vertellen dat hij van alle postscript-gerelateerde files moet afblijven is een oplossing (maar let aub goed op je config file plek! Imagemagick 6? Imagemagick 7? repository build? Custom build met config file ergens anders? Testen!!)

de web-applicatie aanpassen dat er alleen maar bepaalde files door worden gestuurd naar ImageMagick kan ook, maar dan moet je heel goed opletten hoe je dat doet. Image-type mag niet bepaald worden door ImageMagick zelf , en dingen zoals extensie en mime-type zijn makkelijk te spoofen.

Ik zit te kijken in wat Drupal sites (Zoals wij die hier hebben ingericht dan), en daar wordt out of the box de PHP functie fileinfo() gebruikt om te kijken wat voor type het bestand is (dus we vertrouwen niet wat de browser zegt dat het is) en alleen jpg, png en gif mogen door naar ImageMagick... dus ik denk dat we veilig zijn, maar het is wel even goed controleren .

Dan heb je denk ik niet het doel bereikt met fileinfo, los van deze exploit.
Kijk maar eens naar dit comment van 11 jaar terug:
http://php.net/manual/en/function.finfo-file.php#75275

... depends.. wat bij dat (oude) comment staat 'hoe het wel te doen' is juist wat je hier nu NIET moet doen (namelijk het aan imagemagick over laten ).

ze zeggen dat het te faken is wat fileinfo() er van maakt en at je er executable code achter kan plakken en zo.. klopt, maar dan is die code nog niet uitgevoerd.

Als er iets is wat fileinfo() doet denken dat het een GIF file is, dan zal imagemagick dat ook doen (lijkt me).. en als er stiekem toch PDF data achter komt, dan heeft Imagemagick allang de gif parser actief en komen er errors (i.p.v. dat het netjes naar de postscript parser komt waar nu het lek in zit)..

maar ja, ook fileinfo() valt te faken, heb je helemaal gelijk in. Ik geloof niet dat het valt te faken op een manier dat je alsnog een postscript file naar imagemagick krijgt.

Ehm... als je weet hoe het werkt is elke vorm exploitable.
Zelfs in een valide gif of jpeg kan je executable code verstoppen.

Als je weet hoe de functies werken kom je er dus achter dat elke vorm van uploaden gewoon altijd een gevaar is.

Simple voorbeeld: men wil DOCX en XLSX kunnen uploaden. Hoe controleer jij of er macro's in zitten?

[Reactie gewijzigd door DJMaze op 22 augustus 2018 13:24]

Dan kan ik in ieder geval iets geruster ademhalen hahaha. Iedere keer als ik zoiets lees wordt ik zenuwachtig dat ik toch ook kwetsbaar ben. En agree: Ik ga er ook vanuit dat een browser liegt. Ik vraag ook aan het filesystem wat voor bestand het is.

En hoe weet het filesystem dat dan weer?

De headers van de file zelf?

Magic numers, zie de manual page van 'fileinfo' en het commando 'file' op unix/linux:
https://en.wikipedia.org/wiki/Magic_number_(programming)
https://en.wikipedia.org/wiki/File_format
https://en.wikipedia.org/wiki/List_of_file_signatures

Degelijke zaken zijn 'standaard' in unix/linux omgevingen waar file name extenties niets met het operating systeem te maken hebben: Ze worden 'slechts' door applicaties gebruikt.

Zelfs in het simpele file(1) worden regelmatig security issues gevonden. Het blijkt verdomd lastig om foutvrije code te schrijven. :-)

Klopt, want dan wordt Ghostscript niet gebruikt.

Wij hebben een web app in ontwikkeling die zwaar leunt op ImageMagick. Hij is nog niet in productie, dus vormt het nu nog geen risico. Ik hoop dat ze het opgelost hebben voordat hij live gaat, dan hoef ik geen workarounds te gebruiken.

Dan zou je i.p.v. je tijd en geld in workaround steken, misschien een ontwikkelaar kunnen betalen om dit probleem op te lossen.

Ik ben de ontwikkelaar van dit project. Ik zal dus zelf het probleem moeten oplossen. Het is echter niet zo dat de app perse morgen live moet. Daarom hoop ik dat ze het zelf oplossen bij ImageMagick. Scheelt mij weer (ookal is de workaround heel simpel).

_{Of bedoelde je geen ImageMagick gebruiken, maar zelf een afbeeldings processing library (laten) schrijven? Dat gaat heel wat kosten...}

[Reactie gewijzigd door jrswgtr op 22 augustus 2018 13:23]

vergeet even niet dat het lek (als ik dit zo lees) niet in ImageMagick zelf zit, maar in de Ghostscript library die door ImageMagick wordt gebruikt..

ImageMagick compilen zonder Ghostscript (en accepteren wat voor functies je daarmee kwijt raakt) zou best een optie zijn.. ik denk dat het imagemagick team niet veel hier aan gaat doen als het probleem bij een externe dependency zit .

libvips is ook een prima library en ook nog eens sneller. Misschien kun je het als alternatief gebruiken.
Ik gebruik het al vanaf het begin van zijn bestaan in NodeJS

[Reactie gewijzigd door ultimate-tester op 22 augustus 2018 13:03]

Nee hoor, ImageMagick is volledig open source en vrij te gebruiken door iedereen.

ImageMagick is free software delivered as a ready-to-run binary distribution or as source code that you may use, copy, modify, and distribute in both open and proprietary applications. It is distributed under the Apache 2.0 license.

[Reactie gewijzigd door jrswgtr op 22 augustus 2018 12:17]

Dat iets open source is, betekent niet dat je het gratis commercieel kunt gebruiken.

Maar dat mag dus in dit geval wel!

Hmmmm, maar iets was toch niet zomaar gratis te gebruiken? Was Ghostscript dan betaald o.i.d.? Ik dacht dat één van die producten aardig prijzig was...

Hier een linkje naar de licentie:

https://www.imagemagick.org/script/license.php

Zegt duidelijk het volgende:

It allows you to:

- freely download and use ImageMagick software, in whole or in part, for personal, company internal, or commercial purposes;
- use ImageMagick software in packages or distributions that you create;

Dan is dat nu de wereld uit.

Ik dacht dat één van die producten aardig prijzig was...

Misschien heb je het over een 3rd party library die weer gebruik maakt van ImageMagick? Niemand let je om geld te vragen voor iets dergelijks.

[Reactie gewijzigd door jrswgtr op 22 augustus 2018 12:26]

Ik denk dat je ghostscript bedoelt:

Artifex is the exclusive commercial licensing agent for Ghostscript. There is no "public domain" version of Ghostscript.

The kind of distribution or use you plan to make of Ghostscript will determine whether you need a commercial license from Artifex. If you plan to distribute Ghostscript in one of your products or make them available to your SaaS or ASP customers, you should understand the differences between these licenses.