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 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.
You can also contact the SRT about non-advisory/security-response topics. We prefer public communication where possible. In most cases, GitHub issues 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 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, 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 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. Casey analysed the Haskell ecosystem’s exposure to this risk.
The 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 and 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 and ZuriHac. 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). 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, we now generate an HTML index of our advisories, currently hosted at Haskell Security.Advisories.Core. We also added an atom feed.
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) 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.
