Debian Bug Leaves Private SSL/SSH Keys Guessable 670
SecurityBob writes "Debian package maintainers tend to very often modify the source code of the package they are maintaining so that it better fits into the distribution itself. However, most of the time, their changes are not sent back to upstream for validation, which might cause some tension between upstream developers and Debian packagers. Today, a critical security advisory has been released: a Debian packager modified the source code of OpenSSL back in 2006 so as to remove the seeding of OpenSSL random number generator, which in turns makes cryptographic key material generated on a Debian system guessable. The solution? Upgrade OpenSSL and re-generate all your SSH and SSL keys. This problem not only affects Debian, but also all its derivatives, such as Ubuntu." Reader RichiH also points to Debian's announcement and Ubuntu's announcement.
stupid stupid stupid (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:5, Funny)
Re: (Score:3, Interesting)
The point is that encryption, proper randomization, etc are HARD and prone to a lot of errors. That's why you commit changes upstream, so that the people who did the work in the first place are able to review the change and let you know if you changed something vital to the securi
Re:stupid stupid stupid (Score:5, Interesting)
Re: (Score:3, Interesting)
Planting a vulnerability that has gone undiscovered for 2 years and that gave the keys to a lot of SSH servers. Genius !
Re:stupid stupid stupid (Score:5, Funny)
Exactly what I was thinking. But it could be interpreted multiple ways: (a) it was criminals; (b) it was terrorists; (c) it was Microsoft.
Re:stupid stupid stupid (Score:5, Funny)
What does "guessable" mean here? (Score:3, Insightful)
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?
Re:What does "guessable" mean here? (Score:5, Informative)
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)
Re:stupid stupid stupid (Score:5, Informative)
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]
Re:stupid stupid stupid (Score:5, Informative)
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.
Re:stupid stupid stupid (Score:5, Informative)
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.
Re:stupid stupid stupid (Score:5, Insightful)
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.
Re: (Score:3, Informative)
http://securepoint.com/lists/html/bugtraq/2007-02/msg00056.html [securepoint.com]
Re:stupid stupid stupid (Score:5, Informative)
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.
Updated advisory from Ubuntu (Score:5, Informative)
Re:Updated advisory from Ubuntu (Score:5, Informative)
The big question is.. (Score:5, Insightful)
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.. (Score:5, Informative)
Re:The big question is.. (Score:4, Insightful)
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.
Re:The big question is.. (Score:5, Informative)
Re:The big question is.. (Score:5, Informative)
Ubuntu Gutsy already updated... (Score:3, Insightful)
OSS, only as good as the last developer? (Score:5, Insightful)
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? (Score:4, Funny)
I give anyone who touches my package 5 stars!!!
Re:OSS, only as good as the last developer? (Score:5, Insightful)
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? (Score:4, Insightful)
Re: (Score:3, Insightful)
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
Re:OSS, only as good as the last developer? (Score:4, Insightful)
What's the hurry? (Score:5, Funny)
*grin*
How Frakin stupid can you be? (Score:5, Funny)
Re:How Frakin stupid can you be? (Score:5, Funny)
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.
Re: (Score:3, Insightful)
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
2 years? (Score:5, Interesting)
Re:2 years? (Score:5, Interesting)
Re:2 years? (Score:4, Insightful)
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.
Re: (Score:3, Funny)
comics (Score:5, Funny)
http://www.xkcd.com/221/
Too early (Score:5, Funny)
I wake up and what do I see first thing? That there is a problem with Debian's OpenSSH package and the
Now I am thinking, "What exactly is going on here? Is choking on a bucket of cocks not a good source of randomness?"
A great filter (Score:5, Insightful)
Re:A great filter (Score:5, Insightful)
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.
Surely this is not the only source of entropy! (Score:5, Interesting)
In fact I'd expect that separate runs of the same program with the same parameters and environment would leave the same junk on the stack every time.
So I would hope that they have some better source of entropy than unpredictable uninitialized data of dubious randomness.
So if this is really a serious problem, then it seems to me there's already a serious problem in OpenSSH.
Re:Surely this is not the only source of entropy! (Score:4, Insightful)
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.
Re: (Score:3, Insightful)
Degree of Compromise? (Score:5, Interesting)
Schwab
Re:Degree of Compromise? (Score:5, Informative)
Is it good enough now? (Score:3, Insightful)
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
262148 possible keypairs? (Score:5, Informative)
Re:262148 possible keypairs? (Score:4, Informative)
[1] ./dowkd.pl file key*.pub | grep 'weak key' | wc -l
$ for i in `seq 1 500`; do ssh-keygen -N '' -t rsa -f key$i; done
$
500
$
Re:It will be fixed (Score:5, Insightful)
Re:It will be fixed (Score:5, Informative)
This doesn't change the fact that this is a really serious fuckup. Debian lost quite some credibility in my eyes.
Re:It will be fixed (Score:5, Informative)
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.
Passwords may be compromised, too (Score:5, Informative)
From http://wiki.debian.org/SSLkeys [debian.org]
Re:It will be fixed (Score:5, Informative)
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]
Re:It will be fixed (Score:5, Funny)
Re:It will be fixed (Score:5, Funny)
Re:It will be fixed (Score:5, Funny)
I have an eCommerce site (Score:4, Interesting)
According to the reps at Thawte, if you are using a third party ssl cert (thawte, verisign, etc), this does not affect you. According to them, this is only dangerous for people who have generated their own SSL certs for their sites from the ground up (probably a minority, I would guess). If anybody has any information to the contrary, please let me know.
Re:I have an eCommerce site (Score:4, Interesting)
Even if your certs are fine, individual transactions are likely vulnerable.
If someone has taken packet captures, they will likely be able to decrypt them retro-actively.
Re: (Score:3, Interesting)
It seems more like an attempt to show that a maintainer was being petty which is not what the article was about.
Does anyone one really think that this change would have been accepted upstream (or even have had a place for it there?)
Re:It will be fixed (Score:5, Insightful)
Re:It will be fixed (Score:5, Informative)
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."
Re:It will be fixed (Score:5, Insightful)
Re:It will be fixed (Score:5, Interesting)
He would have been told, but who says he would have cared? This happens all the time, although usually it doesn't result in a giant fucking security hole. I was warning people this sort of thing would happen more than two years ago back when I was working on autopackage. It was entirely predictable.
Having distributors randomly change source code as they package it is fundamentally broken. It cannot ever work. It's not just OpenSSL that's been broken like this. Wine often went through periods in which the Debian packages were completely hosed in subtle ways. It would look like a bug in Wine, but was in fact due to parts of the software "going away", because the Debian packager felt they weren't important enough to be a part of the base install. Pointing out that their change was broken didn't help. The result was many, many hours wasted tracking down non-bugs. Then you go through a giant waste of time trying to get the bug in the packages fixed, and just as you finally get it sorted out, some other distribution introduces some other bug into their packages.
So I got sick of this, and started telling people to avoid their distros packages. Some distributors (especially Debian) took it personally and started childish slanging matches. But really, who cares how "integrated" a program is, if it could have had arbitrary bugs silently introduced? It's just a busted model of software distribution.
Imagine if Microsoft reserved the right to modify any software for Windows in any way it saw fit! Yet that's exactly what Debian (and Fedora and Mandrake and Ubuntu) said to me - they reserve the right to make any modifications they like to the software they ship, and if upstream don't like it, tough luck.
I wonder if they'll re-evaluate that policy in light of this disaster. Probably not.
Re:It will be fixed (Score:5, Insightful)
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?
Re:It will be fixed (Score:5, Informative)
Incorrect, no matter what Ben claims. 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!
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
Re:It will be fixed (Score:4, Informative)
Re:It will be fixed (Score:5, Insightful)
Debian people screwed up. This leaves a huge distaste in my mouth for Debian (and Ubuntu).
correct me if I'm wrong (Score:5, Interesting)
It looks like openssl is pulling in "entropy" from uninitialized memory, causing valigrind to complain. The debian maintainer "fixed" this issue by memsetting the buffer to zero.
My question is, wouldn't I see the same behavior using grsecurity to scrub deallocated memory? From what I am seeing, this looks much more like the fault of the openssl team.
Re:correct me if I'm wrong (Score:4, Interesting)
If you look further down the code, it then fills up the buffer with stuff from some random device (/dev/random
AFAIK, all modern Linux implementations have
I only spent a minute looking that the code and the diff in the parent's post, but this is looking not to be a bug to me. But, like I said that I didn't look at the code that long, but I don't see where memsetting the memory makes any difference if its all being overwritten.
Re:correct me if I'm wrong (Score:5, Informative)
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]
Re:It will be fixed (Score:5, Informative)
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.
Re:It will be fixed (Score:4, Informative)
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.
Re:It will be fixed (Score:4, Insightful)
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.
Re:It will be fixed (Score:5, Insightful)
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.
Re:The issue is a bit more complicated... (Score:4, Informative)
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".
Re:It will be fixed (Score:5, Informative)
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].
Don't underestimate corporate arse-covering (Score:5, Insightful)
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,
Re:It will be fixed (Score:5, Insightful)
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.
Re:It will be fixed (Score:4, Insightful)
Most users do not generate nor use ssh/ssl keys or certificates.
The real questions are
Re:It will be fixed (Score:4, Informative)
There most certainly is something to see here, this is kind of a big deal.
Re:It will be fixed (Score:5, Informative)
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.
Bug found & fixed -- "many eyes" seems to work (Score:4, Insightful)
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,
Re: (Score:3, Interesting)
I understand he's not unheard of in this arena.
Re:You stupid god damned open sourcers (Score:5, Insightful)
Yeah, like all those times when MS cut checks for all their customers whose computers were compromised! Oh, wait...
Re:Of course... (Score:5, Insightful)
... 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."
Re: (Score:3, Informative)
Re:Of course... (Score:5, Informative)
Re:Of course... (Score:5, Informative)
Especially when they won't work anymore [ubuntu.com]:
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.
Re: (Score:3, Informative)
Re:i wondered what was going on (Score:5, Informative)
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.
Re:To non-IT people (Score:5, Insightful)
Re:To non-IT people (Score:4, Informative)
Re:Why open source doesn't work for business (Score:4, Informative)
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?
Re:Why open source doesn't work for business (Score:4, Insightful)
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.
You are funny (Score:3, Insightful)
Re: (Score:3)
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?
Re:Kurt Roeckx (debian) mail to openssl-dev list (Score:4, Informative)
Re:Does SSH not use /dev/random? (Score:5, Informative)