-
Notifications
You must be signed in to change notification settings - Fork 18
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
e4350c7
commit a5c4c9a
Showing
1 changed file
with
157 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,157 @@ | ||
| # 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 | ||
| `[email protected]`. 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. | ||
|
|
||
|
|
||
| ## SRT at Haskell Ecosystem Workshop and ZuriHac 2024 | ||
|
|
||
| In early June, members (TODO who?) of the SRT will attend the | ||
| [Haskell Ecosystem Workshop] and [ZuriHac] in June. Fraser will | ||
| present at the Ecosystem 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][]. It's there, but it too needs some | ||
| work. | ||
|
|
||
|
|
||
| [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. | ||
|
|
||
| We will soon (certainly ahead of ZuriHac in June) 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/ |