Forgot your password?
typodupeerror
Security Debian Encryption Software Linux

Debian Bug Leaves Private SSL/SSH Keys Guessable 670

Posted by timothy
from the security-is-a-process dept.
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.
This discussion has been archived. No new comments can be posted.

Debian Bug Leaves Private SSL/SSH Keys Guessable

Comments Filter:
  • by spikedvodka (188722) on Tuesday May 13, 2008 @11:05AM (#23391870)
    Who did this? You don't remove the seeding... stupid

    did I mention stupid?

    this is how some of the old video games were "broken" despite using "random" numbers, the seed was always the same... leading to the same sequence of events
  • by Anonymous Coward on Tuesday May 13, 2008 @11:08AM (#23391912)
    Ubuntu got an updated advisory at http://www.ubuntu.com/usn/usn-612-2
  • by Idaho (12907) on Tuesday May 13, 2008 @11:11AM (#23391928)
    whether this can possibly be claimed to be an accident *dons tinfoil hat*.

    But seriously, removing the code that seeds a random number generator? I can hardly imagine making such a change by accident. I may just lack a sufficiently colorful imagination, though.

    (or, before resorting to conspiracy theories, we should probably ask ourselves first, "can this possibly be explained by simple stupidity?"
    • by sciencewhiz (448595) on Tuesday May 13, 2008 @11:27AM (#23392118)
      It was reading from initialized memory to for the seed value, leading to valgrind warnings. See the original Debian bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516 [debian.org]
      • by 0xABADC0DA (867955) on Tuesday May 13, 2008 @12:45PM (#23393110)
        Actually it looks like valgrind was just confused about whether the buffer was initialized. The openssl code for the edg swaps a pointer to be an uninitialized buffer right before calling read with it... maybe this kind of code confused valgrind.

        It isn't easy to find where the function they changed is actually called... it gets added to an array of function pointers and then a static variable is set to it, and then there are various macros that can obtain it. I can see how valgrind could be confused, but in any case there is a function that takes a buffer and adds it as randomness and they nuked it. They totally screwed up because they assumed that valgrind was perfect at figuring out what memory was initialized.

        There is no simple excuse like 'it was uninitialized wanyway', the debian openssl team just blew it, big time.
  • by psyopper (1135153) on Tuesday May 13, 2008 @11:12AM (#23391942)
    Got up this morning, booted the machine and got a software update first thing: OpenSSH (et al) updates for my Ubuntu Gutsy install. Then I show up over here and see why. Presumably Feisty and Hardy got them as well - they are listed on the Ubuntu announcement.
  • by MosesJones (55544) on Tuesday May 13, 2008 @11:12AM (#23391944) Homepage
    First off I'm a big OSS supporter, yada, yada

    But the point here is that the freedom that OSS gives you does require you to trust the whole distribution chain. In this case there was an added muppet who did something they shouldn't have thus rendering everything downstream insecure. OSS is great but it required great developers, given that it has take well over a year to get the advisory out it shows that the many eyes piece didn't work here, mainly because the eyes were looking at the original source not the botched packaging job.

    The "easy to use" Linux box in the house uses Ubuntu and has this issue and like many people I didn't even think to check that the OpenSSL wasn't the REAL OpenSSL it was OpenSSL with muppet extensions. Maybe there needs to be some form of extension that warns that a package has been modified from its original source code and that the modification was done by "K. Frog" so you can determine whether to trust that package or look back to the source.

    Or some sort of voting system on contributors (how very Web 2.0) so you can see how the people who touched your package were rated with the biggest weighting being given to the last person through the code (hand edited by Linus = 5 stars, hand edited by James Gosling = 5 stars, hand edited by the bloke who wrote clippy = 2 stars, hand edited by a bloke who removed a seed generator = 0 stars).

    Having the code is great, but this makes me want to know much more about who last edited that code.

  • by n0dna (939092) on Tuesday May 13, 2008 @11:15AM (#23391982)
    It was accidentally introduced in 2006... so that's what, another 14 years before it gets moved into 'stable'?

    *grin*
  • by nweaver (113078) on Tuesday May 13, 2008 @11:18AM (#23392024) Homepage
    "You fell for one of the classic blunders, the most famous being 'Never get involved in a land war in Asia' but only slightly less well known is 'Don't use poorly seeded pRNGs in cryptographic protocols!' HAHAHAHAHAHHAHAHAHAHHAHAHAHAHAHA!!!!
    • by EricR86 (1144023) on Tuesday May 13, 2008 @11:38AM (#23392264)

      BUTTERCUP: Who are you?

      MAN IN BLACK: I am no one to be trifled with, that is all you ever need know.

      BUTTERCUP: To think -- all that time it was your cryptographic protocol that was poorly seeded.

      MAN IN BLACK: They were both poorly seeded. I spent the morning downloading a patch to build an immunity to keys being guessed.

  • 2 years? (Score:5, Interesting)

    by Anonymous Coward on Tuesday May 13, 2008 @11:22AM (#23392068)
    The seeding was removed and it wasn't noticed for TWO YEARS? In a distro as popular as Debian?
    • Re:2 years? (Score:5, Interesting)

      by jrothwell97 (968062) <jonathan@notrosw ... minus physicist> on Tuesday May 13, 2008 @12:22PM (#23392784) Homepage Journal
      Hang on. There was a story here the other day about a bug in BSD that had been carried down to all its descendants (FreeBSD, OS X, NetBSD etc) for twenty-five years without anyone noticing. Two years is nothing.
    • Re: (Score:3, Funny)

      by Chemisor (97276)
      Open Source programmers are getting older, and many eyes are getting blurry.
  • comics (Score:5, Funny)

    by Anonymous Coward on Tuesday May 13, 2008 @11:28AM (#23392134)
    http://www.random.org/analysis/dilbert.jpg
    http://www.xkcd.com/221/
  • Too early (Score:5, Funny)

    by sakonofie (979872) on Tuesday May 13, 2008 @11:37AM (#23392242)
    I realized I probably should be legally required to have a morning cup of coffee before thinking because I am an idiot otherwise.

    I wake up and what do I see first thing? That there is a problem with Debian's OpenSSH package and the /. article links to the following code snippet:

    def init(pipeline, librarian):
              gst.debug_set_default_threshold(gst.LEVEL_ERROR)
    - if gst.element_make_from_uri(gst.URI_SRC, "file://", ""):
    + if gst.element_make_from_uri(
    + gst.URI_SRC,
    + "file:///Sebastian/Droge/please/choke/on/a/bucket/of/cocks", ""):
                      global playlist
                      playlist = PlaylistPlayer(pipeline or "gconfaudiosink", librarian)
                      return playlist

    Now I am thinking, "What exactly is going on here? Is choking on a bucket of cocks not a good source of randomness?"
  • A great filter (Score:5, Insightful)

    by Free the Cowards (1280296) on Tuesday May 13, 2008 @11:44AM (#23392336)
    Anyone who posts to this story saying that this is no big deal or telling other people to stop whining should simply be banned from Slashdot for life. If you cannot be bothered to read the article and you cannot be bothered to understand just what a serious vulnerability this is but you insist on insulting those who do, why should you be allowed to continue to post your ignorant bleating?
  • Going to http://www.links.org/?p=327 [links.org] I read...

    OpenSSL happens to include a rare case when its OK, or even a good idea: its randomness pool. Adding uninitialised memory to it can do no harm and might do some good, which is why we do it.
    Uninitialised data doesn't seem to be a good source of randomness to depend on, since depending on where it happens you may consistently end up with a buffer that previously contained all zeroes (or some default memory test pattern), the same part of the same shared library header, or a series of stack frames that for whatever reason happen to be the same frames on every run.

    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.
    • by Chris Burke (6130) on Tuesday May 13, 2008 @02:02PM (#23394194) Homepage
      Uninitialised data doesn't seem to be a good source of randomness to depend on, since depending on where it happens you may consistently end up with a buffer that previously contained all zeroes (or some default memory test pattern), the same part of the same shared library header, or a series of stack frames that for whatever reason happen to be the same frames on every run.

      Well yeah, especially because a byte of "uninitialized" memory, like all memory regardless of how many times it has been initialized, is much more likely to contain the value zero than any other. That'd be like using a 6-sided die as a source of randomness when the '1' side was ten times the area of the '6' side.

      However as mentioned, that's not the only or main source of randomness, and getting rid of that randomness was not the bug. It was getting rid of other sources of randomness in the process, because they -resembled- the function that used uninitialized memory.
  • by ewhac (5844) on Tuesday May 13, 2008 @12:27PM (#23392850) Homepage Journal
    Does anyone have any back-of-the-envelope calculations as to how badly this compromises existing keys? That is to say, about how long is the brute-force lifetime shortened? If it's been shortened from the age of the known universe to 300 hours, then that's a problem I need to address fairly immediately. OTOH, if it's been shortened to one-quarter the age of the known universe, then I'm not going to deal with this before I've had more coffee...

    Schwab

  • by Animats (122034) on Tuesday May 13, 2008 @12:27PM (#23392852) Homepage

    Has someone actually checked the random output for cryptographic soundness?

    The proper source of cryptographic-quality random bits in Linux is "/dev/random". Reading uninitialized memory is not a good source of entropy - it might be initialized to some constant value, especially if you're compiling with a debug allocator or running under a virtual machine monitor.

    OpenSSL makes substantial efforts to get a good random starter. [openssl.org] Unless someone did something so stupid that OpenSSL didn't use /dev/random, it should still work. OpenSSL is supposed to have a check for bad random seeds. Was that bypassed, or doesn't it work, or what?

    Obtaining a good source of randomness is hard. Computers are rather deterministic. Historically, there have been major failures in this area. See "Venona" [wikipedia.org] where the USSR was generating "one-time pads" by having people type random digits on typewriters. Arlington Hall, NSA's predecessor, cracked that. Humans aren't random enough. True random number generation requires special hardware [fourmilab.ch], like a noise diode or a radiation source.

    "Any one who considers arithmetical methods of producing random digits is, of course, in a state of sin." -- John von Neumann

  • by multi io (640409) <olaf.klischat@googlemail.com> on Tuesday May 13, 2008 @02:12PM (#23394336)
    reading the weak key detector script...

    ...it looks like the affected Debian OpenSSHs can generate only 262148 (or something) distinct keypairs. Can this be true? If it is, this is fucking serious.

Can't open /usr/fortunes. Lid stuck on cookie jar.

Working...