diff --git a/reports/2024-04-08-Q1-report.md b/reports/2024-04-08-Q1-report.md new file mode 100644 index 00000000..abedc483 --- /dev/null +++ b/reports/2024-04-08-Q1-report.md @@ -0,0 +1,182 @@ +# Haskell Security Response Team - 2024 January–March report + +The Haskell Security Response Team (SRT) is a volunteer organization +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][repo] 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][repo]. + +You can also contact the SRT about non-advisory/security-response +topics. We prefer public communication where possible. In most +cases, [GitHub issues][gh-new-issue] 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 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*](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][xz-timeline]. Casey analysed the Haskell ecosystem's +exposure to this risk. + +The [`lzma`][hackage-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`][hackage-lzma-clib] and +[`lzma-static`][hackage-lzma-static] packages bundle the upstream +sources. The bundled source code is from versions prior to the +attack. Therefore these packages are **unaffected**. + +[xz-timeline]: https://research.swtch.com/xz-timeline +[hackage-lzma]: https://hackage.haskell.org/package/lzma +[hackage-lzma-clib]: https://hackage.haskell.org/package/lzma-clib +[hackage-lzma-static]: https://hackage.haskell.org/package/lzma-static + + +## 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] in June. 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][osv-advs], we now generate an HTML index of our advisories, +currently hosted at https://haskell.github.io/security-advisories/. + +We would like to also get it hosted somewhere more "canonical", and +improve the appearance (it is quite rough). + +We also added an [atom feed][]. + +[osv-advs]: https://osv.dev/list?ecosystem=Hackage +[atom feed]: https://haskell.github.io/security-advisories/atom.xml + + +## Tooling updates + +Advisories now support the optional `capec` field, for recording +[*Common Attack Pattern Enumerations and Classifications +(CAPEC)*][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. + +[capec]: https://capec.mitre.org/ + +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. + + +[repo]: https://github.com/haskell/security-advisories +[gh-new-issue]: https://github.com/haskell/security-advisories/issues/new/choose +[HSEC-2024-0002]: https://osv.dev/vulnerability/HSEC-2024-0002 +[Haskell Ecosystem Workshop]: https://haskell.foundation/events/2024-haskell-ecosystem-workshop.html +[ZuriHac]: https://zfoh.ch/zurihac2024/