7 ms·

Milk Sad Disclosure

136 points by dgrove 3y ago

hashmush 3y ago
Seems a bit overkill with a brand + domain name for every new vulnerability. Don't get me wrong, it's a nice find and all, but I'm really distracted by all the fluff.
- tptacek 3y ago
  That's on you, though. The name doesn't cost anything, but it does make the vulnerability easier to talk about.
  - thomastjeffery 3y ago
    I suspect the domain literally cost money...
    - lrvick 3y ago
      It cost me $4 to help get the word out on a bug that is being actively exploited right now, stealing valuable property. I am good with that.
      - lalopalota 3y ago
        Where do you buy a $4 domain?
        jnaulty 3y ago
        based on the `whois milksad.info` Domain registrar is Namecheap :shrug:
        topato 3y ago
        Porkbun? I buy under a dollar domains from them frequently
- NelsonMinar 3y ago
  Eh, let the security consultants have their moment. Also it's a great name. "Running bx seed on 3.x versions with a system time of 0.0 always generates the following secret: milk sad wage cup reward..."
  - ryanatdistrust 3y ago
    we had so much fun trying to figure out the icon!
  - bombcar 3y ago
    Milk sad is ok. “Wage cup reward” is almost poetry …
gjhhg-Afff 3y ago
[flagged]
yieldcrv 3y ago
Are any of the following two things true: Multi signature addresses mitigate this attack vector? With the “taproot+schnoor” upgrade last year, it is impossible to tell if funds are stored in a single signature vs multi signature address?
- lrvick 3y ago
  If all the keys were generated with bad entropy, more of them is only buying you some obfuscation.
  - yieldcrv 3y ago
    Generate keys with different apps or methods, for more peace of mind That was one of the goals of initial multisignature technology in bitcoin, it was about if one of your devices got compromised you could have 2 factor and not approve the transaction. People werent thinking about if your private key generation was compromised, but it works here too
- chx 3y ago
  [flagged]
  - yieldcrv 3y ago
    One perspective is that it mimics society more evenly: if you’re one step ahead you also get to steal everyone else’s. Being a perpetual bug bounty is utility. A more collaborative perspective is that the adaptable nature of the protocol adds to the confidence in it. Only new addresses created after an update of one program were affected. And now it is fixed already. Bitcoin use has pointed out flaws in other encryption methods before which quickly got fixed solely because there was a financial motive to fix it suddenly. The primary thing that you missed is that the upgrade last year was not “snakeoil to mitigate this problem”, its just also an additional way to mitigate this potential problem, its just happens to also provide an improvement on 10 year old multisignature technology But an overlapping analogy to your primary observation would be how insecure accepting credits over the internet was in 1995. That problem actually never went away, despite layers and layers of patches and payment processors and security standards, SSL, TLS, PCI Compliance v1 v2.. venture backed competitor payment processors with fraud detection and yet nobody threw their hands up and said “we’re going to stop trying now”
NelsonMinar 3y ago
"On Libbitcoin Explorer 3.x versions, bx seed uses the Mersenne Twister pseudorandom number generator (PRNG) initialized with 32 bits of system time." That's a hell of an amateur mistake to make. 50/50 odds whether it was incompetence or deliberate fraud. Maybe 80/20; that flaw is so simple anyone can attack it. Which apparently is happening right now. It's much better if your crypto library generates keys only you can hack.
- yieldcrv 3y ago
  if it’s something only you can attack then there is no plausible deniability if you become accused as the code contributor
  - ryanatdistrust 3y ago
    To verify, this is something anyone can attack, as was proven by our brute force lookup service: https://lookup.milksad.info https://lookup.milksad.info.
- comboy 3y ago
  Why is it a mistake?
  - wmf 3y ago
    As the article explains, 32 bits of entropy isn't enough for any cryptographic secret because it can be easily brute-forced.
    - NelsonMinar 3y ago
      Also if it's really the date it's nowhere near 32 bits of entropy. I'm guessing you can pretty easily guess to the day when a Bitcoin wallet was created, so that's about 16 bits of entropy. Less if you know the time, possibly 0.
      - ryanatdistrust 3y ago
kmeisthax 3y ago
Reminds me of attacks people were running on 'brainwallets' a while back - i.e. wallets whose initial key material was just a passphrase you'd remember. The idea was that you could keep the passphrase stored nowhere and not have to worry about it being stolen by... well, any of the 10,000 things out there looking for cryptocurrency keys. Of course, there is no way in hell you can actually make the human brain store enough entropy perfectly, and once people realized that these wallets were crackable, they all got drained pretty quick. Owning Bitcoin is like paying into an involuntary bug bounty program. Every time someone finds a bug, your life savings get wiped out.
- TravelTechGuy 3y ago
  Your last sentence should be a t-shirt.
- ajross 3y ago
  > Of course, there is no way in hell you can actually make the human brain store enough entropy perfectly Sure there is. Have horse batteries taught us nothing? https://xkcd.com/936/ https://xkcd.com/936/ Don't confuse key length with entropy. A properly-scaled PBKDF remains secure with as little as 48 bits or so. Needless to say, though, a 32 bit time value is hardly a properly designed key derivation input.
  - codetrotter 3y ago
    This xkcd comic has been instrumental to me. I wrote a command-line utility a couple of years ago that I use myself regularly to generate secure and memorable passwords https://github.com/ctsrc/Pgen https://github.com/ctsrc/Pgen With this tool you can also see how many bits of entropy the passphrase generation settings you are using will result in. For example, generating a 5 word passphrase using the long wordlist pgen -l -n 5 will yield a passphrase like: joyous embolism outsider evasion mashed And when we ask the tool for the entropy with these settings pgen -l -n 5 -e it will tell us: Current settings will create passphrases with 64.62 bits of entropy. And hey, if you have reason to not trust the randomness capabilities of the program or your computer guess what :) My program supports the use of physical dice to generate your password. Have a look, try it out yourselves :D https://github.com/ctsrc/Pgen https://github.com/ctsrc/Pgen
lostmsu 3y ago
Note: "Libbitcoin" here is a company name, and not a name of the core bitcoin library. Only their products and whoever used them as a 3rd party is affected.
- Modified3019 3y ago
  Exactly what I came here to find out, thank you.
- drexlspivey 3y ago
  Here's a thread on how bitcoin core generates entropy https://twitter.com/raw_avocado/status/1445024873382809604 https://twitter.com/raw_avocado/status/1445024873382809604
  - nullc 3y ago
    that thread is a little confused: Particularly, 'The Dynamic and Static events are mixed in(mostly) by using "<<" Left Shift Bits. Because it's a binary operation, every digit is a power of 2, so shifting the bit n positions ends up multiplying by 2^n. This adds further confusion when multiple numbers are used at once.' --- the tweet appears to be confusing C++ stream usage of "<<" with shifting (and as a result makes it sound like the code is doing something idiotic). Here is how it works: Lots of potential entropy sources including the essential good ones (as well as junk ones like timestamps and user/host info) are fed into a cryptographic hash then strengthened with iterated hashing. The junk sources are included as a hail mary so the user might have some chance to move their funds if they learn about vulnerabilities in their OS/hardware RNGs before an attacker can brute force out the weak sources.
    - alexwaltz 3y ago
      OMG, i'm a bit star struck seeing you reply to this. Been reading you posts on btctalk for years :D Sorry about that, my bad, I though i understand how that works, when I was exploring this topic i literally asked everyone i know and no one seemed to have any idea, and then when i felt i got a conclusion i was happy i found some explanation. Anyway that just an excuse at the end of the day. I have added to the thread a screenshoot of your reply and link to this conversation. https://twitter.com/raw_avocado/status/1689317198626422784 https://twitter.com/raw_avocado/status/1689317198626422784 Thanks for clarifying that.
ryan-c 3y ago
I wonder whether they modified brainflayer for brute forcing this, or if they wrote something from scratch.
- ryanatdistrust 3y ago
  We used the broken algorithm from `bx` in a custom Rust program to brute force this.
  - ryan-c 3y ago
    What sort of rate did you get for computing the hashed public keys?
    - ryanatdistrust 3y ago
      I was not involved in that specific aspect, so I can't provide accurate information. We may release more information later in the future.
      - ryan-c 3y ago
        2^32 search space for each set? That seems to imply a little under 2,000 keys per second?
        ryanatdistrust 3y ago
        My numbers are very rough estimates and not good enough to do work on. More accurate information may be made public later.
        ryan-c 3y ago
        I would be interested to see performance stats - I would expect an optimized attack (batch point inversion, large precomputed table to speed up multiplication, not bothering to try to be constant time) to run well over an order of magnitude faster than that. Not that it's particularly worth bothering if you have an 80 core machine and only 13 billion keys to check.
RustyRussell 3y ago
Worth noting: libbitcoin is an obscure project with an impressive name. In that it's not used by bitcoind or any wallets I know of: it's mainly of interest here because the book Mastering Bitcoin used it for examples.
- lrvick 3y ago
  It is also of interest because at least ~$1m of funds were stolen from thousands of wallets made by people that wanted a simple and seemingly reputable CLI tool to generate a mnemonic and derive addresses for various coins.
  - RustyRussell 3y ago
    Sigh. I did not know that, thanks :(
  - Zenul_Abidin 3y ago
    Now I'm busy making my own CLI for that, after this mess.
- nullc 3y ago
  It's far from the first time that people have sought to make themselves extra secure and as a result found themselves using obscure software which was inadequately reviewed and flawed or even outright backdoored and as a result received almost no security at all.
- yieldcrv 3y ago
  there are a couple crypto programming youtube videos like that, remix IDE put up a warning at one point its an interesting attack vector provide educational resources with compromised examples wait for dev or their users to deposit funds in the copy and pasted contract or dependency long game, been wondering how well that worked
tedunangst 3y ago
Weird. I've been assured, repeatedly, that time seeded PRNGs are never used for crypto and it's not an issue worth addressing.
- ryanatdistrust 3y ago
  As long as people can write code, bugs will exist.
- sowbug 3y ago
  There is no single codebase for "crypto," so that would be an extraordinary assurance for someone to make. Even Bitcoin has many different compatible implementations of varying quality.
TacticalCoder 3y ago
> https://blog.ledger.com/Funds-of-every-wallet-created-with-the-Trust-Wallet-browser-extension-could-have-been-stolen/ https://blog.ledger.com/Funds-of-every-wallet-created-with-t... This "Milk Sad" was apparently discovered by the guys at Ledger (they make a hardware wallet but which can also be used as a U2F device for, say, SSH logins). These guys are good. Their CTO (or ex-CTO ?) was part of the original FIDO alliance that came up with the U2F spec.
- lrvick 3y ago
  We found the flaw in bx before ever knowing the Trustwallet flaw existed. We are not the Ledger team but their writeup on their very similar finding was fantastic so we reference it prominently.
comex 3y ago
The spiciest bit: > During our accelerated coordinated disclosure to the Libbitcoin team, the Libbitcoin team quickly disputed the relevancy of our findings and the CVE assignment. By our understanding, they consider bx seed a command that should never be used productively by any bx user since it is sufficiently documented as unsuited for safe wallet generation. > We do not agree with this assessment. https://milksad.info/disclosure.html#libbitcoin-vendor-response https://milksad.info/disclosure.html#libbitcoin-vendor-respo...
- lclc 3y ago
  Look at the big warning there: https://github.com/libbitcoin/libbitcoin-explorer/wiki/bx-seed https://github.com/libbitcoin/libbitcoin-explorer/wiki/bx-se... He's right.
  - lrvick 3y ago
    I would call your attention to the several places it was demonstrated for use by libbitcoin team members -without- a warning, such as in their contributed examples in Mastering Bitcoin. We cover a few of such examples in the writeup. Also note that the tool bothers to refuse to use a flag to specify 32 bit seeds, due to their known risks, but then proceeds to give you only 32 bits of entropy anyway even if you ask for 256.
  - yodelshady 3y ago
    No, he's not. Why have it? This isn't a general purpose programming language, a pile of ore from which you might conceivably construct a footgun. It's a toolkit specifically designed for financial applications with a "leak your financial details" tool built in. Sure, it's AGPL, they're not literally liable, but it's not great.
nullc 3y ago
Some extra relevant links: https://github.com/libbitcoin/libbitcoin-system/pull/559 https://github.com/libbitcoin/libbitcoin-system/pull/559 The pull request adding the vulnerability, the lack of review or collaboration is worth noticing. The prior code was already dubious in that AFAIK std::random_device library doesn't promise that the randomness is suitable for cryptography. I believe on common systems where this code was run the old code was not likely to be exploitable, but I wouldn't bet my money on it. https://twitter.com/evoskuil/status/1688657656620167169 https://twitter.com/evoskuil/status/1688657656620167169 Developer commentary on this issue. I can't figure out what "long-documented intended usage" a seed command that mandates 128-bits of output but never has more than 32-bits of entropy would have. https://archive.is/A7Jn6 https://archive.is/A7Jn6 The documentation the tweet references. I don't know how the 'Pseudorandom seeding' warning there would be distinguishable from warnings against CSPRNGs in favor of dice rolls or whatever, perhaps this is an example of the harm that chicken-little crying about CSPRNGS causes. Nor can I figure out for whose convenience this function would serve except attackers. In any case, this is the only place I found any kind of warning and the warning postdates the mastering bitcoin usage (as well as the change that made the command unconditionally unsafe). https://archive.is/HDe8h https://archive.is/HDe8h Current libbitcoin-explorer instructions telling users to use the seed command to generate private keys. https://archive.is/fhm5J#selection-12915.2-12915.10 https://archive.is/fhm5J#selection-12915.2-12915.10 Current libbitcoin-explorer instructions telling users to use the seed command to generate BIP39 seeds (also private keys). https://archive.is/PWLKJ https://archive.is/PWLKJ Current libbitcoin-explorer documentation on randomness noting that bx seed is the ONLY source of randomness available to users in the package, and that all other commands that need randomness require the user to provide it. It also notes that 'bx seed' will not function if less than 128-bits are requested. The private key and bip39 seed usage (above) sure appears to be the "intended usage" in their documentation, but the "bx seed" function as currently implemented (since 2016) is unambiguously not fit for those purpose.
- midmagico 3y ago
  > Current libbitcoin-explorer instructions telling users to use the seed command to generate private keys. .. and receive bitcoin at them. Wow brutal.
- 3y ago
mkj 3y ago
Was the code seeding by seconds since epoch, or nanoseconds since epoch truncated to 32 bits? Broken either way. https://github.com/libbitcoin/libbitcoin-system/blob/a1b777fc51d9c04e0c7a1dec5cc746b82a6afe64/src/crypto/pseudo_random.cpp#L70 https://github.com/libbitcoin/libbitcoin-system/blob/a1b777f... const auto now = high_resolution_clock::now(); return static_cast<uint32_t>(now.time_since_epoch().count());
- ryanatdistrust 3y ago
  Nanoseconds since epoch, which means eventually it does loop around, so at the very least it's not possible to generate a specific wallet by knowing when it was first used.
  - infofarmer 3y ago
    A quick search says it's actually ticks, which is OS and machine dependent (kernel tunable). Nanosecond resolution is not enough for a seed if it's a real datetime, so the 32-bit truncation is a separate problem.
efficax 3y ago
lol just straight up not using a cryptographically secure source of randomness. that's literally the first thing you do when you want secure cryptography. idiots

136 points by dgrove 3y ago

Seems a bit overkill with a brand + domain name for every new vulnerability. Don't get me wrong, it's a nice find and all, but I'm really distracted by all the fluff.

tptacek 3y ago
That's on you, though. The name doesn't cost anything, but it does make the vulnerability easier to talk about.
- thomastjeffery 3y ago
  I suspect the domain literally cost money...
  - lrvick 3y ago
    It cost me $4 to help get the word out on a bug that is being actively exploited right now, stealing valuable property. I am good with that.
    - lalopalota 3y ago
      Where do you buy a $4 domain?
      - jnaulty 3y ago
        based on the `whois milksad.info` Domain registrar is Namecheap :shrug:
      - topato 3y ago
        Porkbun? I buy under a dollar domains from them frequently
NelsonMinar 3y ago
Eh, let the security consultants have their moment. Also it's a great name. "Running bx seed on 3.x versions with a system time of 0.0 always generates the following secret: milk sad wage cup reward..."
- ryanatdistrust 3y ago
  we had so much fun trying to figure out the icon!
- bombcar 3y ago
  Milk sad is ok. “Wage cup reward” is almost poetry …

gjhhg-Afff 3y ago

[flagged]

yieldcrv 3y ago

Are any of the following two things true: Multi signature addresses mitigate this attack vector? With the “taproot+schnoor” upgrade last year, it is impossible to tell if funds are stored in a single signature vs multi signature address?

lrvick 3y ago
If all the keys were generated with bad entropy, more of them is only buying you some obfuscation.
- yieldcrv 3y ago
  Generate keys with different apps or methods, for more peace of mind That was one of the goals of initial multisignature technology in bitcoin, it was about if one of your devices got compromised you could have 2 factor and not approve the transaction. People werent thinking about if your private key generation was compromised, but it works here too
chx 3y ago
[flagged]
- yieldcrv 3y ago
  One perspective is that it mimics society more evenly: if you’re one step ahead you also get to steal everyone else’s. Being a perpetual bug bounty is utility. A more collaborative perspective is that the adaptable nature of the protocol adds to the confidence in it. Only new addresses created after an update of one program were affected. And now it is fixed already. Bitcoin use has pointed out flaws in other encryption methods before which quickly got fixed solely because there was a financial motive to fix it suddenly. The primary thing that you missed is that the upgrade last year was not “snakeoil to mitigate this problem”, its just also an additional way to mitigate this potential problem, its just happens to also provide an improvement on 10 year old multisignature technology But an overlapping analogy to your primary observation would be how insecure accepting credits over the internet was in 1995. That problem actually never went away, despite layers and layers of patches and payment processors and security standards, SSL, TLS, PCI Compliance v1 v2.. venture backed competitor payment processors with fraud detection and yet nobody threw their hands up and said “we’re going to stop trying now”

NelsonMinar 3y ago

"On Libbitcoin Explorer 3.x versions, bx seed uses the Mersenne Twister pseudorandom number generator (PRNG) initialized with 32 bits of system time." That's a hell of an amateur mistake to make. 50/50 odds whether it was incompetence or deliberate fraud. Maybe 80/20; that flaw is so simple anyone can attack it. Which apparently is happening right now. It's much better if your crypto library generates keys only you can hack.

yieldcrv 3y ago
if it’s something only you can attack then there is no plausible deniability if you become accused as the code contributor
- ryanatdistrust 3y ago
  To verify, this is something anyone can attack, as was proven by our brute force lookup service: https://lookup.milksad.info https://lookup.milksad.info.
comboy 3y ago
Why is it a mistake?
- wmf 3y ago
  As the article explains, 32 bits of entropy isn't enough for any cryptographic secret because it can be easily brute-forced.
  - NelsonMinar 3y ago
    Also if it's really the date it's nowhere near 32 bits of entropy. I'm guessing you can pretty easily guess to the day when a Bitcoin wallet was created, so that's about 16 bits of entropy. Less if you know the time, possibly 0.
    - ryanatdistrust 3y ago

kmeisthax 3y ago

Reminds me of attacks people were running on 'brainwallets' a while back - i.e. wallets whose initial key material was just a passphrase you'd remember. The idea was that you could keep the passphrase stored nowhere and not have to worry about it being stolen by... well, any of the 10,000 things out there looking for cryptocurrency keys. Of course, there is no way in hell you can actually make the human brain store enough entropy perfectly, and once people realized that these wallets were crackable, they all got drained pretty quick. Owning Bitcoin is like paying into an involuntary bug bounty program. Every time someone finds a bug, your life savings get wiped out.

TravelTechGuy 3y ago
Your last sentence should be a t-shirt.
ajross 3y ago
> Of course, there is no way in hell you can actually make the human brain store enough entropy perfectly Sure there is. Have horse batteries taught us nothing? https://xkcd.com/936/ https://xkcd.com/936/ Don't confuse key length with entropy. A properly-scaled PBKDF remains secure with as little as 48 bits or so. Needless to say, though, a 32 bit time value is hardly a properly designed key derivation input.
- codetrotter 3y ago
  This xkcd comic has been instrumental to me. I wrote a command-line utility a couple of years ago that I use myself regularly to generate secure and memorable passwords https://github.com/ctsrc/Pgen https://github.com/ctsrc/Pgen With this tool you can also see how many bits of entropy the passphrase generation settings you are using will result in. For example, generating a 5 word passphrase using the long wordlist pgen -l -n 5 will yield a passphrase like: joyous embolism outsider evasion mashed And when we ask the tool for the entropy with these settings pgen -l -n 5 -e it will tell us: Current settings will create passphrases with 64.62 bits of entropy. And hey, if you have reason to not trust the randomness capabilities of the program or your computer guess what :) My program supports the use of physical dice to generate your password. Have a look, try it out yourselves :D https://github.com/ctsrc/Pgen https://github.com/ctsrc/Pgen

lostmsu 3y ago

Note: "Libbitcoin" here is a company name, and not a name of the core bitcoin library. Only their products and whoever used them as a 3rd party is affected.

Modified3019 3y ago
Exactly what I came here to find out, thank you.
drexlspivey 3y ago
Here's a thread on how bitcoin core generates entropy https://twitter.com/raw_avocado/status/1445024873382809604 https://twitter.com/raw_avocado/status/1445024873382809604
- nullc 3y ago
  that thread is a little confused: Particularly, 'The Dynamic and Static events are mixed in(mostly) by using "<<" Left Shift Bits. Because it's a binary operation, every digit is a power of 2, so shifting the bit n positions ends up multiplying by 2^n. This adds further confusion when multiple numbers are used at once.' --- the tweet appears to be confusing C++ stream usage of "<<" with shifting (and as a result makes it sound like the code is doing something idiotic). Here is how it works: Lots of potential entropy sources including the essential good ones (as well as junk ones like timestamps and user/host info) are fed into a cryptographic hash then strengthened with iterated hashing. The junk sources are included as a hail mary so the user might have some chance to move their funds if they learn about vulnerabilities in their OS/hardware RNGs before an attacker can brute force out the weak sources.
  - alexwaltz 3y ago
    OMG, i'm a bit star struck seeing you reply to this. Been reading you posts on btctalk for years :D Sorry about that, my bad, I though i understand how that works, when I was exploring this topic i literally asked everyone i know and no one seemed to have any idea, and then when i felt i got a conclusion i was happy i found some explanation. Anyway that just an excuse at the end of the day. I have added to the thread a screenshoot of your reply and link to this conversation. https://twitter.com/raw_avocado/status/1689317198626422784 https://twitter.com/raw_avocado/status/1689317198626422784 Thanks for clarifying that.

ryan-c 3y ago

I wonder whether they modified brainflayer for brute forcing this, or if they wrote something from scratch.

ryanatdistrust 3y ago
We used the broken algorithm from `bx` in a custom Rust program to brute force this.
- ryan-c 3y ago
  What sort of rate did you get for computing the hashed public keys?
  - ryanatdistrust 3y ago
    I was not involved in that specific aspect, so I can't provide accurate information. We may release more information later in the future.
    - ryan-c 3y ago
      2^32 search space for each set? That seems to imply a little under 2,000 keys per second?
      - ryanatdistrust 3y ago
        My numbers are very rough estimates and not good enough to do work on. More accurate information may be made public later.
        ryan-c 3y ago
        I would be interested to see performance stats - I would expect an optimized attack (batch point inversion, large precomputed table to speed up multiplication, not bothering to try to be constant time) to run well over an order of magnitude faster than that. Not that it's particularly worth bothering if you have an 80 core machine and only 13 billion keys to check.

RustyRussell 3y ago

Worth noting: libbitcoin is an obscure project with an impressive name. In that it's not used by bitcoind or any wallets I know of: it's mainly of interest here because the book Mastering Bitcoin used it for examples.

lrvick 3y ago
It is also of interest because at least ~$1m of funds were stolen from thousands of wallets made by people that wanted a simple and seemingly reputable CLI tool to generate a mnemonic and derive addresses for various coins.
- RustyRussell 3y ago
  Sigh. I did not know that, thanks :(
- Zenul_Abidin 3y ago
  Now I'm busy making my own CLI for that, after this mess.
nullc 3y ago
It's far from the first time that people have sought to make themselves extra secure and as a result found themselves using obscure software which was inadequately reviewed and flawed or even outright backdoored and as a result received almost no security at all.
yieldcrv 3y ago
there are a couple crypto programming youtube videos like that, remix IDE put up a warning at one point its an interesting attack vector provide educational resources with compromised examples wait for dev or their users to deposit funds in the copy and pasted contract or dependency long game, been wondering how well that worked

tedunangst 3y ago

Weird. I've been assured, repeatedly, that time seeded PRNGs are never used for crypto and it's not an issue worth addressing.

ryanatdistrust 3y ago
As long as people can write code, bugs will exist.
sowbug 3y ago
There is no single codebase for "crypto," so that would be an extraordinary assurance for someone to make. Even Bitcoin has many different compatible implementations of varying quality.

TacticalCoder 3y ago

> https://blog.ledger.com/Funds-of-every-wallet-created-with-the-Trust-Wallet-browser-extension-could-have-been-stolen/ https://blog.ledger.com/Funds-of-every-wallet-created-with-t... This "Milk Sad" was apparently discovered by the guys at Ledger (they make a hardware wallet but which can also be used as a U2F device for, say, SSH logins). These guys are good. Their CTO (or ex-CTO ?) was part of the original FIDO alliance that came up with the U2F spec.

lrvick 3y ago
We found the flaw in bx before ever knowing the Trustwallet flaw existed. We are not the Ledger team but their writeup on their very similar finding was fantastic so we reference it prominently.

comex 3y ago

The spiciest bit: > During our accelerated coordinated disclosure to the Libbitcoin team, the Libbitcoin team quickly disputed the relevancy of our findings and the CVE assignment. By our understanding, they consider bx seed a command that should never be used productively by any bx user since it is sufficiently documented as unsuited for safe wallet generation. > We do not agree with this assessment. https://milksad.info/disclosure.html#libbitcoin-vendor-response https://milksad.info/disclosure.html#libbitcoin-vendor-respo...

lclc 3y ago
Look at the big warning there: https://github.com/libbitcoin/libbitcoin-explorer/wiki/bx-seed https://github.com/libbitcoin/libbitcoin-explorer/wiki/bx-se... He's right.
- lrvick 3y ago
  I would call your attention to the several places it was demonstrated for use by libbitcoin team members -without- a warning, such as in their contributed examples in Mastering Bitcoin. We cover a few of such examples in the writeup. Also note that the tool bothers to refuse to use a flag to specify 32 bit seeds, due to their known risks, but then proceeds to give you only 32 bits of entropy anyway even if you ask for 256.
- yodelshady 3y ago
  No, he's not. Why have it? This isn't a general purpose programming language, a pile of ore from which you might conceivably construct a footgun. It's a toolkit specifically designed for financial applications with a "leak your financial details" tool built in. Sure, it's AGPL, they're not literally liable, but it's not great.

nullc 3y ago

Some extra relevant links: https://github.com/libbitcoin/libbitcoin-system/pull/559 https://github.com/libbitcoin/libbitcoin-system/pull/559 The pull request adding the vulnerability, the lack of review or collaboration is worth noticing. The prior code was already dubious in that AFAIK std::random_device library doesn't promise that the randomness is suitable for cryptography. I believe on common systems where this code was run the old code was not likely to be exploitable, but I wouldn't bet my money on it. https://twitter.com/evoskuil/status/1688657656620167169 https://twitter.com/evoskuil/status/1688657656620167169 Developer commentary on this issue. I can't figure out what "long-documented intended usage" a seed command that mandates 128-bits of output but never has more than 32-bits of entropy would have. https://archive.is/A7Jn6 https://archive.is/A7Jn6 The documentation the tweet references. I don't know how the 'Pseudorandom seeding' warning there would be distinguishable from warnings against CSPRNGs in favor of dice rolls or whatever, perhaps this is an example of the harm that chicken-little crying about CSPRNGS causes. Nor can I figure out for whose convenience this function would serve except attackers. In any case, this is the only place I found any kind of warning and the warning postdates the mastering bitcoin usage (as well as the change that made the command unconditionally unsafe). https://archive.is/HDe8h https://archive.is/HDe8h Current libbitcoin-explorer instructions telling users to use the seed command to generate private keys. https://archive.is/fhm5J#selection-12915.2-12915.10 https://archive.is/fhm5J#selection-12915.2-12915.10 Current libbitcoin-explorer instructions telling users to use the seed command to generate BIP39 seeds (also private keys). https://archive.is/PWLKJ https://archive.is/PWLKJ Current libbitcoin-explorer documentation on randomness noting that bx seed is the ONLY source of randomness available to users in the package, and that all other commands that need randomness require the user to provide it. It also notes that 'bx seed' will not function if less than 128-bits are requested. The private key and bip39 seed usage (above) sure appears to be the "intended usage" in their documentation, but the "bx seed" function as currently implemented (since 2016) is unambiguously not fit for those purpose.

midmagico 3y ago
> Current libbitcoin-explorer instructions telling users to use the seed command to generate private keys. .. and receive bitcoin at them. Wow brutal.
3y ago

mkj 3y ago

Was the code seeding by seconds since epoch, or nanoseconds since epoch truncated to 32 bits? Broken either way. https://github.com/libbitcoin/libbitcoin-system/blob/a1b777fc51d9c04e0c7a1dec5cc746b82a6afe64/src/crypto/pseudo_random.cpp#L70 https://github.com/libbitcoin/libbitcoin-system/blob/a1b777f... const auto now = high_resolution_clock::now(); return static_cast<uint32_t>(now.time_since_epoch().count());

ryanatdistrust 3y ago
Nanoseconds since epoch, which means eventually it does loop around, so at the very least it's not possible to generate a specific wallet by knowing when it was first used.
- infofarmer 3y ago
  A quick search says it's actually ticks, which is OS and machine dependent (kernel tunable). Nanosecond resolution is not enough for a seed if it's a real datetime, so the 32-bit truncation is a separate problem.

efficax 3y ago

lol just straight up not using a cryptographically secure source of randomness. that's literally the first thing you do when you want secure cryptography. idiots