Debian Bug Leaves Private SSL/SSH Keys Guessable 670
SecurityBob writes "Debian package maintainers tend to very often modify the source code of the package they are maintaining so that it better fits into the distribution itself. However, most of the time, their changes are not sent back to upstream for validation, which might cause some tension between upstream developers and Debian packagers. Today, a critical security advisory has been released: a Debian packager modified the source code of OpenSSL back in 2006 so as to remove the seeding of OpenSSL random number generator, which in turns makes cryptographic key material generated on a Debian system guessable. The solution? Upgrade OpenSSL and re-generate all your SSH and SSL keys. This problem not only affects Debian, but also all its derivatives, such as Ubuntu." Reader RichiH also points to Debian's announcement and Ubuntu's announcement.
Many eyes make all bugs shallow (Score:0, Interesting)
Re:It will be fixed (Score:3, Interesting)
It seems more like an attempt to show that a maintainer was being petty which is not what the article was about.
Does anyone one really think that this change would have been accepted upstream (or even have had a place for it there?)
Re:Many eyes make all bugs shallow (Score:3, Interesting)
I understand he's not unheard of in this arena.
Re:stupid stupid stupid (Score:3, Interesting)
The point is that encryption, proper randomization, etc are HARD and prone to a lot of errors. That's why you commit changes upstream, so that the people who did the work in the first place are able to review the change and let you know if you changed something vital to the security.
2 years? (Score:5, Interesting)
Re:The big question is.. (Score:2, Interesting)
This is going to make me seriously reconsider using Debian in the future. I always thought the OpenBSD guys were assholes. Now they're laughing at us.
Re:stupid stupid stupid (Score:2, Interesting)
http://lists.debian.org/debian-security-announce/2008/msg00152.html [debian.org]
is an example of a vulnerability caused by seeding the random number generator with the current time right before use.
Re:stupid stupid stupid (Score:5, Interesting)
Re:OSS, only as good as the last developer? (Score:2, Interesting)
So if one didn't like the 'muppet.patch' included, one could always remove it before building the package. Much, much better than delivering a patched tarball.
--
Regards
Surely this is not the only source of entropy! (Score:5, Interesting)
In fact I'd expect that separate runs of the same program with the same parameters and environment would leave the same junk on the stack every time.
So I would hope that they have some better source of entropy than unpredictable uninitialized data of dubious randomness.
So if this is really a serious problem, then it seems to me there's already a serious problem in OpenSSH.
Re:stupid stupid stupid (Score:3, Interesting)
Planting a vulnerability that has gone undiscovered for 2 years and that gave the keys to a lot of SSH servers. Genius !
Re:It will be fixed (Score:2, Interesting)
Re:2 years? (Score:5, Interesting)
Degree of Compromise? (Score:5, Interesting)
Schwab
correct me if I'm wrong (Score:5, Interesting)
It looks like openssl is pulling in "entropy" from uninitialized memory, causing valigrind to complain. The debian maintainer "fixed" this issue by memsetting the buffer to zero.
My question is, wouldn't I see the same behavior using grsecurity to scrub deallocated memory? From what I am seeing, this looks much more like the fault of the openssl team.
Re:It will be fixed (Score:5, Interesting)
He would have been told, but who says he would have cared? This happens all the time, although usually it doesn't result in a giant fucking security hole. I was warning people this sort of thing would happen more than two years ago back when I was working on autopackage. It was entirely predictable.
Having distributors randomly change source code as they package it is fundamentally broken. It cannot ever work. It's not just OpenSSL that's been broken like this. Wine often went through periods in which the Debian packages were completely hosed in subtle ways. It would look like a bug in Wine, but was in fact due to parts of the software "going away", because the Debian packager felt they weren't important enough to be a part of the base install. Pointing out that their change was broken didn't help. The result was many, many hours wasted tracking down non-bugs. Then you go through a giant waste of time trying to get the bug in the packages fixed, and just as you finally get it sorted out, some other distribution introduces some other bug into their packages.
So I got sick of this, and started telling people to avoid their distros packages. Some distributors (especially Debian) took it personally and started childish slanging matches. But really, who cares how "integrated" a program is, if it could have had arbitrary bugs silently introduced? It's just a busted model of software distribution.
Imagine if Microsoft reserved the right to modify any software for Windows in any way it saw fit! Yet that's exactly what Debian (and Fedora and Mandrake and Ubuntu) said to me - they reserve the right to make any modifications they like to the software they ship, and if upstream don't like it, tough luck.
I wonder if they'll re-evaluate that policy in light of this disaster. Probably not.
Re:What does "guessable" mean here? (Score:3, Interesting)
I have now patched my firewall and ssh config to (hopefully) limit any bruteforcing to one attempt per minute:
MaxAuthTries = 1
iptables -I INPUT -p tcp --dport 22 --syn -m limit --limit 1/minute -j DROP
Ofcourse what remains is the question of how many attempts would be realistically needed to break a weakened key?
I'm eager to see the first proof-of-concept exploit.
Kurt Roeckx (debian) mail to openssl-dev list (Score:3, Interesting)
Found this post at openssl-dev list by Kurt Roeckx ( AFAIK the Debian OpenSSL Team member that made this RNG-clean patch )
http://www.mail-archive.com/openssl-dev@openssl.org/msg21156.html [mail-archive.com]
Extract:
"What I currently see as best option is to actually comment out those 2 lines of code. But I have no idea what effect this really has on the RNG. The only effect I see is that the pool might receive less entropy. But on the other hand, I'm not even sure how much entropy some unitialised data has.
What do you people think about removing those 2 lines of code?
Kurt
"
BTW, i thought that Debian had some kind of policies about testing each package before committing changes in testing/stable branches. Also, the following paper, contributed by another poster, says interesting things about touching cryptographic code, we have to learn from this experience and have tighter policies !
" In a narrow sense, the security flaw we found in the Netscape browser serves merely as an anecdote to emphasize the difficulty of generating cryptographically strong random numbers. But there's a broader moral to the story. The security community has painfully learned that small bugs in a security-critical module of a software system can have serious consequences, and that such errors are easy to commit. The only way to catch these mistakes is to expose the source code to scrutiny by security experts.
Peer review is essential to the development of any secure software. Netscape did not encourage outside auditing or peer review of its software-and that goes against everything the security industry has learned from past mistakes. By extension, without peer review and intense outside scrutiny of Netscape's software at the source-code level, there is simply no way consumers can know where there will be future security problems with Netscape's products. "
http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html" [berkeley.edu]
Ongoing problem for host keys? (Score:3, Interesting)
SSH host keys are generated at sshd install time, and that package is included on the netinstall CD-roms, which means every time I re-use my 4.0r1 netinstall CD to set up a new box, I generate a new set of vulnerable host keys before I get to the security-updates step.
Hopefully, they'll advance the next point release and a 4.0r2 netinstall CD will do better.
Re:correct me if I'm wrong (Score:4, Interesting)
If you look further down the code, it then fills up the buffer with stuff from some random device (/dev/random
AFAIK, all modern Linux implementations have
I only spent a minute looking that the code and the diff in the parent's post, but this is looking not to be a bug to me. But, like I said that I didn't look at the code that long, but I don't see where memsetting the memory makes any difference if its all being overwritten.
Re:It will be fixed (Score:2, Interesting)
Though, as has been pointed out elsewhere, the Debian package maintainer did raise this issue with the openssl developers [marc.info], and was basically told "go ahead, it's OK."
Re:Degree of Compromise? (Score:1, Interesting)
Re:stupid stupid stupid (Score:2, Interesting)
Re:stupid stupid stupid (Score:3, Interesting)
A similar story is described in the book The Art of Intrusion by Kevin Mitnick. Mitnick interviewed someone who claimed to be part of a group of 4 friends who bought a slot machine, reverse engineered the firmware, the game application, the pseudo random number generator, etc. They found a flaw in the PRNG, were able to determine its internal state by watching the cards dealt so far, and were able to develop an algorithm able to predict the outcome of the game.
Then they built a small portable device to run their algorithm on-site, in casinos using the exact same slot machine model. It is rumored they won a lot of money this way and took enough precautions to never being caught (I guess they spread their attack over a large number of casinos/cities and multiple years).
Of course the story is anonymized so can't be verified. And it is in Mitnick's interest to have exciting stories in his book. But IMHO the attack looks totally plausible. Game developers usually have no security background, especially regarding how to design a secure PRNG.
Re:Ongoing problem for host keys? (Score:3, Interesting)
If the host keys are vulnerable on a server, doesn't this just leave you open to a man in the middle attack anyway? That's not as serious as generating keys you use to login with, in which case you need to regenerate those as soon as possible. Is it possible to break into a server just by guessing the host or server keys?
I have an eCommerce site (Score:4, Interesting)
According to the reps at Thawte, if you are using a third party ssl cert (thawte, verisign, etc), this does not affect you. According to them, this is only dangerous for people who have generated their own SSL certs for their sites from the ground up (probably a minority, I would guess). If anybody has any information to the contrary, please let me know.
Check those CA contracts... (Score:3, Interesting)
This is page 45-46, which talks about the reasons why a certificate may be revoked:
Rough translation: The certificate may be revoked when ... there's something that makes you reasonably believe that the certificate has been compromised to the point that it is not reliable.
And then on page 47 it says:
Rough translation: If the revocation of the certificate is not the fault of the subscriber (that's you), then you get a new certificate with the same validity period as the old one.
Obviously, you have to check with the contract governing your CA, but you might find something similar, so check with your CA before paying for new certs.
Re:I have an eCommerce site (Score:4, Interesting)
Even if your certs are fine, individual transactions are likely vulnerable.
If someone has taken packet captures, they will likely be able to decrypt them retro-actively.