Status of CVE

[broucaries]

What are the status of these CVEs ? Could you give me the git commit fixing these problems:

CVE-2016-8862 imagemagick: memory allocation failure in AcquireMagickMemory (memory.c)
CVE-2016-8678 heap-based buffer overflow in IsPixelMonochrome
CVE-2016-8866

[dlemstra]

CVE-2016-8678 was created with a Q64 build and we do not support Q64. We're waiting for 128bit processors to get Q64 to work.

Both CVE-2016-8862 and CVE-2016-8866 are resolved with: https://github.com/ImageMagick/ImageMag ... b116b52322. I have no idea why two separate CVE's were created.

[broucaries]

Thanks for this answer.

we agree with the first one. However my security team asked for more information about the two other:
>Hmm. CVE-2016-8866 is actually assiged for "incomplete fix for
>CVE-2016-8862".
>
>CVE-2016-8862 was assigned here:
>
>https://marc.info/?l=oss-security&m=147694131710754&w=2
>
>with gentoo report
>https://blogs.gentoo.org/ago/2016/10/17 ... -memory-c/
>
>But then apparenty Agostino Sarubbo filled
>
>https://marc.info/?l=oss-security&m=147694847912255&w=2
>
>claiming the previous fix for CVE-2016-8862 is incomplete, resulting
>in the assignment in
>
>https://marc.info/?l=oss-security&m=147703506903637&w=2
>
>which is Agostino's report at
>
>https://blogs.gentoo.org/ago/2016/10/20 ... 2016-8862/
>Could you bring that to upstream to see if that clarifies? Who is now
>wrong?
>
>It would actually be good to have the corupus to validate the fixes
>but Agostino only started afterwards apparently to publish those. Any
>insights?

[magick]

As far as we can tell, its a Schrödinger's cat problem-- that is, the problem is not in ImageMagick but in the observer-- that is the address sanitizer. The address sanitizer tries to allocate 41252327424 bytes of anonymous memory-mapped memory and throws an exception (==26027==ERROR: AddressSanitizer failed to allocate). If you disable the memory sanitizer, mmap() is called, fails, and ImageMagick exits gracefully. We are considering adding an additional security policy that limits the amount of heap or anonymous memory-mapped memory that can be requested but have not completed the work yet. In the mean-time we rely on malloc() and mmap() to return failure when the request exceeds system resources and ImageMagick intercepts the failure and gracefully exits. If our analysis is misguided, let us know and we will investigate further.

Regarding a security image corpus-- sounds like a grand idea. Unfortunately we do not have the resources to maintain the corpus. Any volunteers?

[fmw42]

Do you mean "corupus" or "corpus"? I cannot find the former in the dictionary. The latter sound more like what may be discussing

1 a collection of written texts, esp. the entire works of a particular author or a body of writing on a particular subject : the Darwinian corpus.
• a collection of written or spoken material in machine-readable form, assembled for the purpose of studying linguistic structures, frequencies, etc.

[broucaries]

Relying on mmap failure exit code is fine.

Thank you for our clarification

On the debian side we maintain a corpus of exploit. it is under debian/poc.

If no copyright problem we could maintain this corpus.

We are under alioth for git

[magick]

> If no copyright problem we could maintain this corpus.

Yes please. We see no copyright problems.

Fred, in linguistics, a corpus (plural corpora) or text corpus is a large and structured set of texts. In image processing a corpus is a set of images rather than text.

[fmw42]

Fred, in linguistics, a corpus (plural corpora) or text corpus is a large and structured set of texts. In image processing a corpus is a set of images rather than text.

Thanks for the explanation.

But besides my interest in what it meant, you had misspelled it in one case in the following:

Regarding a security image corupus-- sounds like a grand idea. Unfortunately we do not have the resources to maintain the corpus. Any volunteers?