×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Debian Bug Leaves Private SSL/SSH Keys Guessable

timothy posted more than 5 years ago | from the security-is-a-process dept.

Security 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.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

670 comments

It will be fixed (-1)

Anonymous Coward | more than 5 years ago | (#23391862)

I'm sure the problem will be fixed if the developers acknowledge that the problem exists. Not a big worry.

Re:It will be fixed (5, Insightful)

gQuigs (913879) | more than 5 years ago | (#23391934)

This problem isn't something you can just update your system to fix. This means the basis for all remote authentication on your Debian/Ubuntu machines is compromised until you go and fix it manually.

Re:It will be fixed (0)

Anonymous Coward | more than 5 years ago | (#23392238)

How does the announcement's line "As a result, cryptographic key material may be guessable." make a machine automatically "compromised?" More vulnerable is more like it. The key still needs to be guessed. If the discovered weakness cuts a brute-force effort down to days (or less) instead of years, then I agree ... may as well say "compromised." Perhaps saying "compromised" motivates lazy sysadmins to get off their asses and apply updates? I'm just curious.


I hate slow work days.

Re:It will be fixed (-1, Troll)

tuxgeek (872962) | more than 5 years ago | (#23391958)

Considering that this is in the daylight now, it has probably already been fixed.

Nothing to see here, move along ...

Re:It will be fixed (4, Informative)

Anonymous Coward | more than 5 years ago | (#23392076)

Um.... it doesn't matter if it's been patched, you still have to regenerate all your keys.

There most certainly is something to see here, this is kind of a big deal.

Re:It will be fixed (0)

Anonymous Coward | more than 5 years ago | (#23392132)

You obviously didn't read or understand the advisory if that's your attitude.

Re:It will be fixed (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#23392146)

How can it be fixed? As far as I know, private SSL/SSH keys were always guessable. Not a high probability to guess them, but still guessable.

Re:It will be fixed (1, Informative)

Anonymous Coward | more than 5 years ago | (#23391964)

Yes it's already fixed. I was in the middle downloading the update when when I saw this article.

Re:It will be fixed (0)

Anonymous Coward | more than 5 years ago | (#23391976)

I am presently downloading a patch. Open source is amazing that way.

Re:It will be fixed (4, Informative)

Jellybob (597204) | more than 5 years ago | (#23392138)

Downloading the patch is step one - you also need to regenerate any certificates made with OpenSSL since 2005, since they can't be guaranteed to be secure.

This has the potential to turn into a huge pain in the arse for Debian based shops, who will need to reissue SSL certificates, SSH keys, and a whole host of other essential elements of their security infrastructure.

Re:It will be fixed (2, Interesting)

JackieBrown (987087) | more than 5 years ago | (#23391986)

As far as the bug linked for changes upstream (#477454,) is that seriously the best example of Debian not sharing changes back upstream?

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:It will be fixed (4, Insightful)

Archangel Michael (180766) | more than 5 years ago | (#23391992)

It shouldn't need fixing in the first place.

Debian people screwed up. This leaves a huge distaste in my mouth for Debian (and Ubuntu).

Re:It will be fixed (1)

robot_love (1089921) | more than 5 years ago | (#23392212)

It shouldn't need fixing in the first place.

Debian people screwed up. This leaves a huge distaste in my mouth for Debian (and Ubuntu).

How very...reasonable...of you.

So, you're luvin' Windows, then?

Re:It will be fixed (1)

HappySmileMan (1088123) | more than 5 years ago | (#23392392)

Or any other distro, or Mac, just because he doesn't like the way Debian does things doesn't automatically mean he's sleeping with bill Gates.

Re:It will be fixed (1)

lazy_playboy (236084) | more than 5 years ago | (#23392416)

Well, Debian tries hard to build its reputation for stability and security and sensibleness in general, but arrogantly modifying source code without sending it upstream for verification seriously undermines this.

And I'm not sure that it could be any more serious than when dealing with encryption.

Re:It will be fixed (0, Troll)

Anonymous Coward | more than 5 years ago | (#23392376)

Debian people screwed up. This leaves a huge distaste in my mouth for Debian (and Ubuntu).

Yeah! Cause you never made a mistake did you. plus this was such an obvious and egregious mistake; any fool could/would have caught it. The Debian distributions are obviously crap.

Are you kidding me?

Re:It will be fixed (5, Insightful)

rhavenn (97211) | more than 5 years ago | (#23391994)

I'm sure the problem will be fixed if the developers acknowledge that the problem exists. Not a big worry.
No, but it shouldn't have been changed in the first place. Debian needs to stick their ego up their ass sometimes and just let the people who wrote the software do the coding vs. sticking their own code in in places they don't fully understand. This and their attitude of licensing and not reporting changes back upstream is a stupidly annoying habit.

note: When I have to run Linux instead of a BSD it's Debian and/or Kubuntu all the way since the benefits outweigh the negatives, but it's still an annoying habit of theirs.

The issue is a bit more complicated... (2, Insightful)

Anonymous Coward | more than 5 years ago | (#23392414)

Hmm... no, it shouldn't have been changed. There is absolutely no excuse for touching crypto code when you don't *fully* understand it.

But the fact that changing the use of NON-INITIALISED memory causes most of the seed of a RNG to go away really is worrisome... unless that memory is actually initialized with a seed BUT in a way Valgrind and others can't track. Which means it is sloppy coding on OpenSSL.

You cannot trust unitialized memory, PERIOD. And it will take looking deep into OpenSSL code for me to tell if it was intialized in a way valgrind couldn't see, or that OpenSSL was working due to just plain blind luck (or lack of an attacker).

Either way, upstream prepared the trap, and a debian maintainer sprung it.

Why do YOU think we are not calling for blood on the guy who did the change? Because code that breaks like that is a travesty by itself.

Re:It will be fixed (5, Informative)

Omnifarious (11933) | more than 5 years ago | (#23392018)

I'm sure the problem will be fixed if the developers acknowledge that the problem exists. Not a big worry.

Yes, it is a big worry because any keys generated with this package are now potentially suspect. This means that anybody who's used Debian or a Debian derived distribution like Ubuntu needs to go back and destroy all host and personal keys generated since 2006. All of those keys are potentially guessable.

And that's a real vulnerability. Early versions of Netscape's SSL implementation (the first SSL implementation) were trivially crackable because of just such a vulnerability [berkeley.edu].

Re:It will be fixed (1)

compro01 (777531) | more than 5 years ago | (#23392090)

i was sure that netscape problem was due to the US crypto export regs (the silly encryption=munitions thing) that limited the encryption to 40-bit keys.

Re:It will be fixed (2, Informative)

Omnifarious (11933) | more than 5 years ago | (#23392158)

i was sure that netscape problem was due to the US crypto export regs (the silly encryption=munitions thing) that limited the encryption to 40-bit keys.

Then you are mistaken. Read the linked to paper. N bit security doesn't protect you much when you can guess N-10 bits of the N bits.

Re:It will be fixed (1)

1984 (56406) | more than 5 years ago | (#23392180)

There were two issues: one was that the "export version" had 40-bit encryption which was relatively mathematically weak. Everyone knew that it could be brute forced with enough horsepower, and eventually someone demonstrated that -- though it still cost a lot more computer time (100 HP minis for a year?) than you'd probably want to spend for a single CC number.

The second issue was that the full-strength domestic version used a crappy RNG source. That narrowed the possible keyspace by some tremendous amount. What remained could be brute forced on a desktop PC in a few hours.

Only as good as the implentation :)

Re:It will be fixed (2, Interesting)

illumin8 (148082) | more than 5 years ago | (#23392448)

This means that anybody who's used Debian or a Debian derived distribution like Ubuntu needs to go back and destroy all host and personal keys generated since 2006. All of those keys are potentially guessable.
Great... just when I had mostly convinced the PHBs in management that yes, open source software was trustworthy, and that yes, good developers write Linux, and that no, you don't always get what you pay for, and answered all the hundreds of questions about "why do you think they would develop this software for free?" Now some jackass that shouldn't have even been touching this code fucks around with OpenSSL... I'm not trolling, but maybe open source isn't ready for the enterprise. If some coder did this at a company at least I'm pretty confident they'd get their ass fired, but with open source it's basically "whoops, my bad."

Re:It will be fixed (5, Insightful)

2short (466733) | more than 5 years ago | (#23392184)

Basic cryptographic services have been compromised for a year and your analysis is to assume on faith that it's open source so it will be fixed, so no problem?

If someone stole your crypto keys and has had them for a year...

How thoroughly might they have compromised your system by now?
How many passwords might they have stolen that you use on other systems?
What else might they have done that will give them access in the future even after you fix this?

Just regenerate your keys and no problem? The problem that guessable keys are generated will undoubtably be fixed asap, if not already. The problem that this has been the case for the last year will not be, and is a big worry.

i wondered what was going on (0, Offtopic)

oni (41625) | more than 5 years ago | (#23391868)

I remember installing openSSL on debian long ago and being prompted to type some random text or to move the mouse while the key was generated. More recently, when I installed debian or ubuntu, it just magically generated a key. I guess that was the part that was removed.

Re:i wondered what was going on (3, Informative)

Anonymous Coward | more than 5 years ago | (#23392082)

This has nothing to do with the vulnerability being discussed here.

Re:i wondered what was going on (0, Funny)

Anonymous Coward | more than 5 years ago | (#23392196)

This has nothing to do with the vulnerability being discussed here.
In other words:

NUH-UH!!

"more secure than Windows" (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#23392226)

Doh!

Looks like they were a few pairs of eyes short. Again.

Re:i wondered what was going on (5, Informative)

sumdumass (711423) | more than 5 years ago | (#23392446)

No, the random text your put in can be random or not. What they were talking about is a number generator that was used or applied to an algorithm that decided the prime of your key in so that the same algorithm wouldn't be used on two machines on the first then second keys. Without the random number generator, you could theoretically guess the algorithm used to generate the key based of the actions of another install and then decipher the key to gain access to whatever it was protecting.

To simplify and generalize it, if every machine uses X+1*256 to get a 256 bit key equal to 768, then you could reverse that and know X would =2 (3*256=768) and fake the credentials. The random number generator should change that to X+R*256 which make reversing the key harder because you can only solve to X+R=3 now. In practice, it will be a really larger number and a lot different process though. I can't say that I fully understand it but that simplification should show the difference well enough to give an Idea of where the problem is.

stupid stupid stupid (5, Insightful)

spikedvodka (188722) | more than 5 years ago | (#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

Re:stupid stupid stupid (4, Insightful)

Omnifarious (11933) | more than 5 years ago | (#23391930)

Who did this? You don't remove the seeding... stupid

That's what I was thinking too. What kind of idiot makes that sort of change?

Re:stupid stupid stupid (2, Interesting)

moderatorrater (1095745) | more than 5 years ago | (#23392056)

I also remember some games being broken because you could save, and if the battle didn't go how you wanted it to, you could reload and try again. Nowadays, games tend to save the generator's seed so that things go the same way.

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.

Re:stupid stupid stupid (1, Interesting)

John Meacham (1112) | more than 5 years ago | (#23392108)

Interestingly, another source of compromised security is seeding too often.

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 (4, Interesting)

mikael (484) | more than 5 years ago | (#23392114)

There was a lawsuit story some time ago about a Las Vegas casino vs. a regular punter, over the use of a blackjack game. The punter had found a cabinet unit with a frazzled RNG, so it kept dealing the same sequence of cards every time. The punter managed to memorize the sequence, thus guaranteeing a win every time. Of course, the casino wasn't too happy about this.

Re:stupid stupid stupid (2, Interesting)

Yvanhoe (564877) | more than 5 years ago | (#23392374)

This could be very smart.
Planting a vulnerability that has gone undiscovered for 2 years and that gave the keys to a lot of SSH servers. Genius !

You stupid god damned open sourcers (-1, Troll)

Anonymous Coward | more than 5 years ago | (#23391892)

You told me your OS was secure, and you leave in huge HUGE hole like this? For 2 god damned YEARS?

Windows here I come. At least someone would be accountable for shit work like this.

Re:You stupid god damned open sourcers (5, Insightful)

clang_jangle (975789) | more than 5 years ago | (#23392014)

Windows here I come. At least someone would be accountable for shit work like this.


Yeah, like all those times when MS cut checks for all their customers whose computers were compromised! Oh, wait...

Updated advisory from Ubuntu (5, Informative)

Anonymous Coward | more than 5 years ago | (#23391912)

Ubuntu got an updated advisory at http://www.ubuntu.com/usn/usn-612-2

Re:Updated advisory from Ubuntu (0)

Anonymous Coward | more than 5 years ago | (#23392234)

For once they make it clear in this announcements that it comes from debian.

Many eyes make all bugs shallow (0, Interesting)

Anonymous Coward | more than 5 years ago | (#23391926)

And we were told this sort of bug could NEVER happen in an open source operating system. Seriously, this is a major cockup.

Re:Many eyes make all bugs shallow (2, Insightful)

sterwill (972) | more than 5 years ago | (#23391954)

Who told you that? Why did you believe it? Please cite your sources.

Re:Many eyes make all bugs shallow (0)

Anonymous Coward | more than 5 years ago | (#23392046)

Here [slashdot.org] is the main one, the loudest.

The big question is.. (4, Insightful)

Idaho (12907) | more than 5 years ago | (#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?"

Re:The big question is.. (2, Insightful)

rhavenn (97211) | more than 5 years ago | (#23392016)

(or, before resorting to conspiracy theories, we should probably ask ourselves first, "can this possibly be explained by simple stupidity?"
Very easily. Some coder who didn't understand what he was doing and couldn't figure out the code decided to just remove it.

Re:The big question is.. (2, Interesting)

Anonymous Coward | more than 5 years ago | (#23392100)

What business do they have going that deep within the code? I can understand modifying certain things to make the system more integrated (such as modifying the locations of files), but *WHY* on earth would you fuck around with the cryptographic algorithm? Stupid, stupid, stupid! And I'm not even totally opposed to the idea that this was intentionally done, either.

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:The big question is.. (4, Informative)

Goaway (82658) | more than 5 years ago | (#23392438)

Apparently, OpenSSL was using uninitialized memory as a source of randomness. This made valgrind complain about the program, and some enterprising programmer decided to fix it by clearing the memory before use.

Re:The big question is.. (1)

Culture20 (968837) | more than 5 years ago | (#23392412)

But what C coder doesn't understand the difference between using a randomized (from HID input) seed and a static seed?

Re:The big question is.. (5, Informative)

sciencewhiz (448595) | more than 5 years ago | (#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]

Re:The big question is.. (2, Insightful)

Anonymous Coward | more than 5 years ago | (#23392352)

If it was reading from "un"initialized memory, then OpenSSH was "crusin' for a bruisin'" as my father would say. How long before some OS decides "hey, to prevent process B from 'inheriting' key material, passwords, and other random goodies from process A simply by alloc()ing the space process A used to take up, let's zero out the block of memory that we allocate for each process"? A seed of nothing but zeros, every single time!

If the memory was initialized, then it wouldn't be an issue for valgrind, and the seed would still be whatever the memory had been initialized to.

Re:The big question is.. (2, Informative)

gowen (141411) | more than 5 years ago | (#23392368)

And the ridiculous thing is, in that thread you quote, at least one person is telling the maintainer that they've done a seriously wrong thing, but the Debian OpenSSL maintainer would rather mindlessly eliminate the valgrind warnings than actually think about the reasons for those warnings.

(Oh, and you meant "UNinitialized" memory.)

Re:The big question is.. (0)

Anonymous Coward | more than 5 years ago | (#23392378)

unfortunately, the same instruction

MD_Update(&m,buf,j);

was used in the (unrelated) function ssleay_rand_add( ) and got commented out too.
which lead to the missing seed. sice it is the only instruction in ssleay_rand_add that evaluates the content of buf (which is the seed).

it is total unbelivable that this patch could ever pass a review. it is also total unbelivable
that the code was touched in the first place (the problem mentioned above could be solved by simply switching on -DPURIFY in CFLAGS).

since debian has an ugly history of not submitting patches upstream one can only hope this incedent teaches some people a lesson.

Re:The big question is.. (1)

mikael (484) | more than 5 years ago | (#23392182)

I can imagine the packager thinking, "Why would a encryption software module need the user to swizzle the mouse around a bit? Must be a piece of test code - I'll #ifdef it out, and if anyone complains, I'll remove the #ifdef's again."

Ubuntu Gutsy already updated... (3, Insightful)

psyopper (1135153) | more than 5 years ago | (#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.

I see problems on Gutsy with mine. (1)

khasim (1285) | more than 5 years ago | (#23391980)

Preparing to replace openssh-server 1:4.6p1-5ubuntu0.2 (using .../openssh-server_1%3a4.6p1-5ubuntu0.3_i386.deb) ...
Template #4 in /var/lib/dpkg/tmp.ci/templates has a duplicate field "template" with new value "ssh/vulnerable_host_keys". Probably two templates are not properly separated by a lone newline.
dpkg: error processing /var/cache/apt/archives/openssh-server_1%3a4.6p1-5ubuntu0.3_i386.deb (--unpack):
  subprocess pre-installation script returned error exit status 255

And then:
openssh-server: Depends: openssh-client (= 1:4.6p1-5ubuntu0.2) but 1:4.6p1-5ubuntu0.3 is installed

Anyone else seeing this?

Re:Ubuntu Gutsy already updated... (1)

gumpish (682245) | more than 5 years ago | (#23392172)

Your packages may have been updated, but that doesn't mean your weak keys are.

Sadly it seems that the tool provided in the Debian mailing list post is only useful for detecting weak keys which are 1024 or 2048 bits. Guess I have to scrap all of mine...

OSS, only as good as the last developer? (5, Insightful)

MosesJones (55544) | more than 5 years ago | (#23391944)

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.

Re:OSS, only as good as the last developer? (4, Funny)

Anonymous Coward | more than 5 years ago | (#23392052)

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

I give anyone who touches my package 5 stars!!!

Re:OSS, only as good as the last developer? (1)

cdrguru (88047) | more than 5 years ago | (#23392210)

Yes, FOSS is subject to the "last person that broke it" problem. Unfortunately, the real problem is there are a limited number of people that really understand the code but lots of people that have access to it. Access that, as this proves, can be used to corrupt an otherwise working system.

The problem with reviewing the last modifier for a package is there is no way to know if that last change interacts with some other package. If this change was actually required for OpenSSL to work with some other (modified) Debian package it would not be possible to know this in advance. At least with the current structure of things. I would say this is where the real problem lies - you can always back out modified packages back to the "original" version as long it doesn't break anything else.

Re:OSS, only as good as the last developer? (1)

maxume (22995) | more than 5 years ago | (#23392252)

How many OpenSSH keys have you generated on that particular box? How many dollars worth of transactions have you done over SSL connections?

Re:OSS, only as good as the last developer? (4, Insightful)

peragrin (659227) | more than 5 years ago | (#23392280)

Ah so if the same thing happened from MSFT but no one noticed it does that mean closed source is better.

No software is perfect. when F/OSS screws up everything including the exact versions of the software where the bug began, until it is fixed is known. You know what/where/when/how, and most of the time why it happened.

With closed source software your considered lucky if you get a patch in a timely fashion.

Personally i would rather know what happened and when too.

Re:OSS, only as good as the last developer? (1)

hackstraw (262471) | more than 5 years ago | (#23392310)

But the point here is that the freedom that OSS gives you does require you to trust the whole distribution chain.

Yeah, I just got blind-sided by a Debian developer at a party last week. He knocked me out cold, I can't trust any of them anymore.

That was sarcasm, dunno why.

Seriously, this was a BIG silly mistake by someone. Maybe someone was doing some testing and forgot to undo the testing code? I don't know.

But as far as this being some kind of universal distrust, even the king of trusts like Verisign and Microsoft were dinged when someone was able to get a java development cert that could have done anything. I don't remember the details, but it was very similar to this kind of incident.

I like debian, and I trust their package people as much or more than any other distro because they do a damn good job with their packages. I have a feeling this was some kind of mistake. I mean, nobody in their right mind would take out the entropy to seed generation to a security package. But for development reasons, sometimes its nice to have consistant seeds for testing (or similar).

Just in case, I'm pulling my tin foil hat so that its snug on my head.

Re:OSS, only as good as the last developer? (1, Interesting)

Peter H.S. (38077) | more than 5 years ago | (#23392322)

Having the code is great, but this makes me want to know much more about who last edited that code.
The great thing about the rpm package management system on Fedora and Red Hat is, that the source rpms always include the pristine, original sourcecode as provided by upstream. The rpm package of course also include separate patches and a .spec file that shows how the patches should be applied on the fly when the binary package is built.
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

Re:OSS, only as good as the last developer? (3, Insightful)

Hatta (162192) | more than 5 years ago | (#23392400)

It's debian. ALL your packages have been patched for debian. It's pretty much the only thing I don't like about debian, all the patching. You can get the original source, and you can get the patches, but yeah it would be nice if it were a little more transparent.

Don't we have a built-in utility for this? (0)

Anonymous Coward | more than 5 years ago | (#23391946)

Why are we not just using /dev/urandom for this, which is already seeded with random data?

Do we really need to reinvent the square wheel for every cryptographic program?

Of course... (1)

Oxy the moron (770724) | more than 5 years ago | (#23391956)

... this had to be discovered four days *after* I finished setting up my new Ubuntu 8.04 server... *grumble*

Re:Of course... (0, Troll)

Anonymous Coward | more than 5 years ago | (#23392004)

Yeah, and? What has that got to do with anything? Want some cheese to go with that whine?

Quit being a cry baby and run 'apt-get upgrade' already. It would have taken you less time than to come in here complain.

Re:Of course... (5, Insightful)

Oxy the moron (770724) | more than 5 years ago | (#23392072)

Quit being a cry baby and run 'apt-get upgrade' already. It would have taken you less time than to come in here complain.

... and regenerate all the keys, yes? It isn't quite as simple as you suggest...

"All OpenSSH and X.509 keys generated on such systems must be considered untrustworthy, regardless of the system on which they are used, even after the update has been applied."

What's the hurry? (5, Funny)

n0dna (939092) | more than 5 years ago | (#23391982)

It was accidentally introduced in 2006... so that's what, another 14 years before it gets moved into 'stable'?

*grin*

Yeah, that'll get people to switch... (1, Troll)

Sun.Jedi (1280674) | more than 5 years ago | (#23391988)

So this is how linux is going to replace Windows on the desktop? By creating custom functionality that break RFC and common sense? Some things [microsoft.com] never change, do they?

Servers, not desktops. (0)

Anonymous Coward | more than 5 years ago | (#23392432)

This isn't about "desktop linux", this is really a huge problem for server admins.

And what does kerberos have to do with anything?

How Frakin stupid can you be? (5, Funny)

nweaver (113078) | more than 5 years ago | (#23392024)

"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!!!!

Re:How Frakin stupid can you be? (4, Funny)

EricR86 (1144023) | more than 5 years ago | (#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? (5, Interesting)

Anonymous Coward | more than 5 years ago | (#23392068)

The seeding was removed and it wasn't noticed for TWO YEARS? In a distro as popular as Debian?

Strikes at the heart of the matter (-1, Troll)

Anonymous Coward | more than 5 years ago | (#23392088)

This is why I only use software that is cryptographically signed by Windows Update; that way there's someone to sue if critical security flaws are "updated" into my system. Laugh all you want at the Genuine Advantage, I think this story proves it exists.

Linux at its best... (0, Flamebait)

Bfaber (11252) | more than 5 years ago | (#23392124)

'Makes it appear to be run by a bunch of half-wits.. I don't understand any level of justification that would make anybody think it was wise to touch SSL in your own distribution.

Such bugs and the thread posted from debian discussions show how far linux has to go to really be viewed in any sort of professional light.

comics (5, Funny)

Anonymous Coward | more than 5 years ago | (#23392134)

http://www.random.org/analysis/dilbert.jpg
http://www.xkcd.com/221/

To non-IT people (2, Informative)

Thelasko (1196535) | more than 5 years ago | (#23392136)

This is on the SSH server side. If you are a casual desktop user, you don't have to do anything.

Re:To non-IT people (2, Informative)

maxume (22995) | more than 5 years ago | (#23392306)

It affects all https connections, even client https connections. They are probably transient enough to mitigate the issue, but they are impacted.

Re:To non-IT people (5, Insightful)

Sun.Jedi (1280674) | more than 5 years ago | (#23392356)

This is on the SSH server side. If you are a casual desktop user, you don't have to do anything.
Yes, a good observation for IM/Email/Youtube/Facebook crowd... but how many others ssh into their home machine? I'd wager the ability to ssh into a home box is one of the better perks to running linux@home.

Re:To non-IT people (4, Informative)

jdowland (764773) | more than 5 years ago | (#23392394)

Uhhm, no. If you generated a key using the affected packages (ssh-keygen), as a user, your key needs to be replaced.

who was it? (1, Insightful)

Anonymous Coward | more than 5 years ago | (#23392174)

Who was the member of the security services who acted as package maintainer?

I cannot believe that such a change would have gone by unnoticed if it had been properly documented, and I cannot believe anyone given the trust of the OpenSSL distribution would make such a mistake.

This was an intentional act of sabotage.

Question (-1, Troll)

Anonymous Coward | more than 5 years ago | (#23392232)

Wasn't FOSS suppose to prevent these types of problems in the first place?

Too early (5, Funny)

sakonofie (979872) | more than 5 years ago | (#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?"

Blame me! (1)

pacroon (846604) | more than 5 years ago | (#23392244)

I honestly don't think this is much more than a mistake, like one of those who surfaces every two years. I wouldn't go as far as blaming OSS or any other instance for that matter. No matter what you feel, you cannot deny that Debian usually has some of the most comprehensive focus on security in the scope of popular Linux Distributions.

A great filter (4, Insightful)

Free the Cowards (1280296) | more than 5 years ago | (#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?

Surely this is not the only source of entropy! (4, Interesting)

argent (18001) | more than 5 years ago | (#23392350)

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.

Lovely - if only I could update (0)

Anonymous Coward | more than 5 years ago | (#23392396)

I've been getting badsigs since last week every time I try to update Hardy. Looks like I'm not alone, judging by the forums.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...