|
| 1 | +# OQS Vulnerability Response Report: 20241220-hqc-decaps |
| 2 | + |
| 3 | +<!-- |
| 4 | +Copy this template and rename the file following the format YYYYMMDD-vulnerability-name.md format. |
| 5 | +The date should be the date that the report was created. |
| 6 | +
|
| 7 | +The intent of these reports is to help streamline the vulnerability response process. |
| 8 | +No technical details about the vulnerability need to be provided here; those are contained in the security advisories. |
| 9 | +
|
| 10 | +For a completed example, see the report 20241220-hqc-decaps.md in this same directory. |
| 11 | +--> |
| 12 | + |
| 13 | +## Information |
| 14 | + |
| 15 | +<!-- |
| 16 | +Provide links to any associated published GitHub Security Advisories. |
| 17 | +If there are none, provide (or link to) information about the reported vulnerability. |
| 18 | +--> |
| 19 | + |
| 20 | +See https://github.com/open-quantum-safe/liboqs/security/advisories/GHSA-gpf4-vrrw-r8v7 |
| 21 | + |
| 22 | +## Process |
| 23 | + |
| 24 | +### 1. Intake |
| 25 | + |
| 26 | +<!-- |
| 27 | +Briefly summarize how the vulnerability report was received. |
| 28 | +Be sure to include the following information: |
| 29 | +- intake method (e.g., [email protected], GitHub security report, internal meeting) |
| 30 | +- date of report |
| 31 | +- initial response time |
| 32 | +- initial responder |
| 33 | +--> |
| 34 | + |
| 35 | +We received an initial report from Quarkslab researchers Célian Glénaz and Dahmun Goudarzi via GitHub on 17 September 2024. |
| 36 | +Due to GitHub configuration issues, we were unaware of the report until 24 October, when the reporters left a follow-up comment. |
| 37 | +We did not respond to the reporters until completing the Assessment phase. |
| 38 | + |
| 39 | +### 2. Assessment |
| 40 | + |
| 41 | +<!-- |
| 42 | +Briefly summarize the assessment process. |
| 43 | +Technical details about the vulnerability are not necessary. |
| 44 | +Instead, focus on which projects were impacted and |
| 45 | +Be sure to include the following information: |
| 46 | +- OQS subprojects affected by the vulnerability |
| 47 | +- upstream sources notified |
| 48 | +- team members identified and assigned to work on a fix |
| 49 | +--> |
| 50 | + |
| 51 | +Douglas shared the report with Spencer, who was the team member most familiar with the affected code (the HQC implementation). |
| 52 | +Spencer confirmed the report's findings and responded to the reporters on GitHub on 6 November. |
| 53 | +The vulnerability was present in upstream code (https://pqc-hqc.org) and pulled into the library via PQClean. |
| 54 | +Spencer notified the "main" and "backup" contacts listed on the upstream source's website after coordinating with the reporters. |
| 55 | +The only subproject directly affected (by including vulnerable code) was liboqs. |
| 56 | +It was believed that liboqs-rust was also affected; however, this turned out not to be the case. |
| 57 | + |
| 58 | +Douglas and Spencer consulted and decided not to create a dedicated security release for two reasons: |
| 59 | +1. The 0.12.0 release of liboqs was imminent, so a patch could be included there. |
| 60 | +2. HQC was still an experimental algorithm. |
| 61 | + |
| 62 | +### 3. Patching |
| 63 | + |
| 64 | +<!-- |
| 65 | +Briefly summarize the patch development process. |
| 66 | +Be sure to highlight any friction points. |
| 67 | +--> |
| 68 | +Spencer created a temporary private fork via the draft GitHub advisory and developed a PR with a fix using the `copy_from_upstream` patch mechanism. |
| 69 | +One of the reporters reviewed and approved the PR. |
| 70 | +The fix was merged into liboqs main branch on 21 November. |
| 71 | +Due to liboqs GitHub settings, the PR from the private fork could not be merged directly. |
| 72 | +It was necessary for an administrator (in this case, Ry Jones) to override these settings and commit to main. |
| 73 | + |
| 74 | +### 4. CVE assignment |
| 75 | + |
| 76 | +<!-- |
| 77 | +Was a CVE assigned? |
| 78 | +If not, provide rationale. |
| 79 | +--> |
| 80 | +GitHub assigned CVE-2024-54137. |
| 81 | + |
| 82 | +### 5. Public disclosure |
| 83 | + |
| 84 | +<!-- |
| 85 | +Provide details about public disclosures (e.g., release notes, emails) other than the GitHub Security Advisories already included in the "Information" section. |
| 86 | +--> |
| 87 | +The security advisory was published on 6 December. |
| 88 | +Version 0.12.0 of liboqs was released on 9 December, with a note about the vulnerability in its release notes: https://github.com/open-quantum-safe/liboqs/releases/tag/0.12.0 |
| 89 | + |
| 90 | +Spencer submitted the fix to PQClean (https://github.com/PQClean/PQClean/pull/578) on 10 December. |
| 91 | +This led to a related security advisory being published for the pqcrypto Rust crate: https://github.com/PQClean/PQClean/security/advisories/GHSA-753p-wrj5-g8fj |
| 92 | + |
| 93 | +### 6. Feedback |
| 94 | + |
| 95 | +<!-- |
| 96 | +Highlight any friction points in the response process. |
| 97 | +Feel free to provide suggestions to improve the process. |
| 98 | +Additionally, mention any follow-up work related to the vulnerability. |
| 99 | +--> |
| 100 | + |
| 101 | +We observed the following obstacles throughout the process: |
| 102 | +- Our initial response was very slow due to misconfiguration of GitHub notifications. |
| 103 | + This has hopefully been amended. |
| 104 | +- Merging the patch required "admin"-level access on GitHub. |
| 105 | + Based on GitHub logs, this seems to be due to liboqs settings requiring a pull request for all commits. |
| 106 | + Apparently, a PR from a private fork does not count. |
0 commit comments