GraphicsMagick and ImageMagick popen() shell vulnerability via filename

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

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

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

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