reports: add 2024 Q1 report

reports/2024-04-xx-Q1-report.md

@@ -0,0 +1,179 @@
+# 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.
+
+
+## liblzma / xz utils backdoor
+
+A significant attack against `sshd` via malicious code introduced
+into xz/liblzma was recently discovered.  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**.
+
+Very much related to the preceding topic: the
+[`lzma-clib`][hackage-lzma-clib] and
+[`lzma-static`][hackage-lzma-static] packages bundle the upstream
+sources, at versions prior to those affected by the attack.  Thus
+they 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/