GraphicsMagick and ImageMagick popen() shell vulnerability via filename

Re:GraphicsMagick and ImageMagick popen() shell vulnerabilit... by zerocrates on Sunday May 29, 2016 @06:39PM (#11798554)

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.

[ Parent | on HN ]

Re:GraphicsMagick and ImageMagick popen() shell vulnerabilit... by userbinator on Sunday May 29, 2016 @07:01PM (#11798633)

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.

[ Parent | on HN ]

Re:GraphicsMagick and ImageMagick popen() shell vulnerabilit... by zerocrates on Sunday May 29, 2016 @07:12PM (#11798668)

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

[ Parent | on HN ]

Re:GraphicsMagick and ImageMagick popen() shell vulnerabilit... by ams6110 on Sunday May 29, 2016 @08:21PM (#11798904)

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

[ Parent | on HN ]