Topic: Bitcoin Core Security Disclosure Policy and Disclosure of 10 Old Vulnerabilities (Read 175 times)

There were a few times in the past where I worried about some new PR potentially re-introducing an old non-disclosed issue. ...  unfortunately you can't really solve it with testing because *vulnerabilities* (to a greater extent than plain bugs) are often fragile enough that the old trigger condition still won't trigger the issue even if it's reintroduced in some form.

The reason for this is because a bug is more likely when the software accidentally does the wrong thing, something that no one wanted, just by chance... but a vulnerability is more when the software does a thing an attacker wants.  An attacker isn't stopped by the exact sequences of operations needing to be slightly different, etc.  Often the triggering conditions of vulnerabilities are fairly complex, which is part of how ordinary testing failed to catch them to begin with.

But quiet fixes aren't done by making a simple one line change to the issue, but instead by routing around it entirely... so they're not so easy to accidentally reverse.  The kind of place where I think reintroduction was more likely is the reuse of a defective pattern... e.g. did it like this before and that turned out to be flawed because X/Y/Z.

Unfortunately there just really isn't a replacement for experience, even disclosure doesn't do that-- because even now with these issues disclosed it's unlikely too many contributors understand the issues particularly deeply.

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.

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

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.

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:




-Dave

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.