●Stories
●Firehose
●All
●Popular
●Polls
●Software
●Thought Leadership
Submit
●
Login
●or
●
Sign up
●Topics:
●Devices
●Build
●Entertainment
●Technology
●Open Source
●Science
●YRO
●Follow us:
●RSS
●Facebook
●LinkedIn
●Twitter
●
Youtube
●
Mastodon
●Bluesky
Please create an account to participate in the Slashdot moderation system
Forgot your password?
Close
wnewsdaystalestupid
sightfulinterestingmaybe
cflamebaittrollredundantoverrated
vefunnyunderrated
podupeerror
×
668470
story
Posted
by
timothy
13, 2008 @11:01AM
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.
Related Links
4D Analogue of Megaminx Puzzle
Fedora 9 (Sulphur) Released
This discussion has been archived.
No new comments can be posted.
Load 500 More Comments
Full
Abbreviated
Hidden
/Sea
Score:
5
4
3
2
1
0
-1
More
Login
Forgot your password?
Close
Close
Log In/Create an Account
●
All
●
Insightful
●
Informative
●
Interesting
●
Funny
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
byspikedvodka ( 188722 ) writes:
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
twitter
facebook
byOmnifarious ( 11933 ) writes:
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?
Parent
twitter
facebook
bypenfold69 ( 471774 ) writes:
That's funny, I use the exact same seed on my luggage.
Parent
twitter
facebook
bymoderatorrater ( 1095745 ) writes:
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 securi
bymikael ( 484 ) writes:
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.
Parent
twitter
facebook
byYvanhoe ( 564877 ) writes:
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 !
byDekortage ( 697532 ) writes:
Exactly what I was thinking. But it could be interpreted multiple ways: (a) it was criminals; (b) it was terrorists; (c) it was Microsoft.
Parent
twitter
facebook
byYvanhoe ( 564877 ) writes:
How is that mutually exclusive ?
Parent
twitter
facebook
byKent Recal ( 714863 ) writes:
Can someone explain what "guessable" means in this context?
Does that mean someone can now generate a "master-key" and ssh into root@any-debian-box that allows public key authentication?
What does a realistic attack scenario look like?
byYvanhoe ( 564877 ) writes:
From what I undestood, with my limited cryptographic knowledge and my total reluctance to dig into all the details of the sources, what happens is that when you asked your debian box to generate a key, it did so without integrating enough random data in its choice. That means that a brute force attack will not have to try every key to find yours but only a small subset, depending on the knowledge it has about your machine and its state when it generated the keys.
There is no such thing as a master key, but it would mean that several different servers may have generated the same "random" keys and that a clever attacker could create a dictionary of plausible keys (or, more plausibly, an algorithm to generate them) and try all of them on your server with a good chance to have one of them working. The dictionary would probably be huge however. A good measure would be to block an IP on SSH after a reasonnable number of failures (like 100)
Parent
twitter
facebook
bykensan ( 682362 ) writes:
The original change was tracked in the debian Bugtracking system at:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516 [debian.org]
The offending patch: http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141&view=diff&r1=141&r2=140&p1=openssl/trunk/rand/md_rand.c&p2=/openssl/trunk/rand/md_rand.c [debian.org]
The fix:
http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/crypto/rand/md_rand.c?rev=300&view=diff&r1=300&r2=299&p1=openssl/trunk/crypto/rand/md_rand.c&p2=/openssl/trunk/crypto/rand/md_rand.c [debian.org]
Parent
twitter
facebook
bySiliconEntity ( 448450 ) writes:
The patch that broke it was checked in by Kurt Roeckx [kroeckx@debian.org]. Don't know if he broke it or if he was just the gatekeeper for checkins. See:
http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141&view=diff&r1=141&r2=140&p1=openssl/trunk/rand/md_rand.c&p2=/openssl/trunk/rand/md_rand.c [debian.org] which shows the change that introduced the bug; and its parent node:
http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/?rev=141#dirlist [debian.org] which shows the maintainer responsible.
From looking at this patch, I think this is what happened. valgrind complained about a rather unusual coding convention in ssleay_rand_bytes. This is a function that returns random data into a buffer. However, before writing into the buffer, it reads from the buffer and incorporates the old contents into the internal random state. valgrind complained about this use of an output buffer for input. Normally you would never want to use potentially uninitialized data like this, but in this case it is OK as all that is being done is the data is being folded into the random state. In the worst case, this can't hurt, and maybe it will help, if the old data had some randomness.
Anyway, valgrind complained about it, and the maintainer commented out the use of the buffer. That would actually be OK, it is not a big deal. But the implementor made a mistake, and also commented out another similar usage, in a different function, ssleay_rand_add. This was a huge mistake, as the purpose of ssleay_rand_add is to add randomness into the random state. In that function, buf is an INPUT buffer, and adding it into the random state is perfectly legitimate, in fact it is the whole purpose of the function. But apparently because it looked similar to the questionable usage in ssleay_rand_bytes, the maintainer commented out the code in ssleay_rand_add at the same time. (I don't know whether valgrind also complained about this second usage, but if so, it was mistaken. I think it's more likely that the maintainer just got fooled and over-generalized from the valgrind complaint.)
So the whole thing was an attempt to clean up code and remove warnings, but the fix accidentally broke a crucial piece of functionality, rendering ssleay_rand_add completely non-functional. So any attempt to add randomness into the RNG state, such as for seeding purposes, is ineffective. The random state ends up with much less variability, and therefore all the crypto is weak. As Bruce Schneier points out, bad crypto looks much the same as good crypto, so it took this long to notice it.
Hats off to the reviewer who picked up on the problem. Don't know who it was, but the same Kurt Roeckx [kroeckx@debian.org] checked in the fix.
Parent
twitter
facebook
byivanjager ( 820414 ) writes:
Wow, that was still a really stupid patch. There was an #ifndef PURIFY there for a reason. It's because the openssl authors knew that line would cause trouble in a memory debuger like Purify or Valgrind. http://en.wikipedia.org/wiki/IBM_Rational_Purify [wikipedia.org]
Seriously guys, take a few minutes to understand the code before hacking on it. If it was written by a n00b, you need to understand it to make sure they didn't do other stuff wrong. If it was written by someone competent (which is probably the case for openssl), then you need to make sure you're not the one making the mistake. In this case, to make it work with valgrind, the patch should have been to debian/rules, simply changing the way Configure was called.
Parent
twitter
facebook
byAnonymous Coward writes:
Lesson#1: It's best to not change code you do not understand without getting it reviewed by people who (are supposed to) understand the code.
Lesson#2: If you write code that deliberately does weird things like wanting to read unitialised memory, PUT A COMMENT so that people other than you have a fighting chance with your code.
Parent
twitter
facebook
byJohn Meacham ( 1112 ) writes:
doh! posted the wrong URL
http://securepoint.com/lists/html/bugtraq/2007-02/msg00056.html [securepoint.com]
bybk2204 ( 310841 ) writes:
It's not seeding too often that's the problem, it's seeding with predictable data and expecting that data to be random. The time is very predictable, and contains very little entropy (randomness).
If you seed very often with data containing a lot of entropy (for example, radioactive decay), then there's no problem. It's also not a problem to add the time in the mix if you mark it as having almost no entropy.
Parent
twitter
facebook
byAnonymous Coward writes:
Ubuntu got an updated advisory at http://www.ubuntu.com/usn/usn-612-2
twitter
facebook
byAnonymous Coward writes:
Linky link link: Updated Advisory with instructions [ubuntu.com]
Parent
twitter
facebook
byIdaho ( 12907 ) writes:
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?"
twitter
facebook
bysciencewhiz ( 448595 ) writes:
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]
Parent
twitter
facebook
by0xABADC0DA ( 867955 ) writes:
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.
Parent
twitter
facebook
byGoaway ( 82658 ) writes:
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.
Parent
twitter
facebook
byIkeTo ( 27776 ) writes:
I think the problem is not the removal of the use of uninitialized memory as source of randomness. Instead it is the wrong way it is done, removing nearly all sources of randomness as a result. By the way, the fixed package still don't use the uninitialized memory as source of randomness.
Parent
twitter
facebook
bypsyopper ( 1135153 ) writes:
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.
twitter
facebook
byMosesJones ( 55544 ) writes:
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.
twitter
facebook
byAnonymous Coward writes:
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!!!
Parent
twitter
facebook
byperagrin ( 659227 ) writes:
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.
Parent
twitter
facebook
byHatta ( 162192 ) writes:
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.
Parent
twitter
facebook
byGraftweed ( 742763 ) writes:
Agreed.
The parent asked how can we be sure we're using the real OpenSSL? Simple, just use a distro that maintains a policy of minimal interference with upstream code. Slackware comes to mind, and not much else unfortunately.
Any distro that's liberal about patching upstream code is liable to suffer from security issues, as just exemplified by this story, and also to reduce the value of bug reports to the upstream projects, since they have to go through an extra triage to make sure the bug isn't specific
byatomic-penguin ( 100835 ) writes:
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.
Yeah, source debs have that too.
Parent
twitter
facebook
byn0dna ( 939092 ) writes:
It was accidentally introduced in 2006... so that's what, another 14 years before it gets moved into 'stable'?
*grin*
twitter
facebook
bynweaver ( 113078 ) writes:
"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!!!!
twitter
facebook
byEricR86 ( 1144023 ) writes:
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.
Parent
twitter
facebook
bysoliptic ( 665417 ) writes:
One of the OpenSSL developers [links.org] (or at least, that's what I infer) puts it in even more general terms:
never fix a bug you don't understand.
However, I can't help wondering if some fault may arguably lie with the OpenSSL coders. I mean... by his own admission:
Usually it is bad to have any kind of dependency on uninitialised memory, but OpenSSL happens to include a rare case when its OK...
(Emphasis mine)
So, since it's unusually doing something that looks an awful lot like a Cardinal Sin, did this block of code include a prominent:
/*
NB: Yes, we are reading unitialised memory
This is deliberate, NOT A BUG!
<explanation here>
*/
I mean, if you're going to write code that basically looks like a duck, walks like a duck and quacks like a duck, and which you know is
byAnonymous Coward writes:
The seeding was removed and it wasn't noticed for TWO YEARS? In a distro as popular as Debian?
twitter
facebook
byjrothwell97 ( 968062 ) writes:
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.
Parent
twitter
facebook
byFree the Cowards ( 1280296 ) writes:
Bugs with differing severities have different priorities, though.
If 99.9% of client code works, then an obscure bug in BSD directory traversal code is pretty unimportant. It won't affect most people, so it won't be found by most people.
This kind of bug, on the other hand, severely harms the security of everyone using this distro. It's tricky because it's hard to tell the difference between good crypto and crypto which has a critical flaw at the beginning which makes it insecure, which is why it lasted for so long before being found. But still, one would think that crypto software would get more attention and that someone would have noticed that every affected machine is spitting out nearly identical keys.
Parent
twitter
facebook
byChemisor ( 97276 ) writes:
Open Source programmers are getting older, and many eyes are getting blurry.
byAnonymous Coward writes:
http://www.random.org/analysis/dilbert.jpg
http://www.xkcd.com/221/
twitter
facebook
bysakonofie ( 979872 ) writes:
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?"
twitter
facebook
byFree the Cowards ( 1280296 ) writes:
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?
twitter
facebook
byFree the Cowards ( 1280296 ) writes:
Your SSL-enabled web sites spent two years being vulnerable to masquerade or man-in-the-middle attacks. Your SSH servers spent two years being vulnerable to same. Your SSH key pairs spent two years being easily crackable by anyone who happened to notice this vulnerability but didn't tell the world. I'm not entirely sure, but I think that SSL and SSH sessions either to or from the affected OSes may be crackable, and if so this would include traffic that was recorded at any time during the vulnerable period and can now be analyzed using knowledge of this bug to find out what data they carried.
This is a big deal. Maybe it doesn't affect you very much. It doesn't affect me at all, I've never run these distros. But you can bet right now that there are a lot of heavy Linux users out there going through a lot of trouble. This is going to be a bonanza for certificate authorities as everyone who generated SSL keys with these distros is going to need to purchase a new cert.
Parent
twitter
facebook
byargent ( 18001 ) writes:
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.
twitter
facebook
byChris Burke ( 6130 ) writes:
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.
Parent
twitter
facebook
bymmontour ( 2208 ) writes:
Why not just use /dev/random and stop the stupid games with reinventing the wheel?
Probably because the rate at which it dribbles out random bits is too slow for most real-world applications (unless you happen to have it hooked up to a hardware RNG).
byewhac ( 5844 ) writes:
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
twitter
facebook
bymulti io ( 640409 ) writes:
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.
Parent
twitter
facebook
byAnimats ( 122034 ) writes:
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
twitter
facebook
bymulti io ( 640409 ) writes:
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.
twitter
facebook
bymulti io ( 640409 ) writes:
From the same script:
Note that the blacklist by dowkd may be incomplete; it is only intended as a quick check.
With a statement as vague as that, there could be several orders of magnitude more potential keys.
I have an affected system here, and when I use its ssh-keygen to generate a few hundred keys, the script reports them all as "weak"[1], i.e. they are all in that set of 262,000. Looks like the script is at least quite good at what it does, and/or if there are more potential keys, they are rarely generated? When I do the same on a Fedora box here, none of them are reported, as expected.
260,000 would be bad though. At one test per second, that's just over 3 days. Of course, if you blacklist hosts after a certain number of failed authorization attempts, you can greatly increase the difficulty of exhausting the keyspace for a potential cracker.
...unless the attacker can obtain the public key directly, which he should be able to do frequently (it's called "public key" for a reason). For example, you can query a host for its public host (SSH) key without a problem. So, unless I'm missing something, you could just obtain that key and match it locally against those 262,000 keys (takes a minute at most, if you have all those keys) in order to find out the private key.
[1]
$ for i in `seq 1 500`; do ssh-keygen -N '' -t rsa -f key$i; done
$ ./dowkd.pl file key*.pub | grep 'weak key' | wc -l
500
$
Parent
twitter
facebook
bygQuigs ( 913879 ) writes:
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.
Parent
twitter
facebook
byimbaczek ( 690596 ) writes:
Not entirely true. Keys generated before the patch made it to the repos are safe - and I think quite a lot of debian boxes are old enough (I know I've got one.) There's a link in the advisory to a tool that checks if the keys are vulnerable.
This doesn't change the fact that this is a really serious fuckup. Debian lost quite some credibility in my eyes.
Parent
twitter
facebook
byAaron Denney ( 123626 ) writes:
Actually, any DSA key *used* on a box with the bad SSL packages may be compromised:
From http://wiki.debian.org/SSLkeys
Additionally, some DSA keys may be compromised in the following situations:
* key generated with broken openssl = bad
* key generated with good openssl and used to ssh from a machine with bad ssl = bad
* key generated with good openssl and used to ssh from a machine with good ssl = good
This is because the random numbers used during the signature process must also be good.
Parent
twitter
facebook
byKrischi ( 61667 ) writes:
It is even worse than this. Passwords that were used on a server with a weak DSA key may be compromised, as well:
From http://wiki.debian.org/SSLkeys [debian.org]
Parent
twitter
facebook
byAigariusDebian ( 721386 ) writes:
I cann't claim to 100% understand the situation but after glancing trough the logs of the discussions and of the patches the conclusion I came to was this - OpenSSL used supposed randomness of the uninitialized memory as an added source of entropy (interesting hack, but not an example of good coding as such). Valgring caught that problem and the Debian maintainer during a cleanup fixed it. Making such a fix can be considered a preventive step against possible attack vectors by poisoning the uninitialized memory. He took it up to upstream, they did not raise red flags, but did not quite merge the âclean upâ(TM) patch either. It fell through the cracks.
The problem is that in the same file, in another function all other sources of entropy were being merged into the pool of randomness using exactly the same code line as the one code line flagged by Valgrind. The maintainer assumed that the second code line has a similar function to the first and commented that one as well. AFAIK that also did not show up in the emails to the upstream list.
So we have:
* Upstream using clever hacks that rely on uninitialized memory having some randomness to it
* Upstream using same code and same variable names to describe different things
* Upstream having no comments in the code explaining the two things above
* Maintainer slightly over-generalizing a change
* A bug slipping trough the cracks in the review processes
* Another Debian Developer discovering the bug and recognizing its significance despite all of the above
* Debian project coming out and admitting all of the above and scrambling to get fixes out to its users ASAP
I am impressed by the swift action of the people involved in fixing this. And while I think everyone can find some lesson be learned here, I think this is another good example of free software in action. And I hope that in the aftermath of this we will find ways to prevent this from happening in the future without stifling our progress.
http://www.aigarius.com/blog/2008/05/14/too-similar-to-be-different/ [aigarius.com]
Parent
twitter
facebook
bytruthsearch ( 249536 ) writes:
My wifes ssh key is "Debian compromised".
Talk about an easy key to guess! At least throw in some numbers or something. ;)
Parent
twitter
facebook
bydotancohen ( 1015143 ) writes:
My wifes ssh key is "Debian compromised"
Say thank you that your wife is at least that far. If I dare say ssh in the wife's presence, I get a vase thrown at me and she screams for meto shut the fuck up.
Parent
twitter
facebook
byBooRolla ( 824295 ) writes:
Don't go bragging. A lot of people know the key to rooting your wife's box.
Parent
twitter
facebook
byan.echte.trilingue ( 1063180 ) writes:
I am going to hijack this thread because I have an eCommerce site hosted on Debian and this made me nervous.
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.
Parent
twitter
facebook
byMysteray ( 713473 ) writes:
https/ssl/tls/ssh etc use the certificates to agree on a conventional "session key" every time you connect. Session keys are typically chosen with strong random numbers... but if either the client or server is using the OpenSSL from Debian Etch, there's nearly no randomness in it.
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.
Parent
twitter
facebook
byJackieBrown ( 987087 ) writes:
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?)
byMSG ( 12810 ) writes:
I think the point was that if the Debian maintainer had submitted his patch upstream, he'd have been told exactly how stupid it was.
Parent
twitter
facebook
byMikeyO ( 99577 ) writes:
I think the point was that if the Debian maintainer had submitted his patch upstream, he'd have been told exactly how stupid it was.
Actually, here [marc.info] is where the Debian maintainer brought this up with upstream, and he was not told how stupid it was, in fact the Debian maintainer says, "the pool might receive less entropy." and upstream says, "If it helps with debugging, I'm in favor of removing them."
Parent
twitter
facebook
byIamTheRealMike ( 537420 ) writes:
The problem is that the email is rather misleading, from what I understand. It talks about two places causing the problem even though only one of them actually was making valgrind complain (and you can see, purify already picked up on the problem some time before). The trick is that his patch, not included in the email, removed both calls. Which was busted. So if he'd actually sent a full patch, proposed it for inclusion and had it properly code reviewed, the mistake would probably have been caught.
Parent
twitter
facebook
byIamTheRealMike ( 537420 ) writes:
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.
Parent
twitter
facebook
byIamTheRealMike ( 537420 ) writes:
No, he posted a question openssl-dev, which is a mailing list for people writing software that uses OpenSSL. This OpenSSL developer doesn't read it [links.org] and that's similar with most open source project - developers often don't read mailing lists for end users.
What's more, that mail doesn't contain a patch. It contains a misleading question with two lines posted in isolation. An actual patch, submitted for an actual code review, would almost certainly have revealed the problem via context.
You don't change crypto code of all things based on an idle question on a mailing list populated mostly by users. What's next, changing the kernel scheduler based on a conversation in #kernel-newbies?
Parent
twitter
facebook
bynoahm ( 4459 ) writes:
No, he posted a question openssl-dev, which is a mailing list for people writing software that uses OpenSSL
Incorrect, no matter what Ben claims. According to http://www.openssl.org/support/ [openssl.org], openssl-dev isfor the developers of openssl itself. To quote the list description:
Discussions on development of the OpenSSL library. Not for application development questions!
So yes, perhaps Kurt could have been more explicit in his description of what he was trying to do, but he was definitely using the appropriate address to reach the developers.
noah
Parent
twitter
facebook
bySiliconEntity ( 448450 ) writes:
According to http://www.openssl.org/support/ [openssl.org], openssl-dev is for the developers of openssl itself. To quote the list description: Discussions on development of the OpenSSL library. Not for application development questions!
Right, and further, one of the participants in the discussion was Ulf Moeller, who is one of the main crypto developers in OpenSSL. Unfortunately nobody apparently bothered to check whether the two lines proposed for removal were both involved in this questionable behavior of folding uninitialized data into the random state. Actually, only one of them was being used that way, the other was adding very important data to the random state. The OpenSSL people never caught the fact that the proposed change to the two lines was going to kill the security of the system, even though they had all the information available to do so.
Parent
twitter
facebook
byArchangel Michael ( 180766 ) writes:
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).
Parent
twitter
facebook
byDeanalator ( 806515 ) writes:
From this log: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516 [debian.org]
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.
Parent
twitter
facebook
byhackstraw ( 262471 ) writes:
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.
If you look further down the code, it then fills up the buffer with stuff from some random device (/dev/random /dev/urandom, or other things found in ./configure).
AFAIK, all modern Linux implementations have /dev/urandom and isn't that enough entropy for a seed?
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.
Parent
twitter
facebook
byannodomini ( 544503 ) writes:
No, I don't think you're quite correct. The original patch in that thread is not what actually was applied. There are two functions, one for seeding the pseudo-random number generator, and one for getting random data out of it. The one for getting random data out was actually mixing in some uninitialized data into the entropy pool. This is not particularly harmful, but not particularly helpful either, and it caused Valgrind to complain. So, the maintainer removed that line, but also removed the line that mixes in the value provided to seed the random number in the first place (maybe it was being called with unitialized data at some point, too).
See my comment here for more details: http://reddit.com/info/6j7a9/comments/c03zxko [reddit.com]
Parent
twitter
facebook
byeean ( 177028 ) writes:
Check out this bug report and tell me they weren't just being arrogant:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516 [debian.org]
Says the first comment to the patch, in regards to what is being reversed:
"What it's doing is adding uninitialised numbers to the pool to create random numbers."
OpenSSL having more-random numbers vs. Valgrind looking good. And Valgrind won?
The consensus in the bug report seems to be not to do it, but then someone adds the patch anyways.
Parent
twitter
facebook
byeean ( 177028 ) writes:
Ben Laurie of OpenSSL/Apache puts it into some context:
http://www.links.org/?p=327#comment-176642 [links.org]
Obviously some of the OpenSSL devs probably should've been like "zOMG, SITUATION FUBAR", but it wasn't a formal code review being requested, more of a "hey, what do you think of this and this?" and the patch was never submitted to upstream.
Parent
twitter
facebook
byprofplump ( 309017 ) writes:
It's not arrogance. Or it's at least not arrogance alone. As a distro maintainer I can tell you that upstream providers generally do not care about distro-specific patches. Even if you have a patch that would be useful on more than on distro, there's often a reluctance to inherit code to support any installation method other than source tarballs.
That's not to say that upstream providers are unduly arrogant either -- if you're happy with the way your build/install system works, why would you want to maintain patches for some other system that you don't even use? It's extra code to keep up, and requires more testing on more platforms, and it it doesn't make your core package any better.
Parent
twitter
facebook
byrhavenn ( 97211 ) writes:
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.
Parent
twitter
facebook
byFree the Cowards ( 1280296 ) writes:
This has been explained elsethread, but just in case anyone wanders into this one....
The problem is not the fact that the uninitialized memory seeding was removed. The problem is that the removal was done in an incompetent and destructive manner. Rather than remove only the uninitialized memory seeding, the maintainer managed to remove all seeding.
Reading uninitialized memory as part of random seeding isn't very useful but it's not bad either, since at worst the data is predictable, and OpenSSL mixes it with lots of other randomness. But when you botch your change and completely destroy any randomness present in the system, this is not the fault of the software you were trying to "fix".
Parent
twitter
facebook
byOmnifarious ( 11933 ) writes:
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].
Parent
twitter
facebook
byzooblethorpe ( 686757 ) writes:
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."
I, on the other hand, strongly suspect that any similar mistake at a major software corporation would in all probability be quietly ignored, if it were even noticed at all -- and if it were instead deemed enough of a public relations risk to warrant dealing with, the company would likely just silently push an update to correct the problem for future users, leaving anyone using extant keys with their arses hanging in the breeze.
But maybe I'm just being overly cynical. :-\
Cheers,
Parent
twitter
facebook
by2short ( 466733 ) writes:
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.
Parent
twitter
facebook
byfwarren ( 579763 ) writes:
I guess the real question is how many compromised keys are out there?
Most users do not generate nor use ssh/ssl keys or certificates.
The real questions are
●How many clueless users are actively using these keys/ceritificates?
●How many cluefull users are using these keys and think they are not an issue or that their keys are ok and won't fix it?
●How many cluefull users are going to fix their keys/certificates?
●Is someone able to develop a workable exploit?
●Will it be worth anyones time with a working exploit to scan the internet for compressible systems?
Parent
twitter
facebook
byAnonymous Coward writes:
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.
Parent
twitter
facebook
byJellybob ( 597204 ) writes:
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.
Parent
twitter
facebook
byzooblethorpe ( 686757 ) writes:
And we were told this sort of bug could NEVER happen in an open source operating system. Seriously, this is a major cockup.
First off, we were not told any such thing -- or at least I've never run across any such claims myself. Secondly, this would actually seem to substantiate the many-eyes theory, as the bug was found and summarily corrected, rather than never found, or found and swept under the rug, or found first by black-hats and exploited, all of which seem quite common in the proprietary software world.
The many-eyes model does not guarantee zero bugs, nor does it guarantee speedy bug hunting. However, it would seem to guarantee that bugs will be found eventually, and also that they will be dealt with in some productive way once they are found. This model aims for the opposite of security through obscurity, that hoary old chestnut of proprietary development, by instead ensuring security by knowing exactly what things do. That also means that folks need to go through all changes -- i.e., many eyes actually need to go over the code. Open source ensures that this is possible, but actual people still need to put in the time and effort.
Cheers,
Parent
twitter
facebook
byn0dna ( 939092 ) writes:
http://en.wikipedia.org/wiki/Linus's_law [wikipedia.org]
I understand he's not unheard of in this arena.
byclang_jangle ( 975789 ) writes:
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...
Parent
twitter
facebook
byOxy the moron ( 770724 ) writes:
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."
Parent
twitter
facebook
bytravalas ( 853279 ) writes:
On ubuntu.... according to the vulnerability description..
Once the update is applied, weak user keys will be automatically rejected where possible (though they cannot be detected in all cases). If you are using such keys for user authentication, they will immediately stop working and will need to be replaced (see step 3). OpenSSH host keys can be automatically regenerated when the OpenSSH security update is applied. The update will prompt for confirmation before taking this step.
bygoofy183 ( 451746 ) writes:
But that doesn't fix all of the machines that my public key (generated on Ubuntu) resides on that do not run Ubuntu. So yes fixing Ubuntu machines is easy, it is a PITA to have to go and re-upload my public key to all of these hosts.
Parent
twitter
facebook
byJust Some Guy ( 3352 ) writes:
So yes fixing Ubuntu machines is easy, it is a PITA to have to go and re-upload my public key to all of these hosts.
Especially when they won't work anymore [ubuntu.com]:
Once the update is applied, weak user keys will be automatically rejected where possible (though they cannot be detected in all cases). If you are using such keys for user authentication, they will immediately stop working and will need to be replaced (see step 3).
The GP poster said the same thing, but this is for the benefit of other readers who were skeptical that any such policy was in place.
So, basically, once you upgrade, you'll have no apparent way to access your other machines [1] to upload your new key. That's just spiffy!
[1] Uninstall openssh-blacklist first.
Parent
twitter
facebook
byAnonymous Coward writes:
This has nothing to do with the vulnerability being discussed here.
bysumdumass ( 711423 ) writes:
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.
Parent
twitter
facebook
bySun.Jedi ( 1280674 ) writes:
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.
Parent
twitter
facebook
byjdowland ( 764773 ) writes:
Uhhm, no. If you generated a key using the affected packages (ssh-keygen), as a user, your key needs to be replaced.
Parent
twitter
facebook
byledow ( 319597 ) writes:
Hello troll,
You have no recourse unless you have PAID to have one, like with almost everything else in the world. The GPL specifically states that it's not a warranty or guarantee that things will work.
However, if you were using it in a business, I would hope that you either a) hired your own programmers to work with the code or b) bought a support package/liability clause from someone like Red Hat. In which case it would be down to your programmers or Red Hat respectively. But we're not talking about Red Hat. Or any of the other big-name, support-contract-and-some-sort-of-indemnity-clause-included distros. They don't have this problem, presumably because they are not that stupid.
We're talking about Debian. Got a support contract / liability agreement with Debian? No? Bad luck. It's a bit like asking Microsoft to accept responsibility for your pirate copy of Windows, then, isn't it?
Parent
twitter
facebook
byMinwee ( 522556 ) writes:
It's a bit like asking Microsoft to accept responsibility for your pirate copy of Windows, then, isn't it?
Or a bit like asking Microsoft to accept responsibility for the copy of Windows that you paid for.
Look through the Windows license agreement some time and see how many times phrases like "THERE IS NO WARRANTY OR CONDITION OF ANY KIND", "YOU ARE NOT ENTITLED TO ANY DAMAGES" and "IN NO EVENT SHALL MICROSOFT OR ITS SUPPLIERS BE LIABLE" show up.
The only difference with Microsoft is that if Windows breaks you don't get to keep both pieces.
Parent
twitter
facebook
byFranTaylor ( 164577 ) writes:
Read the end-user agreements for your commercial software and you will see that you have no right to sue them for anything beyond the purchase price of the software.
byExperiment 626 ( 698257 ) writes:
So who's accountable for damages as a direct result of such a problem? If I were using such software to run my business, and this sort of security problem became more than just a threat, what sort of recourse do I have? Which programmer do I get to sue?
As opposed to the closed source world? If a security bug were discovered in Windows, would Microsoft would compensate you for your damages instead of just disavow any liability in a EULA?
bygrumbel ( 592662 ) writes:
i thought that Debian had some kind of policies about testing each package before committing changes in testing/stable branches.
This is a common myth, but Debian doesn't do any explicit testing, they pack things into unstable and then just let them go into testing/stable if no bug reports come in. There is no standard code audit or anything going on.
Parent
twitter
facebook
byvrmlguy ( 120854 ) writes:
The problem is, OpenSSL needed a buffer in which to XOR several sources of randomness, including /dev/random. OpenSSL didn't bother initializing the buffer, because doing so just eats CPU cycles, and a possibly random buffer is marginally better than a non-random one. However, the Debian patch removed *all* of the randomness except for the PID, leaving the user with one of just 262148 (or so) distinct keypairs. The tool that checks if your keys have been conpromised has a list of all of those keypairs and checks if your keypair appears.
Parent
twitter
facebook
There may be more comments in this discussion. Without JavaScript enabled, you might want to turn on Classic Discussion System in your preferences instead.
●
390 commentsUS To Halt Offensive Cyber Operations Against Russia
●
272 comments'I Won't Connect My Dishwasher To Your Stupid Cloud'
●
243 comments'USB-A Isn't Going Anywhere, So Stop Removing the Port'
●
235 commentsShould We Sing the Praises of Agile, or Bury It?
●
209 commentsNew Book Argues Hybrid Schedules 'Don't Work', Return-to-Office Brings Motivation and Learning
Fedora 9 (Sulphur) Released
4D Analogue of Megaminx Puzzle
Slashdot Top Deals
Slashdot
Discussion
●
●
of loaded
●
Submit Story
It is much harder to find a job than to keep one.
●FAQ
●Story Archive
●Hall of Fame
●Advertising
●Terms
●Privacy Statement
●About
●Feedback
●Mobile View
●Blog
Do Not Sell or Share My Personal Information
Copyright © 2026 Slashdot Media. All Rights Reserved.
×
Close
Working...
Fedora 9 (Sulphur) Released
218 comments
4D Analogue of Megaminx Puzzle
80comments
Do Not Sell or Share My Personal Information
Copyright © 2026 Slashdot Media. All Rights Reserved.
×
Close
Working...