|
| 1 | +# Haskell Security Response Team - 2023 July–December report |
| 2 | + |
| 3 | +The Haskell Security Response Team (SRT) is a volunteer organization |
| 4 | +within the Haskell Foundation that is building tools and processes |
| 5 | +to aid the entire Haskell ecosystem in assessing and responding to |
| 6 | +security risks. In particular, we maintain a [database][repo] of |
| 7 | +security advisories that can serve as a data source for security |
| 8 | +tooling. |
| 9 | + |
| 10 | +This report details the SRT activities from July to December 2023. |
| 11 | +The SRT is supposed to report quarterly, but we missed giving a Q3 |
| 12 | +report. We'll try not to let that happen again. |
| 13 | + |
| 14 | +The SRT is: |
| 15 | + |
| 16 | +- Casey Mattingly |
| 17 | +- Fraser Tweedale |
| 18 | +- Gautier Di Folco |
| 19 | +- Mihai Maruseac |
| 20 | +- Tristan de Cacqueray |
| 21 | + |
| 22 | + |
| 23 | +## How to contact the SRT |
| 24 | + |
| 25 | +For assistance in coordinating a security response to newly |
| 26 | +discovered, high impact vulnerabilities, contact |
| 27 | +`[email protected]`. Due to limited resources, we can |
| 28 | +only coordinate embargoed disclosures for high impact |
| 29 | +vulnerabilities affecting current versions of core Haskell tools and |
| 30 | +libraries. |
| 31 | + |
| 32 | +You can submit lower-impact or historical vulnerabilities to the |
| 33 | +advisory database via a pull request to our [GitHub |
| 34 | +repository][repo]. |
| 35 | + |
| 36 | +You can also contact the SRT about non-advisory/security-response |
| 37 | +topics. We prefer public communication where possible. In most |
| 38 | +cases, [GitHub issues][gh-new-issue] are an appropriate forum. But |
| 39 | +the mail address is there if no other appropriate channel exists. |
| 40 | + |
| 41 | + |
| 42 | +## Advisory database |
| 43 | + |
| 44 | +3 contemporary advisories were added to the database during the |
| 45 | +reporting period. |
| 46 | + |
| 47 | +9 historical advisories were added to the database during the |
| 48 | +reporting period. Most of these were found by searching established |
| 49 | +CVE and vulnerability databases. It is important to record |
| 50 | +historical vulnerabilities so if you know of any, please submit a |
| 51 | +pull request or let the SRT know! |
| 52 | + |
| 53 | + |
| 54 | +## Coordinated disclosure and downstream stakeholders |
| 55 | + |
| 56 | +[`HSEC-2023-0015`][HSEC-2023-0015] was a medium severity theoretical |
| 57 | +attack against `cabal-install`. This was the SRT's first embargoed |
| 58 | +vulnerability where we coordinated disclosure with downstream |
| 59 | +distributions. Unfortunately, we missed an important |
| 60 | +distributor—GHCup—causing some stress and embarrassment. We have |
| 61 | +added GHCup to our list of distributors. |
| 62 | + |
| 63 | +The SRT maintains a public [list of downstream |
| 64 | +stakeholders][stakeholders], as well as some private stakeholder |
| 65 | +addresses. If you want to add a contact point to either the public |
| 66 | +or private list, please let us know. |
| 67 | + |
| 68 | + |
| 69 | +## osv.dev integration |
| 70 | + |
| 71 | +The OSV project aggregates the security advisories for many open |
| 72 | +source languages, ecosystems and projects. In addition to exporting |
| 73 | +our advisory content in the OSV data format and requesting osv.dev |
| 74 | +to import our advisories, we delivered [an enhancement][pr-osv] to |
| 75 | +OSV itself to enable it to understand Haskell package and GHC |
| 76 | +version numbers. |
| 77 | + |
| 78 | +As a result of these efforts, all HSEC security advisories are now |
| 79 | +published in OSV (see https://osv.dev/list?ecosystem=Hackage). |
| 80 | + |
| 81 | + |
| 82 | +## Tooling development |
| 83 | + |
| 84 | +- HSEC IDs can now be reserved (e.g. allocate an ID for an embargoed |
| 85 | + vulnerability). |
| 86 | + |
| 87 | +- Gautier implemented the `hsec-tools query` subcommand for querying |
| 88 | + whether a package/version is affected by any advisories. |
| 89 | + |
| 90 | +- Gautier extracted core advisory data types and functions as the |
| 91 | + `hsec-core` library, separating it from the `hsec-tools` |
| 92 | + executable. We have not yet published it on Hackage, but intend |
| 93 | + to do so. |
| 94 | + |
| 95 | +- Gautier extracted the OSV modules to the `osv` library. We have |
| 96 | + not yet published it on Hackage, but will certainly do so, |
| 97 | + probably in Q1. |
| 98 | + |
| 99 | +- Tristan implemented a library for CVSS parsing, printing and |
| 100 | + calculations. As with the others, it is not yet on Hackage, but |
| 101 | + watch this space. |
| 102 | + |
| 103 | +- Tristian implemented library support for mapping CWE numbers and |
| 104 | + descriptions. |
| 105 | + |
| 106 | +- `hsec-tools` CLI help has been improved. |
| 107 | + |
| 108 | +- Eric Mertens (non-SRT contributor) migrated us to a richer TOML |
| 109 | + library which includes generation, enabling us to print as well as |
| 110 | + parse advisories. |
| 111 | + |
| 112 | +- The `generate-index` subcommand generates an HTML index of the |
| 113 | + advisories. For now it is fairly basic. We plan to publish this |
| 114 | + index somewhere prominent, e.g. within the `haskell.org` site, |
| 115 | + and are currently working through the details. |
| 116 | + |
| 117 | + |
| 118 | +## Future work |
| 119 | + |
| 120 | +We plan to develop GitHub tooling (e.g. webhooks or GitHub app) to |
| 121 | +improve the contributor (and maintainer) experience. For example, |
| 122 | +we can expand CVSS and CWE definitions, or provide contextual help |
| 123 | +to fill out missing fields in the advisory TOML. |
| 124 | + |
| 125 | +As mentioned above, we have several libraries awaiting publication |
| 126 | +on Hackage. We hope that CVSS, CWE and OSV libraries will be |
| 127 | +broadly useful, and the `hsec-core` library will be useful in |
| 128 | +developing enhanced security tooling for Haskell development. |
| 129 | + |
| 130 | +The SRT is eager to provide whatever is needed on our side to |
| 131 | +support the development of "downstream" tooling. In particular, we |
| 132 | +would love to see integration with package repositories (Hackage, |
| 133 | +Flora), and tooling for analysing dependency contraints, build |
| 134 | +plans, freeze files, GHC package databases or similar artifacts to |
| 135 | +detect and advise users of vulnerable packages in (potential) use. |
| 136 | +See also David Christiansen's [call to action][]. |
| 137 | + |
| 138 | +Development of downstream tooling is not in the SRT's current scope |
| 139 | +of work, but it *is* in our charter to do whatever we can to support |
| 140 | +such development. This could include things like advisory schema |
| 141 | +changes, enhancing our libraries, or consultation and co-design. If |
| 142 | +you want to contribute to these important efforts, and especially if |
| 143 | +you are a developer/maintainer of an obvious integration target, the |
| 144 | +SRT would love to hear from you and support you. |
| 145 | + |
| 146 | + |
| 147 | +[repo]: https://github.com/haskell/security-advisories |
| 148 | +[gh-new-issue]: https://github.com/haskell/security-advisories/issues/new/choose |
| 149 | +[pr-osv]: https://github.com/google/osv.dev/pull/1463 |
| 150 | +[HSEC-2023-0015]: https://osv.dev/vulnerability/HSEC-2023-0015 |
| 151 | +[stakeholders]: https://github.com/haskell/security-advisories/blob/main/PROCESS.md#downstream-stakeholders |
| 152 | +[call to action]: https://discourse.haskell.org/t/would-you-like-to-write-a-security-advisory-analyzer/7638 |
0 commit comments