Hugo Lefeuvre <[email protected]> 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 <[email protected]>
