Back in september 2023, during the Coredev in the Azores, we (the group of Bitcoin Core contributors present) discussed we (as a project) should do a better job of tracking and disclosing security-critical bugs. A bunch of us volunteered to dig up old reports (disclosed or not), set up some private infra to track vulnerabilities and come up with a disclosure policy. The group is comprised of Ava Chow, Michael Ford (fanquake), Niklas Gögge, Antoine Poinsot, Anthony Towns and Pieter Wuille.
In march 2024, during the Coredev in Berlin, this group had another discussion regarding the disclosure policy involving other long-time contributors. It was decided to go through all the past reports which were dug up to inform our disclosure policy. "If bug X was reported today, how should we treat it?". Following this the group had a couple of calls to decide on a disclosure policy.
When reported, a vulnerability would be assigned a severity category. We differentiate 4 classes of vulnerabilities:
- Low: bugs which are hard to exploit or have a low impact. For instance a wallet bug which requires access to the victim's machine.
- Medium: bugs with limited impact. For instance a local network remote crash.
- High: bugs with significant impact. For instance a remote crash, or a local network RCE.
- Critical: bugs which threaten the whole network's integrity. For instance an inflation or coin theft bug.
Critial bugs would most likely require an ad-hoc procedure. As they are very rare and it's hard to come up with a standard policy for those in advance, we do not consider them here. Instead we focus on a standard policy for the large majority of the reports, which range from low to high severity.
A bug may also not get into any category at all. A reported issue may be considered seriously yet not be classified as a vulnerability because it does not require secrecy.
Low severity bugs will be disclosed 2 weeks after a fix is released. A pre-announcement would be made at the same time as the release.
Medium and high severity bugs will be disclosed 2 weeks after the last affected release goes EOL. This is approximately a year and a half after it was first released. A per-announcement would be made 2 weeks earlier.
- Share with the wider groupe of Bitcoin Core contributors.
- Announce the policy to the wider Bitcoin developer community through the
bitcoin-dev
mailing list. Request feedback. We are not asking people to tell us how they think we should handle this, we are asking if this would be harmful to anybody for objective reasons we may have overlooked.
- Example of valid feedback: "I'm in charge of mining infrastructure. We are occasionally running a couple versions of Bitcoin Core behind for reason X. Given our past experience i believe it's possible for a business like ours to not be capable of upgrading within 2 weeks of the version we are running going EOL for reasons Y and Z. This is unlikely, still i think a pre-announcement period of 1 month instead would make sure to err on the safe side."
- Example of invalid feedback: "I just Google'd 'CVE best practices' and here is how you should do things instead or else it's an attack on Bitcoin" (except passed through ChatGPT to get to 10k words).
- Try to communicate it to a wider audience. Ping the Optech guys, etc..
We want to publish historical reports. We also want to gradually start enforcing the policy, to let the chance to everyone who didn't to upgrade. To this effect we are going to incrementally disclose security bugs which were fixed in past releases, up to the point where the bugs for all EOL releases will have been disclosed.
We'll start this month (june) with historical bugs: all which were fixed in 0.21.x and below (we have undisclosed bugs for as old as 0.11). Barring any good reason to change course (through the feedback received from users) we would continue in July for bugs fixed in 22.x. In August for bugs fixed in 23.x. Etc..
@dergoegge
In a world where users are generally running application softwares on top of bitcoin core, severity impact becomes hard to evaluate in itself. Turns out most of bug types that are proposed to be classified as medium - high severity can easily escalate as coin thefts bugs on upper layer. E.g a medium local network remote crash of a full node can easy be leveraged to steal lightning channel funds.
Beyond, I believe your statement is uncorrect in saying that EOL dates are known well in advance. From a read of "Lifecycle" on Bitcoin Core website, there is still not displayed EOL dates for 25.0, 26.0, 27.0, neither there was an EOL date announced with 27.0 release email. In my opinion, EOL date should be available to users at code or tarballs download like done for linux kernels. (edited: corrected english and added link).
This is correct that ~12-18 months is what generally observed as an embargo period for browser and mobile OS RCEs, sometimes for side-channels attacks cycles can take more times as chips vendors have to develop and release micro-code before kernel devs can actually write their own mitigations. Beyond, this is ignoring the fact that chromium or ios / major android flavors have dedicated distribution channels, where most of the time they can "push" upgrades to their end-users.
About bitcoin, you certainly wish that the software definition of your money has not changed between two upgrades.
@darosior
About PGP signing of disclosure report, this lets you identify who has access to information-sensitive report and in case of any ulterior leak investigate the root causes. There are reasons why linux are pgp-encrypting as much as they can their security-issues coordination communications. I don't know if it it’s something to be done, it can certainly be put in place in the future.
On maintaining a custom numbering scheme, it turns out in my experience (a) the current CVE scheme which is based on usual OWASP top threats doesn't fit well bitcoin types of bug (e.g chain splitting) (b) the scheme doesn't work well when it's protocol-level issues, not affecting a specific codebase and (c) sometimes the CVE assignment authority can be slow in the weeks-span to assign CVEs. That said, it's more something that one can experiment with as a security researcher to watermark its own reports, I don't think there is a strong need to have this formalized in the core-specific disclosure policy.
On reverse-engineering core diffs, yes it all depends with the skills and experience of the security analyst you're talking to. I've seen lighting covert fixes well-done and I've seen bitcoin core covert fixes done in a ugly fashion. Never an easy art. The point being it might be better to go without pre-announcement by default, and then adjust on ad hoc basis if there is a need to do a pre-announcement.
About fork coins, I remember @gmaxwell's position on not pre-disclosing vulnerabilities to other codebases of the same breed than core. Very often fork coins are in an adversarial position w.r.t bitcoin or rarely software robustness is an end in its own sake. My very personal opinion, they somehow succeed in the kernel space to coordinate side-channel vulnerabilities among ISA vendors / chips with adverse interests by laying out strong ethical rules.
In the present case, if the intention is to start disclose 0.11+ historical bugs by June of this year, I think this is not realistic as you need time for any ethical rule to be internalized by the stakeholders of a security-bugs handling process. My recommendation would still be to reach out to the top 10 by market cap of fork coins maintainers and give them few ahead of pre-disclosure by politeness. This is neither my responsibility nor reputation engaged here, so ultimately and a bit cynically I have little care about what is shared with fork coins.