The next edition of my course will be on October 10th in Utrecht, right before the Bitcoin Amsterdam conference. And it has a website now: LearnBitcoinCore.com
Today we finish chapter 8, covering an attack with fake nodes that took place in the summer of 2021.
Now, what’s really interesting is that this fix was published in the weeks before the attack happened. It wasn’t merged into Bitcoin Core yet, but rather just an open pull request, or proposed change. It remained open until shortly after the attack, but then it was merged and released in version 22.0.
So it almost sounds like somebody saw the solution and saw an opportunity to carry out this specific attack. Or perhaps somebody was already planning this attack and then figured they should do it soon, before it was no longer possible.
For more on this attack and related issues, there’s also a great Chaincode Labs podcast episode.
There have been other examples of a situation where publishing a fix may itself have caused the attack. Back in the day, there was an alternative node implementation Bitcoin Unlimited. It had a bug that was fixed, but before the fix was deployed, the bug was exploited by somebody. That attack brought down all the Bitcoin Unlimited nodes at that time.
Additionally, around 2013, something similar didn’t happen, but could’ve happened, on Bitcoin, which we covered in chapter 4. This is because the OpenSSL library was made stricter in its software by imposing constraints on signatures. Had it been discovered only a few months later, after a Bitcoin Core release was already out there with the bug in it, then it would’ve been a zero-day situation. Perhaps in that case, the fix would’ve been disguised as nice cleanup software, rather than a patch for a security vulnerability. If someone had found out, they could’ve posted a slightly different kind of signature and caused a fork because some nodes would accept it and other nodes wouldn’t accept it.
A final example is that of an inflation bug in 2018. It was presented as a fix to a bug that will crash your node. And that was true — it could crash your node — but it could also create inflation. The latter fact was a bit more important, and it was of course not announced, because somebody could’ve exploited it in that window of opportunity.
One way to handle scenarios like this is for developers to pretend that something isn’t a big deal until people have actually downloaded and used the fix — and then to reveal only later that it was actually a much bigger problem they were fixing. This makes it less likely that an attacker detects the vulnerability while it’s still exploitable.
But that’s really not an ideal approach, because in open source development, you want to be very transparent about things you’re changing. Because if you’re not being transparent about fixing a critical bug, then maybe you’re also not transparent about adding inflation. It’s a delicate balance.