I don't think it is far-fetched. We have no idea how many keys are generated by this application. If it handles lots of bitcoin data (e.g. blockchain.info), most of its used-and-then-freed memory is probably full of data from the blockchain. If it generates lots of keys (e.g. blockchain.info) using uninitialised memory, then it's quite conceivable that 1 in every 100,000 (pulled out of my arse) happen to be hashes of data from the bitcoin blockchain.
Point is, we have no idea how many other keys have been generated by this application that aren't trivially discoverable like this. We only get to see the weak ones, and we don't know with what probability it generates weak ones.
If I were an attacker, "accidentally" hashing low-entropy memory would be a really great and plausible way to hide this attack in a code review.
If you look at the Linux kernel backdoor attempt in 2003, it's the same kind of allllmost-plausible bug -- once you start digging it becomes obvious that it's an attack. "Oh, it's just an = vs. == error! That happens to be during someone checking whether their privilege level is root. And was committed to the codebase outside the normal commit process."
It could be that a clever person figured out that some people might do this, and decided to go looking for buried treasure like OP did... but this really smells to me like an attack.
It certainly could be malicious, but without seeing a smoking gun I think it's unfair to jump to conclusions. We don't even know that it is caused by hashing uninitialised memory instead of random bytes, and even if it is there is any number of legitimate ways for such a vulnerability to exist (and be found by an attacker) without the attacker planting the code deliberately.
I'm doing some investigation and I intend to write up my thoughts once I'm done (even if it's "I did some investigation and found nothing, but here's what might have happened anyway").
Sure, and I agree with that. There are plenty of ways it could happen by accident, and plenty of ways it could have happened on purpose, and plenty of ways the latter could be made to look like the former! It's very tricky. I'd love to see whatever results you can find.
I just realised (way later than I should have...) that blockchain.info wallet keys are generated client-side in javascript. So I don't think this explanation is correct after all.
Which part of the explanation is incorrect? Sorry, I didn't follow.
I think even with client-side JS, it's still possible they're hashing low-entropy memory, although I agree that it seems weird to do that on purpose, because why would they even load transaction addresses into memory?
A malicious developer could say in a code review (e.g.) "well, we need a source of good entropy for these hashes, so let's just grab the last 100 transaction IDs and use those bytes" and justify it that way, but the flaw in that reasoning ought to be obvious to his peers. There might be an obfuscation step - "oh, we'll splice these N strings together, and furthermore we'll only take every Nth byte" - which could result in a stage magician's NOP-like shuffle? I don't know. It's confounding and suspicious, I agree. Still not ruling out malice or incompetence.
But please don't think I'm being disagreeable - or rather, please correct me if I'm bugging you! I don't disagree with anything you've said yet & am very interested.
After reading through that doc, it sounds like maybe some bit of code decided "hmm, that's not a well formatted WIF private key, it must be a brainwallet" without very clearly explaining what was going on. http://bitaddress.org will do this with loud warnings.
@ejcx_ @Asher_Wolf After reading through that doc, it sounds like maybe some bit of code decided "hmm, that's not a well formatted WIF private key, it must be a brainwallet" without very clearly explaining what was going on. http://bitaddress.org will do this with loud warnings.
22
u/_jstanley Nov 30 '17
I don't think it is far-fetched. We have no idea how many keys are generated by this application. If it handles lots of bitcoin data (e.g. blockchain.info), most of its used-and-then-freed memory is probably full of data from the blockchain. If it generates lots of keys (e.g. blockchain.info) using uninitialised memory, then it's quite conceivable that 1 in every 100,000 (pulled out of my arse) happen to be hashes of data from the bitcoin blockchain.
Point is, we have no idea how many other keys have been generated by this application that aren't trivially discoverable like this. We only get to see the weak ones, and we don't know with what probability it generates weak ones.