Bitcoin Core Security Disclosure Policy and Disclosure of 10 Old Vulnerabilities

[achow101]

https://bitcoincore.org/en/security-advisories/

https://groups.google.com/g/bitcoindev/c/Q2ZGit2wF7w

The vulnerabilities disclosed today were fixed in 0.21 and earlier. At the end of July, those that were fixed in 22.0 will be published, in August, 23.0, and so on until there are no remaining undisclosed vulnerabilities in end of life Bitcoin Core versions.

[DaveF]

Good to see that this is being made public. It should also give people more confidence that issues are being worked on.

It then made me take a look at bitnodes.io to see how many older versions (14 to 20 )were still running out there. Was surprised to see that it was in the multiple hundreds. There are over 500 nodes just on 0.20.xx alone.
Have to wonder who and why they are running it.

Also brings up the question, has any testing been done to see if any old issues have been reintroduced. Kind of like the OpenSSH vulnerability disclosed earlier this week:

OpenSSH versions earlier than 4.4p1 are vulnerable to this signal handler race condition unless they are patched for CVE-2006-5051 and CVE-2008-4109.

Versions from 4.4p1 up to, but not including, 8.5p1 are not vulnerable due to a transformative patch for CVE-2006-5051, which made a previously unsafe function secure.

The vulnerability resurfaces in versions from 8.5p1 up to, but not including, 9.8p1 due to the accidental removal of a critical component in a function

-Dave

[achow101]

Also brings up the question, has any testing been done to see if any old issues have been reintroduced.

Newly added code has tests.

Several of the issues disclosed today were fixed by throwing away and completely replacing the vulnerable code, so the newly introduced code would have its own tests.

Some things like the miniupnp vulnerabilities are because of that dependency. There isn't a whole lot that we can do about it other than bumping to the latest dependency version or working out ways to get rid of the dependency entirely.

Several issues were discovered via fuzzing, and the fuzz inputs have been added to our fuzz input corpus that oss-fuzz uses. So reintroduction of those specific issues would be caught by those fuzzers.

Otherwise, these bugs can be kind of hard to test for since many of them are stalling issues.

[DaveF]

Also brings up the question, has any testing been done to see if any old issues have been reintroduced.

Newly added code has tests.

Several of the issues disclosed today were fixed by throwing away and completely replacing the vulnerable code, so the newly introduced code would have its own tests.

Some things like the miniupnp vulnerabilities are because of that dependency. There isn't a whole lot that we can do about it other than bumping to the latest dependency version or working out ways to get rid of the dependency entirely.

Several issues were discovered via fuzzing, and the fuzz inputs have been added to our fuzz input corpus that oss-fuzz uses. So reintroduction of those specific issues would be caught by those fuzzers.

Otherwise, these bugs can be kind of hard to test for since many of them are stalling issues.

I get all of that, but what I was thinking about was something closer to the SSH type of issue. It was vulnerable, it was fixed, it was tested fixed, and the someone broke it.
However, since it was fixed and tested they didn't think to test it every release.

I know it's all rare / edge case kind of stuff but going back and making sure something that was fixed didn't get broken again might not be the worst. If it's possible to test for these things.

-Dave

[achow101]

I get all of that, but what I was thinking about was something closer to the SSH type of issue. It was vulnerable, it was fixed, it was tested fixed, and the someone broke it.
However, since it was fixed and tested they didn't think to test it every release.

I don't know what OpenSSH's testing infrastructure is like, but for Bitcoin Core, the unit and functional tests (including regression tests) are run automatically on every PR before being merged, and on the master branch after anything is merged. If the fix included tests for the fix, unless someone removes the tests for the fix, regressions should be caught.

Otherwise it would be insane to manually test for every single bug that was fixed, security or otherwise. That is simply untenable, and that's what testing infrastructure, including fuzzers, is for.