# Haskell Security Response Team - 2024 January–March report
**URL:** https://discourse.haskell.org/t/haskell-security-response-team-2024-january-march-report/9285
**Category:** Announcements
**Created:** [April 8, 2024, 1:03pm UTC](https://discourse.haskell.org/t/haskell-security-response-team-2024-january-march-report/9285 "2024-04-08T13:03:18Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@frasertweedale](https://discourse.haskell.org/u/frasertweedale)
#### Post date: [April 8, 2024, 1:03pm UTC](https://discourse.haskell.org/t/haskell-security-response-team-2024-january-march-report/9285/1 "2024-04-08T13:03:18Z")
The Haskell Security Response Team (SRT) is a volunteer organisation within the Haskell Foundation that is building tools and processes to aid the entire Haskell ecosystem in assessing and responding to security risks. In particular, we maintain a [database](https://github.com/haskell/security-advisories) of security advisories that can serve as a data source for security tooling.
This report details the SRT activities from January through March 2024.
The SRT is:
- Casey Mattingly
- Fraser Tweedale
- Gautier Di Folco
- Mihai Maruseac
- Tristan de Cacqueray
## How to contact the SRT
For assistance in coordinating a security response to newly discovered, high impact vulnerabilities, contact `security-advisories@haskell.org`. Due to limited resources, we can only coordinate embargoed disclosures for high impact vulnerabilities affecting current versions of core Haskell tools and libraries, or in other exceptional cases.
You can submit lower-impact or historical vulnerabilities to the advisory database via a pull request to our [GitHub repository](https://github.com/haskell/security-advisories).
You can also contact the SRT about non-advisory/security-response topics. We prefer public communication where possible. In most cases, [GitHub issues](https://github.com/haskell/security-advisories/issues/new/choose) are an appropriate forum. But the mail address is there if no other appropriate channel exists.
## Advisory database
1 contemporary advisory (affecting 3 packages) was added to the database during the reporting period.
1 historical advisory was added to the database during the reporting period.
Additionally, 1 HSEC ID has been reserved for an embargoed vulnerability that we anticipate will be published early in Q2.
We urge community members to submit to the database any known security issues, including historical issues, that are not yet represented.
## Security risks of bundled/vendored C code in Haskell packages
[HSEC-2024-0002](https://osv.dev/vulnerability/HSEC-2024-0002) was a vulnerability affecting several packages that perform bzip2 compression or decompression. It was introduced by way of _bundled_ (interchangable term: _vendored_) C sources. As demonstrated in this case, there is a risk of these bundled sources not being updated when security issues are discovered and fixed in the “upstream” project.
Thanks to Julian Ospald, HSEC-2024-0002 was resolved in all known affected packages by introducing [_bzip2-clib_](https://hackage.haskell.org/package/bzip2-clib), a new, separate package that contains the (updated) bzip2 cbits. The affected packages were modified to depend on _bizp2-clib_, instead of independently bundling the C sources. This will also make future updates easier. Other packages could benefit from taking a similar approach, especially where multiple packages currently bundle the same upstream C library independently.
There is a clear need for better identification of libraries that contain vendored cbits within the Haskell ecosystem—especially those that are widely depended upon. Issue [#162](https://github.com/haskell/security-advisories/issues/162) tracks this topic. We welcome all community members to contribute to the discussion. The SRT will communicate further about this need in the coming months.
## liblzma / xz utils backdoor
A significant attack against `sshd` via malicious code introduced into `xz`/_liblzma_ was recently discovered. It was assigned **CVE-2024-3094**. Russ Cox published an excellent [timeline of the attack](https://research.swtch.com/xz-timeline). Casey analysed the Haskell ecosystem’s exposure to this risk.
The [`lzma`](https://hackage.haskell.org/package/lzma) package binds to the system library. Any Haskell projects that use this package, or systems on which the resulting artifacts are deployed, **may be compromised if the system package was an affected version**. Because the issue is in the system liblzma package, we will not public an HSEC advisory for this issue.
Very much related to the preceding topic: the [`lzma-clib`](https://hackage.haskell.org/package/lzma-clib) and [`lzma-static`](https://hackage.haskell.org/package/lzma-static) packages bundle the upstream sources. The bundled source code is from versions prior to the attack. Therefore these packages are **unaffected**.
## SRT at Haskell Ecosystem Workshop and ZuriHac 2024
In early June, Gautier and Fraser (maybe Mihai too) will attend the [Haskell Ecosystem Workshop](https://haskell.foundation/events/2024-haskell-ecosystem-workshop.html) and [ZuriHac](https://zfoh.ch/zurihac2024/). Fraser will present at the Workshop to give participants an orientation in the technical details of our tooling, share our ideas for high-impact integration with the advisory database, and propose new work for improving Haskell’s overall security posture.
If you are interested in the security of the Haskell ecosystem, please consider attending the workshop and/or ZuriHac. We look forward to meeting and collaborating with you!
## Introducing `cabal-audit`
Thanks to the work of GitHub user **MangoIV** , we will soon merge the `cabal-audit` program (see [PR #148](https://github.com/haskell/security-advisories/pull/148)). `cabal-audit` runs the Cabal solver on a project, looks for vulnerabilities in the dependencies, and proposes fix versions. Some churn should be expected as the tool matures. We would eventually like _cabal-install_ to have native audit capabilities, but this is a significant step that provides a foundation for technical problem solving and UX experimentation. Thank you for your valuable contributions, MangoIV!
## HTML index and atom feed
In addition to our advisories being [published on OSV.dev](https://osv.dev/list?ecosystem=Hackage), we now generate an HTML index of our advisories, currently hosted at [Haskell Security advisories](https://haskell.github.io/security-advisories/). We also added an [atom feed](https://haskell.github.io/security-advisories/atom.xml).
We would like to also get it hosted somewhere more “canonical”, and improve the appearance (it is quite rough).
## Tooling updates
Advisories now support the optional `capec` field, for recording [_Common Attack Pattern Enumerations and Classifications (CAPEC)_](https://capec.mitre.org/) data. CAPEC differs from CWE in that CWE is a classification of programming or configuration errors that give rise to security weaknesses, CAPEC classifies known patterns of attack.
We introduced the `hsec-sync` command, which is intended for downstream tools to **synchronise a local cache of the advisory content**. It currently clones the whole `security-advisories` Git repo, but that will soon change. Gautier is working on an snapshot format that we will use to distribute advisory data and `hsec-sync` will be modified to download these snapshots instead.
Soon (certainly ahead of ZuriHac in June) we will **publish our libraries on Hackage**. We hope that `cvss`, `cwe` and `osv` packages will be broadly useful, and the `hsec-core` library will be helpful for working with Haskell security advisories.
---
### Author:  [@hasufell](https://discourse.haskell.org/u/hasufell)
#### Post date: [April 8, 2024, 2:43pm UTC](https://discourse.haskell.org/t/haskell-security-response-team-2024-january-march-report/9285/2 "2024-04-08T14:43:21Z")
If I ever had doubts about this project… those are now gone with the wind and I’m rather strongly convinced of the SRT’s success.
---
### Author:  [@Vlix](https://discourse.haskell.org/u/Vlix)
#### Post date: [April 8, 2024, 7:28pm UTC](https://discourse.haskell.org/t/haskell-security-response-team-2024-january-march-report/9285/3 "2024-04-08T19:28:37Z")
Can I just say that, as someone working with Haskell at a company in production, it’s very assuring to know that someone has gone through the Haskell ecosystem to analyze any exposure to the `xz`/`liblzma` issue so I would know what to do if anything had been compromised, and now that I know that nothing has been in this case, I can report so to my manager/CTO.
(I of course looked at what we were using, but it’s good to include not just my findings but that of the “Haskell SRT” as well)
I’m very happy with this report and all the work being put in to make the Haskell ecosystem safer.
Thank you to all the Security Response Team 🙏
---
### Author:  [@simonmic](https://discourse.haskell.org/u/simonmic)
#### Post date: [April 9, 2024, 8:22pm UTC](https://discourse.haskell.org/t/haskell-security-response-team-2024-january-march-report/9285/4 "2024-04-09T20:22:18Z")
Amen! Thanks for your work Security Response Team!
---
### Author:  [@MangoIV](https://discourse.haskell.org/u/MangoIV)
#### Post date: [May 6, 2024, 7:52am UTC](https://discourse.haskell.org/t/haskell-security-response-team-2024-january-march-report/9285/5 "2024-05-06T07:52:03Z")
Hi. Just for completeness, I wanted to note that the work on `cabal-audit` has been moved to [its own repository](https://github.com/MangoIV/cabal-audit) for the fear of scope creep in the original repo. `cabal-audit` is in a usable state, if you like, you can try it out.
Please leave feedback in the new repository.
Thanks in advance for (beta-)testing \<3