back to article Server-jacking exploits for ImageMagick are so trivial, you'll scream

Samples of booby-trapped image files that exploit ImageMagick to compromise servers and other computers are well and truly out in the open now. On Tuesday, it emerged that ImageMagick – a popular software tool used by countless websites to process selfies and other submitted photos – has a bunch of critical security bugs. …

  1. Pascal Monett Silver badge

    Developer forum is murdering ImageMagick

    From the first few lines on that forum, I clearly get the sense that nobody is very impressed with ImageMagick's way of doing things.

    My favorite comment thread :

    It's really a command-line tool at its heart. The library is essentially just a wrapper around this command-line tool.

    That sounds bass ackwards if you ask me. A command line tool is usually a thin wrapper around a library, for a reason.

    and the beautiful conclusion :

    And yes, it's a mess. That's why the much saner GraphicsMagick was forked off it… in 2002. People just never migrated.

    In other words, ImageMagick is something that should have died at the turn of the millennium.

    1. Anonymous Coward
      Anonymous Coward

      Re: Developer forum is murdering ImageMagick

      Confirmed: GraphicsMagick is NOT vulnerable to the particular exploit in this article. It bails out if the file's extension doesn't match its 'magic number' header, and if you give it the proper extension (.mvg) it rejects the malicious 'fill color'.

      This does not mean GraphicsMagick is 100% safe.

      Meanwhile, turns out it's pretty easy to screw up the policy.xml patch for ImageMagick. Test the exploit code before and after patching, or just switch to GraphicsMagick.

    2. ElReg!comments!Pierre

      Re: Developer forum is murdering ImageMagick

      Some people DID migrate!

      In any case, at heart IM is mostly just a pile of script tools for image manipulation. I don't think it was ever meant to be terribly secure, it's supposed to be on the "quick'n dirty" side of the spectrum. GraphicsMagick is not _terrificly_ better either. In fact, batch image manipulation tools and libraries are notoriously hard to make both useful an secure because of the tendency (by all "image format ventors") to include more and more "bells and whistles", notably in the meta-informations. I tend to trust PIL somewhat, mostly because I know how to prevent Python from doing stupid things, but even then I always keep a close eye on what can happen with it.

      In my IM days I used to have a few sanitization scripts which I think kept my systems relatively safe, mostly by pre-emptively removing all but pixel informations, but not all image formats work well with that approach, obviously.

    3. Trixr

      Re: Developer forum is murdering ImageMagick

      So I've been using ImageMagick since the late 90s - not on a website, just for a few personal projects - and I've never heard of GraphicsMagick before.

      Cool there is an alternative tool, but a shame they didn't manage to get the word out there very well.

  2. Lunatik
    Facepalm

    Not an inconsiderable oversight

    Oh boy...

    How many sites? How much abandoned but still used code? How...daft?

  3. Anonymous Coward
    Anonymous Coward

    That's the unix way of doing things..

    ... pass anything around chaining shell commands by invoking shells with all their issues (having being designed primarily to be interactive)... so every parameter is just a string (the UDT - Universal Data Type [TM] for lazy programmers) while shell special characters are still processed...

    What? Calling a function in a library where parameters has types and can't be misused easily, and errors are returned in a code-friendly way and not just like strings you need to parse? Heck, that's not the Unix way, we *must* still chain commands as it was 1971, we can't truly load libraries in a few KBs of RAM we still have today, of course!

    1. Frumious Bandersnatch Silver badge

      Re: That's the unix way of doing things..

      I'll tell you a true story. Back in Uni, we had a practical programming exam (in Basic) on the mainframe. The lecturer had set up a restricted environment where commands that could be used to cheat (those relating to sending messages to other users and accessing shared folders) were disabled by using aliases. I noticed that I could undo these aliases from within the Basic interpreter. I hacked the system by asking the lecturer if we could use the Basic interpreter during the exam, because it was more convenient for testing things quickly. They didn't see the problem and whitelisted the interpreter. So after finishing my assignment, I had a bit of fun messaging my mates to show that I'd broken out of the jail.

      The moral of the story is not that there's anything wrong with interpreters (like your diatribe against shells) but the context that they're allowed to be used from. ImageMagick evolved from being a command-line tool and now it's being used in an unsafe context. That is all.

      1. Anonymous Coward
        Anonymous Coward

        Re: That's the unix way of doing things..

        Shells are not just "interpreters". Shells are mostly designed, how their name imply, to allow for user interactions - their scripting was introduced to store list of commands you would have to type instead. Scripting was never meant to substitute proper programming, it's just a quick (and dirty) way to collect sequences of commands.

        Thereby shells have some specific features to allow for easier keyboard interaction (when screens where not so common also). BASIC is another beast - it is designed to write programs, not as an interactive command processor for human interaction.

        Chaining applications was also a common practice when too much code anda data can't simply be stored in the available RAM. Thereby you run a program, stored its result, remove the program from RAM, run the next one, and so on (sometimes, even swapping storage).

        The problem is that lead to the creation of a religion. Because it was done that way back then (due to the hardware constraints of the time), it was the RIGHT WAY, and when the hardware constraint went away, narrow minded people didn't understand it was no longer the right way, and still repeat you today you still have to code like it was still 1970.

        Guess they also wear elephant trousers and big collars shirts because that's the RIGHT WAY to dress.... drugs addiction and Che Guevara worshipping are already part of the picture. It's a cultural stance, not a technically sound one. Forty years too late...

        1. Ramazan

          Re: That's the unix way of doing things..

          > when the hardware constraint went away,

          > narrow minded people didn't understand

          > it was no longer the right way

          When CPU power and screen estate became plenty, wide minded people decided that putting ability to execute code (or bytecode or whatever) in every image, data and hypertext format on the Internet was a great idea. Enjoy.

        2. John Sanders
          Linux

          Re: That's the unix way of doing things..

          I was about to write a lengthy response, but as I'm not as idle as I wanted I'll just say; NO, you do not understand why the insistence on using separate commands and processing text streams via pipes.

          I will give you a simple example of imagemagick in action, using pipes and text:

          qrencode -t PNG -o - "${1:-Empty data!}" | display &

          There you go my on-the-fly QR code generator and viewer, courtesy of the 70s

          Imagemagick was created circa 1991, qrencode 2006

          That my friend is not a religion, it is just practical, I made something to fit my needs with a single line of code, I can quickly generate a QR code and display it on screen to pass data to my phone.

          Joining two applications without having to do anything special is part of how Unix stuff works.

          One does not need to even think hard to come with little bits like these, they just come naturally.

          1. h4rm0ny

            Re: That's the unix way of doing things..

            >>"qrencode -t PNG -o - "${1:-Empty data!}" | display &"

            >>Joining two applications without having to do anything special is part of how Unix stuff works.

            We're talking about calling this from another program or a web script, so tell me why building your command line above is less "having to do anything special" than using an API like the following:

            Imagick imageTool = new Imagick();

            imageTool->grencode('png',outputFile);

            Etc. Is building a command line and sending it to the shell inherently simpler? I think the opposite. It's certainly more prone to vulnerabilities which was the OP's point.

            Text is a terrible way of joining programs together.

            1. Brewster's Angle Grinder Silver badge

              I hate to defend H4rm0ny, but

              If this was an SQL injection caused by home-spun quoting, everybody would condemn the coder as idiots who should have used placeholders. But because its happening on the command-line, everybody's defending it. (Ironically, the unix command-line has the potential to be a safe API: but not when the tokenisation is done by a shell.)

              1. h4rm0ny

                Re: I hate to defend H4rm0ny, but

                If it helps, you can consider yourself simply defending the original AC by proxy. They made the valid criticism and got voted down heavily for it. That way you don't have to feel troubled by defending me for whatever reason that it is problematic. Instead you would merely be agreeing with me on an isolated point.

                Hope that's of use.

      2. h4rm0ny

        Re: That's the unix way of doing things..

        >>"The moral of the story is not that there's anything wrong with interpreters (like your diatribe against shells) but the context that they're allowed to be used from. ImageMagick evolved from being a command-line tool and now it's being used in an unsafe context. That is all"

        I disagree. Your argument is to the effect of "it doesn't matter if there are sufficient protections in place", but that's a statement that's always true and always misses the point. The point the OP made was that command-line text to join up different programs is inherently more vulnerable as an approach than calling the APIs of other objects because it is inherently more open to malicious input. If in this case, ImageMagick was written to call the "imageconvert()" method of an object, even if you could provide a variety of such objects that implemented it in different ways, that would be inherently safer than having it exec to the command line "jpegtool --convert myImage.jpg" where the command line is, by necessity, assembled from different parts and thus needs the kind of "jail" that you talk about in your anecdote.

        OP is correct.

    2. Ian Michael Gumby

      @AC ...Re: That's the unix way of doing things..

      Before you bash Linux/Unix...

      Looking at the exploit, unless you run ImageMagick as root, you're limiting the potential damage.

      Yeah, this is brain dead, but, it could be worse.

      1. h4rm0ny

        Re: @AC ...That's the unix way of doing things..

        >>"Before you bash Linux/Unix... Looking at the exploit, unless you run ImageMagick as root, you're limiting the potential damage."

        Something that runs as the webserver (ImageMagick is a library compiled into PHP amongst other things), then that's quite enough damage, thanks. Being able to connect to the sites database and run arbitrary commands, scan the entire webroot, and even (though this should normally be blocked by other measures) potentially write to it is not something that should be described as "Limited" without context.

    3. ElReg!comments!Pierre

      Re: That's the unix way of doing things..

      The most annoying "flaws/features" in imaging libraries stem from the perceived need (by users) to stay friendly with idiotic image formats, mostly proprietary ones, as pushed by, for example, Microsoft (who were the first to force command-containing image formats to the hapless masses). Hardly a *NIX problem then (unless by *NIX problem" you really mean "the will to play nice with idiotic image formats pushed by non-*NIX companies")

  4. Charlie Clark Silver badge

    Who's using ImageMagick on the server?

    It's a command line tool for batch processing lots of your own stuff, never give it anything from an unknown source.

    Most programming languages have bindings for the relevant image handling libraries.

    1. #define INFINITY -1

      Re: Who's using ImageMagick on the server?

      Like this: http://php.net/manual/en/book.imagick.php ?

      1. Charlie Clark Silver badge

        Re: Who's using ImageMagick on the server?

        oh, PHP? To be expected really and I have no sympathy.

      2. Anonymous Coward
        Anonymous Coward

        Re: Who's using ImageMagick on the server?

        ImageMagick is used on tons of Wordpress and Drupal sites. The alternative is libgd which has its own problems.

        I've used ImageMagick on Python sites as well; functionally it's miles ahead of PIL.

        1. Ramazan

          Re: Who's using ImageMagick on the server?

          > I've used ImageMagick on Python sites as well; functionally it's miles ahead of PIL.

          I used PIL with Python and GD with Perl just because I didn't like ImageMagick's bloat.

          1. Anonymous Coward
            Anonymous Coward

            Re: Who's using ImageMagick on the server?

            Last decade I switched from PIL to GD to ImageMagick because of image quality, in spite of their inferior APIs and code quality. A few clients/employers thought PIL in particular looked worse than other sites; I did some comparisons and they were absolutely right.

            And, PIL and GD have not seen much improvement (or security patching?) since then. Although I just noticed there's a fork of PIL called Pillow.. anyone using that?

        2. John Sanders

          Re: Who's using ImageMagick on the server?

          In my experience it is not that popular, php.gd on the other hand is.

    2. Ian 55

      Re: Who's using ImageMagick on the server?

      It's on one of my servers (actually, I thought it was more) so that I can do occasionally necessary batch processing of stuff there.

      I don't think it's listening to the outside world, and the firewall would block it if it were, but I've just changed policy.xml to make sure.

    3. Anonymous Coward
      Anonymous Coward

      Re: Who's using ImageMagick on the server?

      And where do you believe a lot of batch processing happens and how files are loaded today?

      Also, to use image processing libraries you usually need to know what you're doing. ImageMagik offers and higher level "API", just it offers it the wrong way.

      And don't forget many scripting languages, including those used for web server side programming, are not the best to manage binary data and buffers, maybe through all those scaring "pointers". The low hanging fruit is to write image data to a file and then invoke a command line tool upon it... too many developers are unable to master the art of complex programming and keep on using outdated paradigms just because they are easier to use - the result is software cobbled together and vulnerable. But the biggest problem are those who tell them it's right because they too never left the past.

  5. tin 2

    Lest we forget

    Hmmm. trust the file extension followed by mistrust the file extension. File extensions still going in 2016, who'd have thought it?

    1. Anonymous Coward
      Anonymous Coward

      Re: Lest we forget

      With the proliferation of file types extension are a simple way to identify them even without a GUI to display an icon (if one is available), and without having to process every file to try to understand what it is (not every file has an easy header to read), or even to tell what a text file is - a .conf file tells you it has a different use than a .c or .txt one.

      The only other option would be to attach metadata to the file in the filesystem - some OS did (Apple and OS/2, IIRC), but usually those attributes are not portable and are lost when a file is moved across different systems. Especially, good luck with the poor file attribute systems from the 1970s... when there were only two types of files, executable and text ones... ah, if only we could save images into text files and perform image editing with vi!

      1. ElReg!comments!Pierre

        Re: Lest we forget

        >ah, if only we could save images into text files and perform image editing with vi!

        It is, indeed, very easy to do. Most imaging libraries allow you to save the bitmap of an image to raw text (ImageMagick does, for example). That's one of the safest ways to handle images. It works well, I've used it; I actually designed a few advanced scientific image analysis scripts (5-D image cross-correlation to name but one use) based entirely on text parsing (not using Vi, obviously, that would be an unnecessary overhead). Some are still in use.

        That's also how it's done by most scientific software (MatLab, anyone?) but these usually give a whole new meaning to the expression "useless overhead".

        1. Brewster's Angle Grinder Silver badge

          Re: Lest we forget

          Yeah, PNM files have saved my hide. But that was in the days before PNG.

        2. Anonymous Coward
          Anonymous Coward

          Re: Lest we forget

          Sorry for the downvote, but text formats are anything but inherently safe. Text parsing is one of the trickiest things to get right. Even a simple format like PNM could conceivably be used for an exploit, especially if you're using dozens of obscure tools.

  6. drtune

    Damn this is huuuuge

    Practically every server in the world uses Imagemagick to process images uploaded by the public - and it's wiiiide open... LOLZ!

    I've certainly set up more than one server that's vuln to this... patchin' time!

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021