10 ms·

How I tripped over the Debian weak keys vulnerability

339 points by ecliptik 3y ago

ArtTimeInvestor 3y ago
Reading this makes me wonder how probable/improbable it is that this kind of thing has happened / will happen with the seed generation function in one of the popular Bitcoin hardware wallets. And what the fallout would be.
- trashburger 3y ago
  Feels like that would be noticed rather quickly given that you would be able to access someone else's funds on the network automatically, whereas in the SSH vulnerability case you have to proactively check if servers you want to access have one of the bad fingerprints.
- xiphias2 3y ago
  https://news.ycombinator.com/item?id=6195493 https://news.ycombinator.com/item?id=6195493
  - baobun 3y ago
    also https://blog.1inch.io/a-vulnerability-disclosed-in-profanity-an-ethereum-vanity-address-tool/ https://blog.1inch.io/a-vulnerability-disclosed-in-profanity...
  - ArtTimeInvestor 3y ago
    In 2013, Bitcoin's market cap was less than a Billion, I think. And those Android wallets probably only held small amounts. But now that pension funds get into Bitcoin, one has to wonder what would happen if a giant like Coinbase turns out to be holding their funds in cold storage but with guessable keys.
    - 3abiton 3y ago
      It's crazy to to from a hobbyist niche commodity to a nearly gold reserve alternative.
    - xiphias2 3y ago
      Even if those ,,small amounts'' were 5% of net worth of some people (which was not uncommon), the same small amount would consist of more than 99% of the net worth of the same people currently. As Android wallets were the easiest to use wallets and exchanges routinely robbed people, it mattered a lot even back then. While Coinbase has a quite good protocol for securing keys, what's scary to me is that so many ETFs are trusting it to be the only key holder instead of using multi-signature wallets between multiple entities (like Fidelity and Unchained capital as the other 2).
      - ArtTimeInvestor 3y ago
        Is it documented, how the individual ETFs are holding their assets? I know they state that they do it via a custodian and name it like "Coinbase", but is that really all? All they got is an IOU from Coinbase? Maybe they have more specific setups?
  - pcthrowaway 3y ago
    Interesting to see Vitalik pop up in that thread
- pants2 3y ago
  The $160M Wintermute hack was a result of insecure key generation in a public library, though it's unlikely that one was introduced intentionally.
- macrolime 3y ago
  https://www.unciphered.com/blog/randstorm-you-cant-patch-a-house-of-cards https://www.unciphered.com/blog/randstorm-you-cant-patch-a-h... Over the last 22 months, Unciphered has been working on a vulnerability which affected BitcoinJS, a popular package for the browser based generation of cryptocurrency wallets, as well as products and projects built from this software. Over a period of years, this vulnerability caused the generation of a significant number of vulnerable cryptocurrency wallets.
- withinboredom 3y ago
  Considering that each key can be generated deterministically from a seed key and the seed keys are not infinite… it’s only a matter of time (millions of years compute time with current technology, and not out of reach for state actors who can spend infinite money to run that much compute in a matter of weeks) until every wallet is accessible by anyone who knows the address. Bitcoin isn’t that safe to hold value in, if you might be targeted by someone with brains and money.
  - posnet 3y ago
    Just for fun, because it's hard to appreciate how strong a 256bit ECDSA key is. Base Numbers: - 2*128 guesses on average - public state of the art for ECDSA on an FPGA is 1315tps [0] - retail price of said fpga $10,000 [1] - total net income for xilinx from advanced FPGAs FY2022 (936M * 0.74 + 879M * 0.72) = 1325M [2] Ballpark numbers, we'll assume that attacker can buy 10x every FPGA xilinx made in 2022 for a 50% discount and can run them non stop for zero cost. We'll also assume they have a bunch of secret math geniuses and have a faster ECDSA implementation that can do 1,000,000,000 tps ( or 1,000,000x SOTA) - (1325,000,000 / 5,000) * 10 = 2,650,000 FPGAs - 2,650,000 * 100,000,000,000 = 2,650,000,000,000,000tps - 2*128 / 2,650,000,000,000,000 = 1.28e+23s - 1.28e+24 / 60 / 60 / 24 / 365 = 4,080,000,000,000,000 years - ~4 quadrillion years - or 4x the time until every planet has been ejected from every star system and the sun has cooled to 5K [3] But why stop there, lets assume that the attacker can use the entire planets GDP to buy chips and has a 1,000,000,000,000,000x faster ECDSA implementation. - World GDP (2022): 101.3 trillion - (101,300,000,000,000 / 5000) = 20,260,000,000 - 100,000,000,000,000,000 * 20,260,000,000 = 2.66419e+28tps - 2*128 / 2.66419e+28 = 12,772,451,173s - 12,772,451,173 / 60 / 60 / 24 / 365 = 405 years So even then, we wouldn't see a single BTC key broken within our lifetime. (Unless you believe that 3 letter agencies have successfully built a quantum computer that practically implement shore's algorithm, in which case you should probably be more worried about the fact that they can break public key encryption globally) [0]: https://arxiv.org/pdf/2112.02229.pdf https://arxiv.org/pdf/2112.02229.pdf [1]: https://www.colfaxdirect.com/store/pc/viewPrd.asp?idproduct=3664&idcategory=6 https://www.colfaxdirect.com/store/pc/viewPrd.asp?idproduct=... [2]: https://web.archive.org/web/20211203065624/https://investor.xilinx.com/node/18856/pdf https://web.archive.org/web/20211203065624/https://investor.... [3]: https://en.wikipedia.org/wiki/Timeline_of_the_far_future https://en.wikipedia.org/wiki/Timeline_of_the_far_future
cozzyd 3y ago
I wonder if GitHub is still running a patched openssh...
- TheDong 3y ago
  It's pretty easy to check something kinda close to GitHub's source code to see, if you want. Just buy a copy of GitHub Enterprise, deobfuscate the files (it's a fun challenge to deobfuscate them, and not all that hard), and look around to see. It's unfortunately not open source, so we can't share and talk about the code, link to it on GitHub, or anything like that, but if GitHub Enterprise is still using such a patch, it's like the prod github is too.
  - rudasn 3y ago
    How do they distribute github enterprise? Like a VM or image?
    - everfrustrated 3y ago
      Publicly downloadable VM images. Choose openstack for a generic qcow image to run with opensource tools. Docker not supported. https://enterprise.github.com/releases/3.12.1/download https://enterprise.github.com/releases/3.12.1/download
      - rudasn 3y ago
        Nice, thanks!
  - iforgotpassword 3y ago
    Assuming they wrote an entirely new sshd in ruby or something. Otherwise why should they ship the source code to a patched-up opensshd...
    - TheDong 3y ago
      You can see them writing the ssh public keys that are entered into the settings page _somewhere_ in ruby, and you can then kinda guess :)
mkesper 3y ago
I remember looking at SSH public key fingerprints in Savannah at the time and wondering why SO MANY started with AAAA (thought it was some padding first...)
- unhammer 3y ago
  The AAAA (and several of the following characters) is just a header showing what type of key it is: https://crypto.stackexchange.com/questions/5944/why-do-all-ssh-rsa-keys-begin-with-aaaab3nzac1yc https://crypto.stackexchange.com/questions/5944/why-do-all-s...
  - denton-scratch 3y ago
    That's the header on the public key itself; the fingerprint GP referred to doesn't have a "header".
    - tedunangst 3y ago
      The broken keys didn't all have fingerprints of AAAA either.
immibis 3y ago
As I understand it, the OpenSSL RNG was seeded by uninitialised stack memory and the PID. Debian seeded it with just the PID. But wasn't that already quite dangerous even without the Debian patch?
- jwilk 3y ago
  This is incorrect. OpenSSL seeded its RNG also with data read from /dev/urandom.
- tialaramex 3y ago
  Yes, this misunderstanding does seem to be very popular. No, that's what was going on here, the OpenSSL code had two places where it copies of a bunch of bytes, and one of those copies can end up with uninitialized junk, so that's wrong. Somebody wrote a patch which fixes this, and then - even without assistance from an LLM just using normal human incompetence, somebody said "There's another similar copy nearby, we should get rid of that one too" and Debian landed the patch to apply both changes. The result is now OpenSSL doesn't copy any bytes. It doesn't copy the uninitialized data, which is good, and it also doesn't copy the truly random entropy into the pool. Oops.
  - orra 3y ago
    > and one of those copies can end up with uninitialized junk, so that's wrong. To be fair to the Debian patch, reading from uninitialized junk doesn't sprinkle randomness into the desired buffer: it invokes undefined behaviour. The Debian patch was lawful!
    - tedunangst 3y ago
      The part where they also zeroed the buffer with intentionally random data may have been lawful, but it wasn't good.
  - ptx 3y ago
    From Russ Cox's post[0] about this, it sounds like the place in the code that initializes the buffer with actual random data also uses the parts of the buffer that haven't been initialized. So there weren't two separate pieces of code, one copying junk and one copying actual random entropy, but rather "at least three different places" that did both, if I've understood this correctly. [0] https://research.swtch.com/openssl https://research.swtch.com/openssl
matsemann 3y ago
> Ezra Zygmuntowitz pointed GitHub in my direction, and let me take the time to really get into the problem with the GitHub team This sentence is funny to me. Maybe because I'm not a native speaker, but I can't avoid reading it as a big problem with the GH team itself, heh. I was expecting the next sentences to "get into" that. > I wonder if Luciano hadn’t found it, how long it might have been before it was found I think perhaps only GH or one of the big cloud providers would have stumbled upon it, few places I can think of that would have thousands and thousands of keys stored from users.
- alias_neo 3y ago
  > This sentence is funny to me It does / can read both ways, but a comma after "problem" would have removed that doubt.
  - thedanbob 3y ago
    But that wouldn't be correct syntax. That would imply the middle section was an addition to the complete thought of the outer two sections, e.g. > Ezra Zygmuntowitz pointed GitHub in my direction (and let me take the time to really get into the problem) with the GitHub team > Ezra Zygmuntowitz pointed GitHub in my direction (...) with the GitHub team
- arnsholt 3y ago
  In syntactic problem, this is called the PP attachment problem. Basically, should the sentence read (get into the problem) (with the GH team) or (get into (the problem with the GH team)). Turns out to be a very hard thing to do correctly.
  - gosub100 3y ago
    Is that the same thing as being a context sensitive grammar?
ckastner 3y ago
An important fact that I only recently learned about this vulnerability is that the change that introduced it was not some rushed act: the maintainer raised the problem they were seeing on the OpenSSL mailing list, proposed a change to fix the problem with a request for feedback, and got some (including from upstream). The result was a terrible vulnerability, but it seems more of a case of spectacularly bad luck of everyone not spotting the issue.
- yashap 3y ago
  Probably more lacking automated test coverage than bad luck? For security critical RNG code, seems to me you’d really want to have a test where it generates a tonne of random numbers and asserts that they’re all unique.
  - tizvoivo 3y ago
    [dead]
  - bdonlan 3y ago
    In this case, the problem was the seed was low entropy, so if you generated a bunch of random numbers with a single initialization of the RNG seed you would get unique values. It's a tricky scenario to test for if you don't know of the failure mode...
  - gunapologist99 3y ago
    It's not possible to assert that a number is not random (or is). You can look at it and you just don't know. This was the issue with the PRNG blackbox mixing. Obligatory Dilbert https://imgur.com/uR4WuQ0 https://imgur.com/uR4WuQ0 and XKCD: https://xkcd.com/221/ https://xkcd.com/221/
  - brokenmachine 3y ago
    So if you rolled a dice a few times and happened to get the same number, you'd throw the dice away for not working properly?
Sesse__ 3y ago
“While I’ve not found a description of exactly when and how Luciano Bello discovered the vulnerability that became CVE-2008-0166 […]” From my IRC logs at the time: 17:23 < luciano> has really an accident. I was needing many primes numbers... 0:-) 17:23 < Sesse> and you got the same numbers every time? 17:25 < luciano> Sesse, not every time :P
- rmetzler 3y ago
  Luciano in these lines sounds like he just generated lots of keys and then started to wonder why he got more collisions than expected. Thanks for sharing.
- cryptonector 3y ago
  I miss bash.org.
tomlong 3y ago
I realise it is separate to the weak key prime discovery, but it is interesting how much slow SSH login times are a thread that is worth pulling for one reason or another.
nonrandomstring 3y ago
> I feel like we, as an industry, got a bit lucky that someone with the skills, time, and energy was on hand at the right time to make a huge difference. This is where statistics of "many eyes" and "sunlight as disinfectant" hits home. However bizarrely improbable that anyone would just wander along and find a a bug, people do, because they can. With proprietary/closed code, the probability is zero.
- candiddevmike 3y ago
  > With proprietary/closed code, the probability is zero. People discover bugs all the time in closed source software...
  - nonrandomstring 3y ago
    Which people?
    - thfuran 3y ago
      Customers, though they usually aren't finding security vulnerabilities.
      - nonrandomstring 3y ago
        > Customers Ah I see what you mean. Problem of language then. "Finding bugs", to me as a coder, means something different from observing the effects of bugs. Sure, I can see incorrect behaviours in lots of proprietary software. And I can guess what might cause it. But without the source code that's not the same as "finding bugs".
        xyzzy_plugh 3y ago
        "finding a bug" in source code implies there's a mistake there. A bug can be that the implementation doesn't match the spec, or that the spec changed, with respect to the user (customer). Reporting bugs vs finding them is perhaps what you're looking for, but I'd argue finding is overloaded. It's perfectly valid to kick the tires on some software and find some bugs. I've found thousands of bugs in closed source software before, and subsequently reported those bugs.
tzs 3y ago
> After examining a variety of different possible solutions, we came to the conclusion that the least-worst option was to patch OpenSSH to lookup keys in a MySQL database, indexed on the key fingerprint. Why MySQL rather than sqlite? They were trying to speed up access to ~/.ssh/authorized_keys. That's the kind of situation mysql is designed to shine in. I would have expected that patching OpenSSH to check for ~/.ssh/authorized_keys.db would be less work than patching it to use MySQL.
- klysm 3y ago
  I’d imagine there are many machines involved and maintaining one database is typically easier than maintaining many. I’d also imagine MySQL was already in operation, so there wasn’t any startup cost to storing data there. They already had a database of users _somewhere_
epx 3y ago
Another interesting episode was the detection of RSA keys with common 'p' or 'q' factors using GCD: https://factorable.net/weakkeys12.extended.pdf https://factorable.net/weakkeys12.extended.pdf

339 points by ecliptik 3y ago

Reading this makes me wonder how probable/improbable it is that this kind of thing has happened / will happen with the seed generation function in one of the popular Bitcoin hardware wallets. And what the fallout would be.

trashburger 3y ago
Feels like that would be noticed rather quickly given that you would be able to access someone else's funds on the network automatically, whereas in the SSH vulnerability case you have to proactively check if servers you want to access have one of the bad fingerprints.
xiphias2 3y ago
https://news.ycombinator.com/item?id=6195493 https://news.ycombinator.com/item?id=6195493
- baobun 3y ago
  also https://blog.1inch.io/a-vulnerability-disclosed-in-profanity-an-ethereum-vanity-address-tool/ https://blog.1inch.io/a-vulnerability-disclosed-in-profanity...
- ArtTimeInvestor 3y ago
  In 2013, Bitcoin's market cap was less than a Billion, I think. And those Android wallets probably only held small amounts. But now that pension funds get into Bitcoin, one has to wonder what would happen if a giant like Coinbase turns out to be holding their funds in cold storage but with guessable keys.
  - 3abiton 3y ago
    It's crazy to to from a hobbyist niche commodity to a nearly gold reserve alternative.
  - xiphias2 3y ago
    Even if those ,,small amounts'' were 5% of net worth of some people (which was not uncommon), the same small amount would consist of more than 99% of the net worth of the same people currently. As Android wallets were the easiest to use wallets and exchanges routinely robbed people, it mattered a lot even back then. While Coinbase has a quite good protocol for securing keys, what's scary to me is that so many ETFs are trusting it to be the only key holder instead of using multi-signature wallets between multiple entities (like Fidelity and Unchained capital as the other 2).
    - ArtTimeInvestor 3y ago
      Is it documented, how the individual ETFs are holding their assets? I know they state that they do it via a custodian and name it like "Coinbase", but is that really all? All they got is an IOU from Coinbase? Maybe they have more specific setups?
- pcthrowaway 3y ago
  Interesting to see Vitalik pop up in that thread
pants2 3y ago
The $160M Wintermute hack was a result of insecure key generation in a public library, though it's unlikely that one was introduced intentionally.
macrolime 3y ago
https://www.unciphered.com/blog/randstorm-you-cant-patch-a-house-of-cards https://www.unciphered.com/blog/randstorm-you-cant-patch-a-h... Over the last 22 months, Unciphered has been working on a vulnerability which affected BitcoinJS, a popular package for the browser based generation of cryptocurrency wallets, as well as products and projects built from this software. Over a period of years, this vulnerability caused the generation of a significant number of vulnerable cryptocurrency wallets.
withinboredom 3y ago
Considering that each key can be generated deterministically from a seed key and the seed keys are not infinite… it’s only a matter of time (millions of years compute time with current technology, and not out of reach for state actors who can spend infinite money to run that much compute in a matter of weeks) until every wallet is accessible by anyone who knows the address. Bitcoin isn’t that safe to hold value in, if you might be targeted by someone with brains and money.
- posnet 3y ago
  Just for fun, because it's hard to appreciate how strong a 256bit ECDSA key is. Base Numbers: - 2*128 guesses on average - public state of the art for ECDSA on an FPGA is 1315tps [0] - retail price of said fpga $10,000 [1] - total net income for xilinx from advanced FPGAs FY2022 (936M * 0.74 + 879M * 0.72) = 1325M [2] Ballpark numbers, we'll assume that attacker can buy 10x every FPGA xilinx made in 2022 for a 50% discount and can run them non stop for zero cost. We'll also assume they have a bunch of secret math geniuses and have a faster ECDSA implementation that can do 1,000,000,000 tps ( or 1,000,000x SOTA) - (1325,000,000 / 5,000) * 10 = 2,650,000 FPGAs - 2,650,000 * 100,000,000,000 = 2,650,000,000,000,000tps - 2*128 / 2,650,000,000,000,000 = 1.28e+23s - 1.28e+24 / 60 / 60 / 24 / 365 = 4,080,000,000,000,000 years - ~4 quadrillion years - or 4x the time until every planet has been ejected from every star system and the sun has cooled to 5K [3] But why stop there, lets assume that the attacker can use the entire planets GDP to buy chips and has a 1,000,000,000,000,000x faster ECDSA implementation. - World GDP (2022): 101.3 trillion - (101,300,000,000,000 / 5000) = 20,260,000,000 - 100,000,000,000,000,000 * 20,260,000,000 = 2.66419e+28tps - 2*128 / 2.66419e+28 = 12,772,451,173s - 12,772,451,173 / 60 / 60 / 24 / 365 = 405 years So even then, we wouldn't see a single BTC key broken within our lifetime. (Unless you believe that 3 letter agencies have successfully built a quantum computer that practically implement shore's algorithm, in which case you should probably be more worried about the fact that they can break public key encryption globally) [0]: https://arxiv.org/pdf/2112.02229.pdf https://arxiv.org/pdf/2112.02229.pdf [1]: https://www.colfaxdirect.com/store/pc/viewPrd.asp?idproduct=3664&idcategory=6 https://www.colfaxdirect.com/store/pc/viewPrd.asp?idproduct=... [2]: https://web.archive.org/web/20211203065624/https://investor.xilinx.com/node/18856/pdf https://web.archive.org/web/20211203065624/https://investor.... [3]: https://en.wikipedia.org/wiki/Timeline_of_the_far_future https://en.wikipedia.org/wiki/Timeline_of_the_far_future

cozzyd 3y ago

I wonder if GitHub is still running a patched openssh...

TheDong 3y ago
It's pretty easy to check something kinda close to GitHub's source code to see, if you want. Just buy a copy of GitHub Enterprise, deobfuscate the files (it's a fun challenge to deobfuscate them, and not all that hard), and look around to see. It's unfortunately not open source, so we can't share and talk about the code, link to it on GitHub, or anything like that, but if GitHub Enterprise is still using such a patch, it's like the prod github is too.
- rudasn 3y ago
  How do they distribute github enterprise? Like a VM or image?
  - everfrustrated 3y ago
    Publicly downloadable VM images. Choose openstack for a generic qcow image to run with opensource tools. Docker not supported. https://enterprise.github.com/releases/3.12.1/download https://enterprise.github.com/releases/3.12.1/download
    - rudasn 3y ago
      Nice, thanks!
- iforgotpassword 3y ago
  Assuming they wrote an entirely new sshd in ruby or something. Otherwise why should they ship the source code to a patched-up opensshd...
  - TheDong 3y ago
    You can see them writing the ssh public keys that are entered into the settings page _somewhere_ in ruby, and you can then kinda guess :)

mkesper 3y ago

I remember looking at SSH public key fingerprints in Savannah at the time and wondering why SO MANY started with AAAA (thought it was some padding first...)

unhammer 3y ago
The AAAA (and several of the following characters) is just a header showing what type of key it is: https://crypto.stackexchange.com/questions/5944/why-do-all-ssh-rsa-keys-begin-with-aaaab3nzac1yc https://crypto.stackexchange.com/questions/5944/why-do-all-s...
- denton-scratch 3y ago
  That's the header on the public key itself; the fingerprint GP referred to doesn't have a "header".
  - tedunangst 3y ago
    The broken keys didn't all have fingerprints of AAAA either.

immibis 3y ago

As I understand it, the OpenSSL RNG was seeded by uninitialised stack memory and the PID. Debian seeded it with just the PID. But wasn't that already quite dangerous even without the Debian patch?

jwilk 3y ago
This is incorrect. OpenSSL seeded its RNG also with data read from /dev/urandom.
tialaramex 3y ago
Yes, this misunderstanding does seem to be very popular. No, that's what was going on here, the OpenSSL code had two places where it copies of a bunch of bytes, and one of those copies can end up with uninitialized junk, so that's wrong. Somebody wrote a patch which fixes this, and then - even without assistance from an LLM just using normal human incompetence, somebody said "There's another similar copy nearby, we should get rid of that one too" and Debian landed the patch to apply both changes. The result is now OpenSSL doesn't copy any bytes. It doesn't copy the uninitialized data, which is good, and it also doesn't copy the truly random entropy into the pool. Oops.
- orra 3y ago
  > and one of those copies can end up with uninitialized junk, so that's wrong. To be fair to the Debian patch, reading from uninitialized junk doesn't sprinkle randomness into the desired buffer: it invokes undefined behaviour. The Debian patch was lawful!
  - tedunangst 3y ago
    The part where they also zeroed the buffer with intentionally random data may have been lawful, but it wasn't good.
- ptx 3y ago
  From Russ Cox's post[0] about this, it sounds like the place in the code that initializes the buffer with actual random data also uses the parts of the buffer that haven't been initialized. So there weren't two separate pieces of code, one copying junk and one copying actual random entropy, but rather "at least three different places" that did both, if I've understood this correctly. [0] https://research.swtch.com/openssl https://research.swtch.com/openssl

matsemann 3y ago

> Ezra Zygmuntowitz pointed GitHub in my direction, and let me take the time to really get into the problem with the GitHub team This sentence is funny to me. Maybe because I'm not a native speaker, but I can't avoid reading it as a big problem with the GH team itself, heh. I was expecting the next sentences to "get into" that. > I wonder if Luciano hadn’t found it, how long it might have been before it was found I think perhaps only GH or one of the big cloud providers would have stumbled upon it, few places I can think of that would have thousands and thousands of keys stored from users.

alias_neo 3y ago
> This sentence is funny to me It does / can read both ways, but a comma after "problem" would have removed that doubt.
- thedanbob 3y ago
  But that wouldn't be correct syntax. That would imply the middle section was an addition to the complete thought of the outer two sections, e.g. > Ezra Zygmuntowitz pointed GitHub in my direction (and let me take the time to really get into the problem) with the GitHub team > Ezra Zygmuntowitz pointed GitHub in my direction (...) with the GitHub team
arnsholt 3y ago
In syntactic problem, this is called the PP attachment problem. Basically, should the sentence read (get into the problem) (with the GH team) or (get into (the problem with the GH team)). Turns out to be a very hard thing to do correctly.
- gosub100 3y ago
  Is that the same thing as being a context sensitive grammar?

ckastner 3y ago

An important fact that I only recently learned about this vulnerability is that the change that introduced it was not some rushed act: the maintainer raised the problem they were seeing on the OpenSSL mailing list, proposed a change to fix the problem with a request for feedback, and got some (including from upstream). The result was a terrible vulnerability, but it seems more of a case of spectacularly bad luck of everyone not spotting the issue.

yashap 3y ago
Probably more lacking automated test coverage than bad luck? For security critical RNG code, seems to me you’d really want to have a test where it generates a tonne of random numbers and asserts that they’re all unique.
- tizvoivo 3y ago
  [dead]
- bdonlan 3y ago
  In this case, the problem was the seed was low entropy, so if you generated a bunch of random numbers with a single initialization of the RNG seed you would get unique values. It's a tricky scenario to test for if you don't know of the failure mode...
- gunapologist99 3y ago
  It's not possible to assert that a number is not random (or is). You can look at it and you just don't know. This was the issue with the PRNG blackbox mixing. Obligatory Dilbert https://imgur.com/uR4WuQ0 https://imgur.com/uR4WuQ0 and XKCD: https://xkcd.com/221/ https://xkcd.com/221/
- brokenmachine 3y ago
  So if you rolled a dice a few times and happened to get the same number, you'd throw the dice away for not working properly?

Sesse__ 3y ago

“While I’ve not found a description of exactly when and how Luciano Bello discovered the vulnerability that became CVE-2008-0166 […]” From my IRC logs at the time: 17:23 < luciano> has really an accident. I was needing many primes numbers... 0:-) 17:23 < Sesse> and you got the same numbers every time? 17:25 < luciano> Sesse, not every time :P

rmetzler 3y ago
Luciano in these lines sounds like he just generated lots of keys and then started to wonder why he got more collisions than expected. Thanks for sharing.
cryptonector 3y ago
I miss bash.org.

tomlong 3y ago

I realise it is separate to the weak key prime discovery, but it is interesting how much slow SSH login times are a thread that is worth pulling for one reason or another.

nonrandomstring 3y ago

> I feel like we, as an industry, got a bit lucky that someone with the skills, time, and energy was on hand at the right time to make a huge difference. This is where statistics of "many eyes" and "sunlight as disinfectant" hits home. However bizarrely improbable that anyone would just wander along and find a a bug, people do, because they can. With proprietary/closed code, the probability is zero.

candiddevmike 3y ago
> With proprietary/closed code, the probability is zero. People discover bugs all the time in closed source software...
- nonrandomstring 3y ago
  Which people?
  - thfuran 3y ago
    Customers, though they usually aren't finding security vulnerabilities.
    - nonrandomstring 3y ago
      > Customers Ah I see what you mean. Problem of language then. "Finding bugs", to me as a coder, means something different from observing the effects of bugs. Sure, I can see incorrect behaviours in lots of proprietary software. And I can guess what might cause it. But without the source code that's not the same as "finding bugs".
      - xyzzy_plugh 3y ago
        "finding a bug" in source code implies there's a mistake there. A bug can be that the implementation doesn't match the spec, or that the spec changed, with respect to the user (customer). Reporting bugs vs finding them is perhaps what you're looking for, but I'd argue finding is overloaded. It's perfectly valid to kick the tires on some software and find some bugs. I've found thousands of bugs in closed source software before, and subsequently reported those bugs.

tzs 3y ago

> After examining a variety of different possible solutions, we came to the conclusion that the least-worst option was to patch OpenSSH to lookup keys in a MySQL database, indexed on the key fingerprint. Why MySQL rather than sqlite? They were trying to speed up access to ~/.ssh/authorized_keys. That's the kind of situation mysql is designed to shine in. I would have expected that patching OpenSSH to check for ~/.ssh/authorized_keys.db would be less work than patching it to use MySQL.

klysm 3y ago
I’d imagine there are many machines involved and maintaining one database is typically easier than maintaining many. I’d also imagine MySQL was already in operation, so there wasn’t any startup cost to storing data there. They already had a database of users _somewhere_

epx 3y ago

Another interesting episode was the detection of RSA keys with common 'p' or 'q' factors using GCD: https://factorable.net/weakkeys12.extended.pdf https://factorable.net/weakkeys12.extended.pdf