Hacker News new | past | comments | ask | show | jobs | submit login
GraphicsMagick and ImageMagick popen() shell vulnerability via filename (gmane.org)
144 points by marksamman on May 29, 2016 | hide | past | web | favorite | 54 comments

Thanks HN, I have now lost my Twitter profile image and can't upload a new one:


I love that you did that. Never be afraid of breaking things. In this case it's amusing but imagine you would have done this in a banking application and you'd probably be arrested for hacking.

Let's check how much HDD space they got?

|dd if=/dev/zero of=hello.txt bs=1M count=1000000000

I always have a hard time interpreting Twitter posts. Did you link to two images in this post? Were they things you observed when trying to upload an avatar with a filename in accordance with this bug? Why does Twitter crop the images? (This it what I see: https://u.pomf.is/dmomwl.png )

Yes, there are two images. You should be able to click on them separately to open the full images [0][1]. The first screenshot shows a preview of the file with its name which I tried to upload to Twitter, the other one shows what I observed locally through htop when running `convert` on that filename.

0: https://pbs.twimg.com/media/Cjqj3oiXIAAYJix.jpg:large

1: https://pbs.twimg.com/media/Cjqj3pFWkAEaRcD.jpg:large

The current situation reminds me of OpenSSL after Heartbleed - researchers start paying lots of attention and finding other issues after the "main" one. Sad that this is what it takes for a big, old project like ImageMagick to get some TLC.

There's a crucial difference; OpenSSL was designed to be secure. ImageMagick was designed to support hundreds of codecs and thousands of operations.

You can't pivot design on 1.25 million lines of code (est.) very quickly after 25 years of feature-first development process.

I'm a bit skeptical it will happen at all; it would be a multi-million dollar undertaking. Better to describe its design scope and tradeoffs, and get people to use it properly - sandbox it if it's on the server.

I started Imageflow to solve that problem - a server-focused design with strict design rules: security is first, followed by visual quality, followed by performance. We've kept the codebase to just 10kloc and we are 50% feature complete, but need to get a lot more momentum on Kickstarter to make completion possible. See https://www.imageflow.io

The particularly troublesome part of this issue (and the previous big one) is the interaction between all the "power" ImageMagick provides in its filename parsing and its MVG and SVG decoders.

You'd think that just having applications not use user-provided filenames during the conversion process would prevent much of what's been disclosed lately, but no: the MVG decoder exposes all those features to a user that merely controls the content of the input file.

The mitigations from the last big vulnerability will still work against this, but people who merely updated to an ImageMagick that fixed the curl command escaping would be in trouble.

The biggest question I have is why filenames would even need to be treated specially by ImageMagick anyway. Almost all command-line utilities that are designed to be used in pipelines have the convention of using stdin/stdout, and do so without requiring they spawn shells themselves.

"Why?" can be an interesting question with ImageMagick.

Does it need a prefix you can put on a filename that makes the file automatically get deleted after it's read? I don't think so, but there it is.

At some point in the past, someone thought it would be clever.

> The simple solution to the problem is to disable the popen support (HAVE_POPEN)

Is it just me or is this the wrong way to tackle this? The question to me is why the file name being interpreted in some way in the first place, not why popen is being used on the result of the interpretation.

Also, why are pipes even being allowed in the file name in the first place? (I'm asking about POSIX/*nix here, not about ImageMagick.)

> why are pipes even being allowed in the file name in the first place?

Why not? It's a perfectly legitimate (printable) character. The filesystem can't know that one shell or another will come along and use it (and several other characters) for special purposes.

I go the opposite way and rather question why slashes aren't allowed. Non-printable characters, though, I think we could do without them. Put differently, I think it makes sense to let filenames consist of characters, rather than of bytes.

>I go the opposite way and rather question why slashes aren't allowed.

You mean aside from the obvious reason that a slash is the path seperator?

I'm thinking that a path should be a list of directory names (and possibly a file name at the end), not tied to any particular way of representing this list. In some contexts, such as in a shell, concatenating the directory names, with slashes between them, ("/home/bromskloss/hello.txt") might be the way to represent it. In that case, a slash in the name would have to be escaped. Other times, such as in code, an array might be cleaner (["home", "bromskloss", "hello.txt"]).

There are filesystems that let filenames consist of any Unicode characters. Tag-based filesystems do not need to rely on special cased path separators, as long as they provide a sufficient UI and API for file management and interaction.

Linux allows any byte to be a part of a filename except for the null byte and '/'. It's not the kernel or filesystem's fault if some program like sh treats some characters like '|' specially.

But I don't get why you need to use the shell to get your file?

If you have a filename maybe you should manipulate the file directly instead of delegating to the shell.

Interestingly enough, Cocoa on OS X allows '/' but disallows ':', and maps them back and forth when going down to the Darwin layer, as ':' used to be the (always invisible in the UI) path separator pre-OS X.

I'm wondering now if you're as old as I am (old enough to have written code for OS9), or if you're younger but curious about archeological wierdnesses in modern OSs...

> not why popen is being used on the result of the interpretation.

I haven't read the source but I'm guessing that if HAVE_POPEN is undefined, this special argument interpretation is disabled, in which case it would just be two different ways of looking at the same thing.

> Also, why are pipes even being allowed in the file name in the first place?

The sibling comments are correct, but whether or not POSIX supports pipe characters in filenames is irrelevant for the issue at hand. ImageMagick is free to allow any kind of character in the arguments that it accepts. There is no POSIX/*nix magic that would ensure all arguments passed on the command line (or in the xlink:href attribute, as per the SVG example) are valid filenames.

Wow. This is really scary. Especially the SVG issue. Is it common to support xlink:href on servers that use ImageMagick? It seems like that would allow you to read any readable image on the FS anyway, which is a vulnerability in itself.

> It seems like that would allow you to read any readable image on the FS anyway, which is a vulnerability in itself.

It does. You can trivially use the same feature to render the contents of a readable text file into the output image, too.

This is not the first time popen with | has led to security issues. At the same time it doesn't have any legitimate use cases that I can think of. Is there any good reason to not patch popen and remove the support for |s instead?

It can be useful if you want to offload some of the processing to other processes.

    // Open a gzipped file, display progress bar
    snprintf(buf, sizeof(buf), "pv %s | zcat", filename);
    FILE* f = popen(buf, "r");

    // Add an additional processing step when reading file
    FILE* f = NULL;
    if(do_extra_step) {
        snprintf(buf, sizeof(buf), "zcat %s | extra_step", filename);
        f = popen(buf, "r");
    } else {
        snprintf(buf, sizeof(buf), "zcat %s", filename);
        f = popen(buf, "r");
The first example could be replicated by using zlib and reproducing pv's progress bar in-app. More work, but nothing especially tricky about it.

For the second example, it would be more difficult, for two reasons. First, popen() can open either a read or a write pipe, but not both. In order to write to extra_step's stdin, then read from stdout, you'll need to switch over to fork/exec. Second, you'll have to handle all the buffering between zcat and extra_step yourself, rather than getting it for free.

Unfortunately, this is not the only one. In fact, there are so many that there is a dedicate site:


It also contains several PoC.

Does this affect non-SVG (and other weird format I've never heard of) images? (such as jpg, png, bmp, gif)

I'm trying to figure out a way to patch this that doesn't involve recompiling imagemagick. Like most people I get it from dist, compiling it is kindof a PITA.

In case anyone is interested, here's another mirror of the CVE: https://marc.ttias.be/oss-security/2016-05/msg00255.php

So, just like Perl?

Only badly-written perl.

It's a bit like claiming that SQL allows for SQL injection attacks.

Well, the default open() method do perform pipe execs if you prepend or append "|", just like here.


If you're not using two-argument open() in Perl 5, you deserve what you get.

"If you're not using two-argument open() in Perl 5, you deserve what you get."

Pretty sure that's not quite what you meant to say...


If you _are_ using two-arg open, or if you're _not_ using three-arg open.

(Or, the more general case: "If you're using Perl you deserve what you get - if you don't understand all the language features you're using." (And feel free to substitute whatever language will start the argument in place of Perl in that claim...)

If you're not using fork, dup2, execve instead of popen, you deserve what you get.

To be fair, I agree there's some bad code in there, and no real mention of any security concerns. Not good!

Who on earth still uses ImageMagick? Security holes in it are old news. Like 15 year old news.

Unfortunately when it comes to file conversion/creation even, ImageMagick is the best of a bad bunch. Graphics formats are notoriously bad, check out the famous PSD rant on it: http://web.archive.org/web/20090426230545/http://code.google...

Look! It's possible to highlight an entire block of code: https://github.com/zepouet/Xee-xCode-4.5/blob/master/XeePhot...

Maybe we should even link to a specific version of the file, to make sure that nothing breaks when it is updated or moved: https://github.com/zepouet/Xee-xCode-4.5/blob/83394493f51991...

What replacement would you suggest?

Libvips. It also doesn't choke on large files and doesn't fill your tmp dir with GBs large tempfiles.

Most basic image manipulation can be performed using only the standard library packages, if your language includes such (PHP's bundled `libgd2` fork / Golang's `image` package / Qt QImage+QPixMap ). For Python `pillow` is popular.

I don't think ImageMagick is targeted at "basic" image manipulation, though.

Python / Pillow (formerly PIL) could offer a real path here although there's a gap to Imagemagick on things like SVG

I believe php uses imagick under the hood, and even if it does not, I'd rather rely on imagick than on PHP code when accepting exotic formats.

From a security standpoint, wouldn't it be better to rely on PHP (first)? Are you more or less likely to get RCE from PHP or ImageMagick? I'd say PHP has had a lot more eyes on it, security wise.

> From a security standpoint, wouldn't it be better to rely on PHP (first)?

You're joking, right? Popping PHP boxes is script kiddie 101. You might argue that "bad developers make insecure software" but when you're given a toolbox with nothing but oddly shaped hammers it's very hard to make a house.

That's rarely PHP failing but whatever framework/CMS is used. That's like saying C++ is inherently insecure because there exists a lot of software written in C++ with security holes.

Did you read the second sentence I wrote? Just because you can write safe code in a language that tries to make you footgun at every turn, doesn't mean that language is a good language. Pick a language that doesn't suffer from crippling security issues (which, sure, you can workaround -- but why use a language that requires workarounds to get security?).

We started Imageflow (https://www.imageflow.io ) in C to design the C ABI for interop with all the host languages, but we're swapping out components for Rust every time it's possible/practical.

Or, when saving to file for imagemagic, have it be a random temp name, with the correct file extension, read in the result, and only serve it as the original name when downloaded, if it fits the use case.

PHP does not use imagick, but a (forked) libgd2 by default (some distros patch php to use the distro libgd). Imagick is only available if you install a C PHP extension providing an imagick interface.

True, and most people. Despite the issues, it's still really versatile tech.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact