Haskell Security Response Team - Haskell Ecosystem Workshop 2024
I discuss the results, ongoing work and future of the Haskell Security Response Team at the 2024 Haskell Ecosystem Workshop, colocated with ZuriHac 2024.
▶ Primary motivation: enterprise adoption ▶ Without a security response structure and artifacts, Haskell is a non-starter for many companies ▶ Makes Haskell an easier choice even without hard regulatory/compliance requirements ▶ We should care about security of our ecosystem anyway :)
tooling ▶ Triage, assess and admit issue reports ▶ Coordinate repsonse with maintainers of affected packages (high-impact issues) ▶ Collaborate and respond to needs of downstream tools that consume our advisories ▶ Quarterly report
CommonMark description ▶ arranged by namespace and package/component name ▶ symlinks for multi-package advisories ▶ quirk: dates are derived from Git commit times
= ["json", "dos", "historical"] aliases = ["CVE-2022-3433"] [[affected]] package = "aeson" cvss = "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H" [[affected.versions]] introduced = "0.4.0.0" fixed = "2.0.1.0" ‘‘‘ # Hash flooding vulnerability in aeson *aeson* was vulnerable to hash flooding (a.k.a. hash DoS). The issue is a consequence of the HashMap implementation from *unordered-containers*. It results in a denial of service through CPU consumption. This technique has been used in real-world attacks against a variety of languages, libraries and frameworks over the years.
HTML index: https://haskell.github.io/security-advisories/ ▶ "snapshot" format designed for syncing with tools2 1https://osv.dev/list?ecosystem=Hackage 2https://github.com/haskell/security-advisories/pull/179
data are on Hackage: ▶ https://hackage.haskell.org/package/cvss ▶ https://hackage.haskell.org/package/osv ▶ https://hackage.haskell.org/package/hsec-core ▶ https://hackage.haskell.org/package/hsec-tools Expect churn as more consumers/users arrive, give feedback. CWE3 library is coming. 3Common Weakness Enumeration—https://cwe.mitre.org/
is very low. Why? ▶ Submission process is too hard? (improve the tools) ▶ Haskell just has fewer security bugs? (not significantly, IMO) ▶ People don’t know about it? (increase visibility) ▶ People don’t care?
false positives ▶ e.g. HSEC-2023-0007 readFloat memory exhaustion in base ▶ VEX - Vulnerability Exploitability eXchange ▶ statements that an issue is(n’t) exploitable in the dependent ▶ data model by CISA.gov ▶ implementations: OpenVEX, SPDX 3.0, OASIS CSAF 2.0, CycloneDX ▶ We don’t have to use VEX per se
by machine (call analysis) ▶ Tristan’s experiment: https://github.com/TristanCacqueray/cabal-audit ▶ typeclass methods seem to be the tricky part ▶ relies on declaration of affected functions/symbols in the advisory
supplied by maintainer, or Hackage trustees ▶ distributed in Hackage snapshots ▶ metadata revisions → new version not required to update VEX statements ▶ Advisory DB as a VEX clearing-house ▶ supplied by SRT, or community with SRT review ▶ distributed in Advisory DB snapshots ▶ Both? ▶ requires conflict resolution (preferred source)
(of a single project or whole ecosystem) are increasingly important ▶ That xkcd4 ▶ Identify the load-bearing projects / juicy targets? ▶ Are they maintained? Sustainably? ▶ What are the main risks? ▶ Query projects exposed to external risks ▶ cbits? vendored/bundled code? out of date? ▶ using external libraries? 4https://xkcd.com/2347/
bit of this tooling exists in Open Source Insights ▶ https://deps.dev; Google project ▶ Web, visualisations, API, BigQuery ▶ Haskell is not supported yet ▶ Development is not public (currently) ▶ I have reached out to find out more and offer support ▶ acme-everything becomes useful?
SPDX) ▶ Add Haskell call analysis support to osv-scanner? ▶ Increase issue discovery efforts ▶ OSS-Fuzz support? ▶ OpenSSF Best Practices checking? ▶ Verified crypto libs ▶ . . . and other compliance things that matter in various sectors
▶ Much to do that’s not in the charter ▶ Therefore: expand the charter and grow the team ▶ Gather feedback/ideas this week about: ▶ how scope of SRT should change ▶ topology (sub-teams? separate efforts? how many people?)
anything that improves Haskell security posture ▶ Discussions about SRT evolution ▶ I will default to working on Hackage ▶ Gautier will work on advisory db snapshots ▶ MangoIV will work on cabal-audit ▶ Beginner-friendly tasks: ▶ cvss/osv/hsec-core CVSS 4.0 support ▶ Haskell.org security page - https://github.com/haskell-infra/www.haskell.org/issues/293
is licensed under http://creativecommons.org/licenses/by/4.0/ SRT code github.com/haskell/security-advisories My blog frasertweedale.github.io/blog-fp Fediverse @[email protected]