https://twitter.com/_jom0/status/737081667215601664

:-)

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

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

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

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

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.

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.

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 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.

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

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

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.

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

    // 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");
    }

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.

https://imagetragick.com/

It also contains several PoC.

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.

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

http://docstore.mik.ua/orelly/perl3/prog/ch16_03.htm

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

http://modernperlbooks.com/mt/2010/04/three-arg-open-migrati...

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...)

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...

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.