haskell/security-advisories

bz2 is vulnerable to CVE-2019-12900

hasufell opened this issue · 8 comments

hasufell commented

Mandatory information:

  • Package : bz2
  • cvss: 9.8
  • affected versions:
    • Haskell: 0.1.0.0 - 1.0.1.0
    • Upstream: 1.0.6 and earlier

Optional:

Hackage upstream issue: https://hub.darcs.net/vmchale/bz2/issue/4

Upstream blog post about the issue: https://gnu.wildebeest.org/blog/mjw/2019/08/02/bzip2-and-the-cve-that-wasnt/ (they say it's not actually exploitable with "current compilers")

ulidtko commented

Huh... how is there cvss 9.8 if there's no impact?

And all state after the selectorMtf array in the DState struct would be assigned values right after reading the selectors. And none of the excess selector values would ever be used. So even though there really was an array overwrite, it was completely harmless!

TristanCacqueray commented

Thank you @hasufell for the report, I think we will do a single advisory affecting multiple packages, no need to open one issue here per package, unless it's for a different CVE.

TristanCacqueray commented

@ulidtko perhaps there is a situation where the memory layout is different? In any case, this is the score assigned to the upstream CVE, not sure we should re-evaluate the assessment here.

hasufell commented

I agree. It's not our business to speculate about exploitability. The blog is a useful reference though that should be included.

In practical terms, I'm less worried about the CVE, but about the state of maintenance that all 3 libraries are in. I doubt we had a different result if there was a definitely exploitable CVE.

  • 👍2
frasertweedale commented

@ulidtko perhaps there is a situation where the memory layout is different? In any case, this is the score assigned to the upstream CVE, not sure we should re-evaluate the assessment here.

I think we can use the "upstream" CVSS score as a starting point, but should be willing to revise it (up or down). We also have the capacity to assign different scores for different packages within the same advisory, if appropriate.

frasertweedale commented

In practical terms, I'm less worried about the CVE, but about the state of maintenance that all 3 libraries are in. I doubt we had a different result if there was a definitely exploitable CVE.

That is for sure. I will bring to SRT the topic of how we can better monitor the Haskell ecosystem for problems like these.
I can think of some low-hanging fruit to at least expose more accessible info about libraries that have cbits, explicitly link non-Haskell shlibs, etc. Having that info readily accessible would be a good starting point for building manual or automated audit processes.