News for hackers. Stuff that matters.
Re:Remote Code Execution in ImageMagick (CVE-2016–3714) by asteadman on Tuesday May 03, 2016 @03:00PM (#11623279)
I assume Lambda is affected? According to http://docs.aws.amazon.com/lambda/latest/dg/current-supporte..., Lambda functions have access to ImageMagick-6.7.8.9. I'm not sure how you can specify a policy file in such an environment.
Re:Remote Code Execution in ImageMagick (CVE-2016–3714) by barnybug on Wednesday May 04, 2016 @04:59AM (#11627105)
Yes, confirmed ImageMagick on Lambda is vulnerable.
Re:Remote Code Execution in ImageMagick (CVE-2016–3714) by michaelmcmillan on Tuesday May 03, 2016 @03:22PM (#11623462)
Re:Remote Code Execution in ImageMagick (CVE-2016–3714) by oneweekwonder on Tuesday May 03, 2016 @03:33PM (#11623529)
Any insight?
Re:Remote Code Execution in ImageMagick (CVE-2016–3714) by alxndr on Tuesday May 03, 2016 @03:55PM (#11623689)
No insight, but the diff is easier to look at if you tell GitHub to ignore (most) whitespace with `?w=1`: https://github.com/ImageMagick/ImageMagick/commit/e93e339c?w...
Re:Remote Code Execution in ImageMagick (CVE-2016–3714) by bpicolo on Tuesday May 03, 2016 @04:28PM (#11623960)
That diff seems logicless
Re:Remote Code Execution in ImageMagick (CVE-2016–3714) by alxndr on Tuesday May 03, 2016 @04:38PM (#11624033)
With a commit message like "whitespace cleanup" I would expect the diff to look something like that.

I like to have GitHub show the diff with whitespace ignored as it's then easier to verify that no other code changes snuck in to the commit(s).

Re:Remote Code Execution in ImageMagick (CVE-2016–3714) by chatmasta on Tuesday May 03, 2016 @02:41PM (#11623145)
The article doesn't reveal much, but judging from the list of vulnerable coders and the fact that the Imagemagick forum post references the delegates.xml file, I imagine the exploit allows users to create their own delegate [0], then upload an image that causes that delegate to be called. My guess is that the exploit is two parts: 1) appending a line to the delegates.xml file by exploiting a vulnerable coder, and 2) exploiting the custom delegate you create.

Delegates seem very dangerous and there's all sorts of ways to exploit a custom delegate.

I'm surprised we haven't seen more Imagemagick vulnerabilities... it's a really old library with a massive codebase supporting tons of file formats and arbitrary command chaining. And it's often called by higher level languages via functions like `system()` or `shell()` where developers could easily neglect to "properly sanitize" user inputs, since what those "inputs" can be is so wide ranging.

[0] http://www.imagemagick.org/Usage/files/#delegates

EDIT:

Looks like I was right... check out this commit from 3 days ago:

https://github.com/ImageMagick/ImageMagick/commit/06c41aba39...

"Sanitize input filename for http / https delegates"

So presumably the attack is to set the "filename" property of a file such that when including '%f' in a command, the filename breaks the shell command and inserts its own arbitrary code.

EDIT 2:

A reddit user also linked to this critical line: https://github.com/ImageMagick/ImageMagick/blob/e93e339c0a44...

So the process would be something like this:

1) Create file with name e.g. evilserver.com/funnycat';rm-rf/;.gif hosted on remote server

2) Somehow instruct vulnerable imagemagick install to download evilserver.com/funnycat';rm-rf/;.gif

3) Assume 99% chance that the render command on server will include %f, which is unsanitized, and will cause rm -rf / to execute

I'm a bit confused on step (2)... how do you tell imagemagick to download a file? Will this only affect installations that are explicitly downloading untrusted URLs from users? Like if imgur "upload via URL" fed the URL directly to imagemagick, it would be vulnerable...