Re: potrace

[Brian May <bam@debian.org>]

Hugo Lefeuvre <hle@debian.org> writes:

>> This is the potrace 0.14 diff, which supposedly resolves CVE-2016-8685
>> and CVE-2016-8686 (which was previously described as not a bug in
>> #843861).
>> 
>> Unfortunately, it is somewhat large...
>> 
>> https://github.com/skyrpex/potrace/commit/b3fce824046abcc0465deb5596d4556b132c77aa
>
> It looks like most of the changes are not related to the CVEs.
>
> And the part fixing CVE-2016-8685 is identical to the patch that was
> already used in stretch (which is buggy in wheezy).

It looks like the bm_new() function, referenced by CVE-2016-8686 has
been refactored. In particular the size calculation has been moved to a
getsize function.

Unfortunately the description of CVE-2016-8686 is vague - "A crafted
image, through a fuzz testing, causes the memory allocation to fail."

Source: http://www.openwall.com/lists/oss-security/2016/10/08/18

I suspect the issue might be that it tries to allocate more memory then
what you would reasonably expect. In the above message it seems to be
trying to allocate 8.5GB if I calculated that correctly.

The reproducer file:

brian@prune:/tmp$ ls -l potrace_testcase 
-rw------- 1 brian brian 157 May  9 17:22 potrace_testcase
brian@prune:/tmp$ file potrace_testcase 
potrace_testcase: PC bitmap, Windows 95/NT4 and newer format, 41 x 1073741825 x 32
brian@prune:/tmp$

Which I guess is shows the problem. I am not sure if the file is
1073741825 pixels along one axis (with very good compression), or if the
headers have been fudged so it looks like the image is bigger then it
actually is.

In what way is a momory allocation failure a security issue? Maybe it
could somehow be used as a DOS attack? Trick a user into running potrace
on a dodgy file, and have it gobble up your memory?
-- 
Brian May <bam@debian.org>