Add HSEC-2024-0002

[TristanCacqueray]

Advisory

• It's not duplicated
• All fields are filled
• It is validated by hsec-tools

Fixes: #156 #155

[frasertweedale]

CVSS score is 9.8, which seems quite high considering the linked blog post. I haven't fully disgested the issue yet, just pointing it out.

[hasufell]

[[references]]
type = "FIX"
url = "https://sourceware.org/git/?p=bzip2.git;a=commit;h=7ed62bfb46e87a9e878712603469440e6882b184"

[hasufell]

[[references]]
type = "ADVISORY"
url = "https://www.cve.org/CVERecord?id=CVE-2019-12900"

[TristanCacqueray]

CVSS score is 9.8, which seems quite high considering the linked blog post. I haven't fully disgested the issue yet, just pointing it out.

I agree, it's also unclear if a remote attacker can easily trigger this, can the affected code be reached through an http request using bzip2 content-encoding?

Can GHC produces a different/vulnerable memory layout for the cbits than the "current compilers" used in the blog post?

Is there a precedent where a downstream CVSS score differs from the one assigned to the CVE upstream?

[hasufell]

I'd also suggest to make clear that this bug stems from the fact that all these haskell packages bundle C library source code. For bzlib, only windows users are affected.

[TristanCacqueray]

[[references]]
type = "ADVISORY"
url = "https://www.cve.org/CVERecord?id=CVE-2019-12900"

Thanks, I've added the CVE to the aliases attribute.

[hasufell]

The other question is: do we list packages that use bzlib/bz2/bzlib-conduit directly here too? E.g. ghcup uses bzlib/bz2.

My intuition says no. Unless someone can demonstrate that those packages themselves exhibit exploitable behavior.

[TristanCacqueray]

The other question is: do we list packages that use bzlib/bz2/bzlib-conduit directly here too? E.g. ghcup uses bzlib/bz2.

My intuition says no. Unless someone can demonstrate that those packages themselves exhibit exploitable behavior.

That sounds correct, for example in HSEC-2023-0007 we included toml-reader.

[frasertweedale]

http://scary.beasts.org/security/CESA-2008-005.html is a detailed analysis that explains why this issue is not (trivially?) exploitable. I think we should include it in the references.

Red Hat's advisory for this problem is here: https://access.redhat.com/security/cve/cve-2019-12900.
They gave a CVSS score of CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L (4.0). I would be inclined to set Integrity Impact: Low. As far as I can see, in the absence of a concrete way to exploit this bug, the only thing actually impacted is Integrity (memory corruption within the address space of the process); Confidentiality and Availability are, as far as has been demonstrated so far, not impacted at all.

[TristanCacqueray]

@frasertweedale that sounds reasonable, but is there any chance that when compiled with ghc the selectorMtf layout could be different?

Also the introduced versions might be too permissive, I just picked the oldest one.

[frasertweedale]

Thanks for the updates. A couple more comments.

[frasertweedale]

I propose instead: /C:N/I:L/A:N. But I might be missing or misunderstanding something, so let us discuss.

[TristanCacqueray]

That sounds good to me, the new score is Medium, 4.0

[frasertweedale]

I'd also suggest to make clear that this bug stems from the fact that all these haskell packages bundle C library source code. For bzlib, only windows users are affected.

We should define a standard keyword for indicating that a vulnerability comes from "vendored" code. That way we can keep track of statistics about how many advisories arise in a similar way. Maybe vendored-code? This would also cover situations where a vulnerability arises from code included via e.g. a Git submodule.

I think we should also add a label for tracking issues in arising in bundled code (whether "vendorised" or original) in languages other than Haskell. I propose the scheme language-{lang}, so in this case, language-c.

And if we agree on a convention like this, we will also have to document it somewhere :)

[hasufell]

I'm not sure what is the difference between vendorized and bundled here?

[frasertweedale]

I'm not sure what is the difference between vendorized and bundled here?

I think we're talking about the same thing. I don't mind what term we use. Whatever is more widely understood is probably best.

[hasufell]

I created a new central package that does nothing but bundle the C sources: https://hackage.haskell.org/package/bzip2-clib-1.0.8

Then I created PRs for all 3 affected packages utilizing that new package:

• Fix CVE-2019-12900 hackage-trustees/bzlib#5
• CVE 2019 12900 snoyberg/bzlib-conduit#11
• https://hub.darcs.net/vmchale/bz2/issue/4

[frasertweedale]

I created a new central package that does nothing but bundle the C sources: https://hackage.haskell.org/package/bzip2-clib-1.0.8

Then I created PRs for all 3 affected packages utilizing that new package:

* [Fix CVE-2019-12900 hackage-trustees/bzlib#5](https://github.com/hackage-trustees/bzlib/pull/5)

* [CVE 2019 12900 snoyberg/bzlib-conduit#11](https://github.com/snoyberg/bzlib-conduit/pull/11)

* https://hub.darcs.net/vmchale/bz2/issue/4

Thank you, nice approach! Hopefully the upstream maintainers have capacity to accept the PRs and cut new releases.

[hasufell]

@frasertweedale does the security team have a list of hackage usernames I can add to the package as maintainers?

[frasertweedale]

@frasertweedale does the security team have a list of hackage usernames I can add to the package as maintainers?

@hasufell in general, SRT will not (co-)maintain packages other than our own tooling and supporting libraries. That said, if any individual SRT members want to volunteer, they can say so. If there is no volunteer I will (for completeness) ask at the next SRT meeting on 2024-03-20.

I do see that there may be a need for identification and active (possibly collective) maintainership of those "batteries included" libraries that are not core libraries under CLC purview, but still widely used. The work of identifying important but un(der)maintained libraries would be a good activity for the SRT.

[hasufell]

bz2 and bzlib-conduit are fixed:

• https://hackage.haskell.org/package/bzlib-conduit-0.3.0.3
• https://hackage.haskell.org/package/bz2-1.0.1.1

bzlib pending: haskell/bzlib#8

[hasufell]

bzlib fix released too: https://hackage.haskell.org/package/bzlib-0.5.2.0

[frasertweedale]

I'm happy with the current content but would like to squash the commits.

Also, not sure what's busted in the CI. Some cache expired maybe? I will try and find time to look but pinging @blackheaven in case he can help diagnose the issue.

[blackheaven]

I'll have a look

[frasertweedale]

CI is green again. Thanks @TristanCacqueray for squashing. I will merge it now!

[hasufell]

How is the community informed about these HSECs? Through discourse, weekly Haskell letter?

[frasertweedale]

How is the community informed about these HSECs? Through discourse, weekly Haskell letter?

@hasufell Currently we publish to

• osv.dev: https://osv.dev/list?ecosystem=Hackage
• HTML page: https://haskell.github.io/security-advisories/
• Atom feed (PR will be merged very soon)

We want to see enhancements to Hackage-server and Cabal-install to increase visibility of vulnerable package versions and enable dependency auditing. SRT will collaborate with those projects to see these ideas made real.

Besides that, I created a new issue to discuss other places we should publish or notify about new advisories: #161. Please share your ideas over in that ticket. Thanks!