Debian OpenSSL fiasco



  • Expect Zillions of pwned Debian (Ubuntu, Xandros, ...) boxes during the next days... 

    http://metasploit.com/users/hdm/tools/debian-openssl/ 

    But, on the plus side, at least purify and valgrind are happy with the code.



  • <obligatory>

    </obligatory> 



  • News hit slashdot on tuesday: http://it.slashdot.org/it/08/05/13/1533212.shtml


    http://it.slashdot.org/comments.pl?sid=551636&cid=23394472
    If I read the published "weak key detector" script correctly, Debian OpenSSHs will always generate one out of a fixed set of 262148 possible keypairs. Do the math yourself. If you know those keys, this is a 5-minute brute force attack.
    Now THAT hurts. I guess some admins are doing overtime right now. Lucky that I run windows! (actualy, I run slackware ;))


  • @Daid said:

    Now THAT hurts. I guess some admins are doing overtime right now. Lucky that I run windows! (actualy, I run slackware ;))
     

    Nope! You may be affected too:

    • you may have generated a key that belongs now to the weak keys pool;
    • you may have imported a weak key generated elsewhere, on an affected system. 


  • In the case where you're using 'ordinary' password authentication at least, you're only vulnerable if you USE ssh with a weak key. If your ssh servers have weak keys, and you haven't yet updated, just don't ssh to them!

    Of course it's possible black hats found this first and will have previously compromised you. But I'm not worrying too much.

    Sure is a nasty bug though.



  • @acne said:

    @Daid said:

    Now THAT hurts. I guess some admins are doing overtime right now. Lucky that I run windows! (actualy, I run slackware ;))
     

    Nope! You may be affected too:

    • you may have generated a key that belongs now to the weak keys pool;
    • you may have imported a weak key generated elsewhere, on an affected system. 
    Uh. It's a very simple server machine, I think the only key that it has must be the SSH server key. And I authenticate with passwords on SSH. So I think the only risk that I have is that someone could find out my private SSH server key and do a man in the middle attack. If I have one of the 'weak' keys.



  • Right on time!  Every 2-3 years Debian has a major security fuck-up like having several of their servers compromised and they rush to save face.  After almost a decade of this, I have to wonder if Debian will ever be able to escape its pathetic history of security problems.



  • I wonder, do the Debian developers actually get a heads-up about this, or do they get to read it in the headlines and develop a bigger headake every next word?



  •  @dlikhten said:

    bigger headake

    At least you got everyone to laugh at you on the IRC channel...



  • @morbiuswilters said:

    Right on time!  Every 2-3 years Debian has a major security fuck-up like having several of their servers compromised and they rush to save face.  After almost a decade of this, I have to wonder if Debian will ever be able to escape its pathetic history of security problems.

    They're not "rushing to save face", they've made a timely and effective response to what is a fairly serious, but presumably non-obvious, bug.Security vulnerabilities happen; this is just an unusually far-reaching one because it affects a very widely used server, and more visible to the user than most as the keys must be re-generated. It's somewhat limited anyway, in that security is only compromised if the service is used when the vulnerability is known about.

    Sure Debian's no OpenBSD, but there are operating systems with far worse security issues.



  • Ubuntu just gave me an OpenSSL update today, I didn't look at the changelog too closely, but I assume it fixes the issue, so problem solved for Ubuntu at least (I wasn't running an ssh server anyways). 



  • @burntfuse said:

    so problem solved for Ubuntu at least (I wasn't running an ssh server anyways). 
     

    Only if you never used your SSH to generate any key pairs. Anyone who actually ran one of the buggy SSH servers and/or used it to generate key pairs is vulnerable until all the keys generated with it are replaced with properly generated ones.

    Essentially they sent out a new SSH that'll lock your door properly, but if you used the older version of lock, then pretty much anyone can pick open your door (or any other doors you used your keys on) with the equivalent of a cereal box decoder ring until you do the work to replace the keys for that old lock.



  •  Ok, well "bug fixed" is more accurate then.



  • @m0ffx said:

    They're not "rushing to save face", they've made a timely and effective response to what is a fairly serious, but presumably non-obvious, bug.Security vulnerabilities happen; this is just an unusually far-reaching one because it affects a very widely used server, and more visible to the user than most as the keys must be re-generated. It's somewhat limited anyway, in that security is only compromised if the service is used when the vulnerability is known about.

    Sure Debian's no OpenBSD, but there are operating systems with far worse security issues.

    I'm amazed you can act like this is no big deal.  This is a huge security vulnerability and many systems will be compromised because of a screw-up by the Debian developers.  Additionally, this even effects non-Debian systems as any SSH key generated with the broken software is now compromised.  What's more, it was undetected by the Debian team for 2 years.  Supposedly FOSS is more secure because of all the eyes on the code.  I think this incident is further refutation of that theory and proof that it doesn't matter how many eyes you have on the source if those eyes are not experienced enough to recognize severe flaws such as this one.  I'm just glad that I fled from the entire Debian ecosystem years ago and have never been personally harmed by the incompetence of the distro maintainers.



  • @morbiuswilters said:

    Supposedly FOSS is more secure because of all the eyes on the code.  I think this incident is further refutation of that theory and proof that it doesn't matter how many eyes you have on the source if those eyes are not experienced enough to recognize severe flaws such as this one. 

    No, the lesson to take away from this is that the only secure system is Bruce Schneier's brain... and that's only because Bruce doesn't feel like cracking it.



  • @MarcB said:

    Only if you never used your SSH to generate any key pairs. Anyone who actually ran one of the buggy SSH servers and/or used it to generate key pairs is vulnerable until all the keys generated with it are replaced with properly generated ones.
    Which I believe the security update automatically does. Correct me if I'm wrong.

    @morbiuswilters said:

    This is a huge security vulnerability and many systems will be compromised because of a screw-up by the Debian developers.
    Find me ONE case of a break-in known or reasonably suspected to be caused by this bug (and NOT of a system that doesn't get frequent updates). Then I might pay more attention to what you're saying.



  • @m0ffx said:

    Find me ONE case of a break-in known or reasonably suspected to be caused by this bug (and NOT of a system that doesn't get frequent updates). Then I might pay more attention to what you're saying.

    Jeez, drink enough Kool-Aid? If I leave my back door open for two years, it's no less of a security vulnerability because nobody walked in and took my TV.



  • @m0ffx said:

    Correct me if I'm wrong.
     

    Any keys generated by one of the bad versions had, as their ONLY source of entropy, the PID of the ssl process doing the generation. On Linux boxes that limited the space for random seeds to 2^15-1 ints (32,767 possible seed values). The only thing the patched versions do is fix the key generation process to add back in the entropy sources that were removed. These days, testing 32,7687 possibilities is trivial.

    Given someone's public key and the random value (32767 possibles, remember) used in generating it, you can recover a person's private key. If these keys were used to set up password-less access between systems, then at most you have to test 32,768 possibilities and you're in. Ditto for SSL certs, ditto for signature keys, yada yada yada.

    This is why the "bug" is so horrible. It's not that SSL/SSH were hacked with a buffer overflow of anything. It's that a stupid developer who had no business poking around in its guts made a trivial change that completely destroyed the basis of SSL's crypto security. SSL requires high quality random number generators, which require high quality entropy sources, and this idiot developer took the equivalent of google desktop search and replaced it with SSDS.

    @m0ffx said:

    Find me ONE case of a break-in known or reasonably suspected to be caused by this bug

    There's a metasploit plugin, already, to probe and test systems for these bad keys. Remember, you only need to test 32,767 possibilities per username.



  • @m0ffx said:

    Find me ONE case of a break-in known or reasonably suspected to be caused by this bug (and NOT of a system that doesn't get frequent updates). Then I might pay more attention to what you're saying.

    Why should I do your research for you?  Also, it's not like every single hacked Linux system ends up with a front-page story on Slashdot, that only happens when someone using proprietary software gets exploited.  Finally, a lot of Debian users probably don't know they've been compromised.  If they knew enough to determine if they machine has been rooted, they probably wouldn't be running Debian.



  • @bstorer said:

    No, the lesson to take away from this is that the only secure system is Bruce Schneier's brain... and that's only because Bruce doesn't feel like cracking it.

     

    Brute force AKA baseball bat does wonders.



  • @alegr said:

    @bstorer said:

    No, the lesson to take away from this is that the only secure system is Bruce Schneier's brain... and that's only because Bruce doesn't feel like cracking it.

    Brute force AKA baseball bat does wonders.

    Fool! You think you can defeat a skull encrypted with Blowfish using your silly little bat?



  •  @bstorer said:

    Jeez, drink enough Kool-Aid? If I leave my back door open for two years, it's no less of a security vulnerability because nobody walked in and took my TV.
    Poor analogy. It's more like your back door having a lock of a type whereby every lock can be opened with one of a handful of keys.If this isn't known for two years, until the manufacturers 'fess up and send you a new lock without the issue, then what's the problem. Of course, if some burglar (equiv. cracker) found this out sooner, THEN there's a problem. But did they? It's hard to know.

     @MarcB said:

    The only thing the patched versions do is fix the key generation process to add back in the entropy sources that were removed.
    The update also regenerates your keys. Provided you've applied the security updates, you're no longer vulnerable. True, you might have got rooted in the time betweenthe vulnerability being known and you updating. But that applies to pretty much any vulnerability.

    I think it also updates the ssh _client_ to recognise and warn you about connecting to any servers that still use bad keys.

    @MarcB said:

    If these keys were used to set up password-less access between systems, then at most you have to test 32,768 possibilities and you're in.
    And if they weren't, then you're not in. You've got to have eavesdropped the traffic during a session using insecure keys. What proportion of ssh servers use passwordless authentication? I don't know, but I'd guess it's not many. Also, any administrator with half a brain will have their ssh setup to disallow root logins. Unless a hacker manages to eavesdrop and thus decrypt a session where the root password was transferred, they may be in, but only as a normal user.

    It is a seriously nasty bug, that I agree with.

    @morbiuswitters said:

    Why should I do your research for you?
    Because you're the one making out it's a big thing. I'm saying it's not so, meaning I wouldn't expect to find many reports of broken into systems. You're overstating Why would I look for something I don't expect to find?

    In fact, I'm willing to set up a machine with one of the known bad keys, and generate some ssh traffic into it. (I'll probably login and run 'watch fortune' or something). No passwordless authentication, because I never use it on my systems. I'll post the hostname and you can try and break in using this vulnerability. I honestly doubt you'll be able to.

    Actually, maybe ssh is a red herring. What about https - is that affected? If it is then that's a far more serious issue, and most of us in this thread (including myself) have badly missed the point. And I'm gonna have to do the password change run-around again, and make sure all my passwords on different sites are unrelated :-@



  • @m0ffx said:

    The update also regenerates your keys.
     

    Yes, it regenerates local host keys, but it can't do anything about keys you've already shared. What if you generated a public/private pair and sent the public one to a key server? The update doesn't reach out and update that for you. It also won't regenerate any CA signing requests you sent to Verisign to get that shiny new SSL cert for Apache. That's the whole point of all the warnings. If all you had to do was to make the world a cozy/comfy place again was 'apt-get update openssl', then the warnings wouldn't be nearly as dire. 

    @m0ffx said:

    Actually, maybe ssh is a red herring. What about https - is that affected?

    Anything that uses SSL that happens to be using one of the vulnerable keys generated by the bad Debian OpenSSL-generated certs is essentially an open book for man-in-the-middle attacks and session hijacking. If you're connecting to an Ubuntu (say) hosted secure site, it's going to be using an SSL cert that was produced from OpenSSL-generated key, and therefore, yes, it's affected, but only because the keys and cert used to establish the session are cryptopgrahic kleenex.

    If you want a highly unlikely, but absolute worst-case scenario: Imagine Verisign's master CA generating/key signing machine was running the vulnerable OpenSSL. That'd mean every single SSL cert they've generated in the last 2 years is garbage. With the trivially simple PRNG crap in the bad OpenSSL, it'd be utterly trivial to compute Verisign's private master key. After all, their public key is embedded in pretty much every browser in the world. With the master key, you ARE Verisign. You sure that was amazon.com you just sent your Visa # to? 



  • @morbiuswilters said:

    Right on time!  Every 2-3 years Debian has a major security fuck-up like having several of their servers compromised and they rush to save face.  After almost a decade of this, I have to wonder if Debian will ever be able to escape its pathetic history of security problems.
    Morbs do you have examples of Debian's past security fuckups because I honestly have no idea what they are.  I started using Debian sometime in 2005.

    I really am interested.



  • @belgariontheking said:

    Morbs do you have examples of Debian's past security fuckups because I honestly have no idea what they are.  I started using Debian sometime in 2005.

    I really am interested.

    Well, there's [url=http://www.debian.org/News/2003/20031121]this one[/url], which was pretty embarassing.



  • @belgariontheking said:

    I really am interested.

    Guess there's always Proof by Google: <font size="-1">"Results 1 - 10 of about 840 for debian security fuckups. (0.26 seconds)"</font>

    </joke> 

     

    (not that I'm saying there aren't any past security screwups, just making a lame-o joke) 



  • @bstorer said:

    @belgariontheking said:

    Morbs do you have examples of Debian's past security fuckups because I honestly have no idea what they are.  I started using Debian sometime in 2005.

    I really am interested.

    Well, there's this one, which was pretty embarassing.

    I, too, would be interested to hear what happens every couple of years. That's the only other one I know of.


Log in to reply