Alarming Open-Source Security Holes (key generation flaw leaves millions vulnerable)

Thanks for the explanation. Some folks do not fully understand the depths one has to go go even approximate randomness. Reminds me of some of the CS students I tried to teach - they thought “it’s already been done, so why learn the basics?”

I’ll call bull on that. I oversee a number of Admins.
I have one guy at a site managing over 70 W2K3 servers, and 1 guy looking after 5, FIVE! nix servers.

Take a guess which guy has the most issues, the most downtime and is the most difficult to deal with. We have been through numerous (and I mean numerous) Unix “Gurus” and the problems never seem to go away.

My CIO one afternoon once made it clear that if he ever saw a “free” piece of software in our environment again, well I like my job.

Also if you think that in the rest of the corporate world it’s any different, I know a ton of companies shoving “open source” software out into the trash as fast as they can.

One thing I’m curious about. If all the keys were generated from a fairly small subset, surely a certificate authority must have received requests from multiple entities to register the same key. I would have thought that would set off some alarm bells.

>> Rather than strive to figure out why the code would have contained such things, he merely commented them out to quiet the bug-catcher software.

> Sounds like the original author didn't document his code well enough.

I'd be inclined to agree, but I haven't seen the code myself so I can't really say for sure.

IMO, if the offending programmer at Debian was inside a module that he or she didn't understand, they should have passed their comments or criticisms back up to the OpenSSL group with a "WTF does this do??"

That would have solved it. However, I have heard rumors that there's ongoing feuding between Debian developers and others, such that the Debian group doesn't talk to anybody else.

If so, that's extremely unfortunate, witness this.

I'm having to crawl through my entire organization, since some of our people use Ubuntu (affected by this), and may have generated bad keys that have been copied between other systems (Unix, other Linux, Windows, Mac, etc.) over a period of two years. It's a bloody nightmare.

Reminds me of some of the CS students I tried to teach - they thought “it’s already been done, so why learn the basics?”

The proper answer would be: Yes it's been done. Probably many times properly, but even more times wrongly. You'd best find out the right way to do it, and you'll probably find it easier to learn than discover.

Some folks do not fully understand the depths one has to go go even approximate randomness.

I'm not a programmer, but it seems to me that making anything random in a program would be nearly impossible, since everything the computer does comes from an instruction it's given. How do you tell a computer to do ANYTHING at random?

You need to come to my world.

We’re getting ready to replace VMS (a whole ‘nother story) and according to the two Linux proponents at work, it is the savior of all mankind. It never breaks, it’s easy to administer, security is very easy to administrate, exploits are easily patches, etc.

I’m not saying I disagree or agree, but we are talking about what will be a production critical system. I’d like people to be a bit more objective and thoughtful about the OS and what it will take to maintain - that’s hardly possible when one is accused of being a Linux hater, blah, blah, blah when questions about job scheduler/batcher and the like are raised.

Oh I feel so sorry for you. Tell the Linux guys to “take a walk”, or make sure you are prepared for a whole new set of issues.

I’ve seen Linux guys totally confused when it comes to simple things like Hardware Raid, changing one piece of hardware (kernel panic time)or even something as simple as a server restore issue.

Yes I know Linux guys out there will tell me I’ve always hired the wrong guy, but when you’ve been through 10 of them and the one windows guys is still going strong, I’ve got real issues.

“”I’ve seen Linux guys totally confused when it comes to simple things like Hardware Raid, changing one piece of hardware (kernel panic time)or even something as simple as a server restore issue.””

I have no idea who interviews the people you hire-

But obviously these Unix/linux guys are losers..except for
fooling your company to hire them-

a suggestion.. work with a known good unix company to maintain your systems- hire them (short or long term contract) have them interview or recommend an admin for you.

Yep tried that as well. LOL.

It all comes down to the fact that Linux really is not ready for prime time. There are out-standing stability issues, lack of commercial tools to support it and generally a multitude of thought on “best practice”.

The biggest issue is the support that is required just to “make it work”. I can have a Windows box up and running in less than 3 hours, a Linux box, not so much.

I not a Windows fanboy, far from it, I’ve been in the IT industry for over 20 yrs and have worked with pretty well all there is to work with. However, at this point of my life, I really don’t want to play around and promise my bosses that an opsys can do a job that it is just not cabable of doing.

Take for example file and print sharing. If anyone can convince me that Linux can do it better than Windows, I’ll gladly switch. However when I can train a help desk person in five minutes on Windows, you got a lot of convincing to do.

I'm not a programmer, but it seems to me that making anything random in a program would be nearly impossible, since everything the computer does comes from an instruction it's given. How do you tell a computer to do ANYTHING at random?

Good question. Most techniques to generate an initial random number rely on some real world phenomenon which has some component of randomness. For example, one of the techniques used in the initial SSL code was apparently to measure the time between successive actions by the user, probably at a very high time resolution. That value will be quite variable, and can be used to generate a random value

For example, the time between keystrokes from a user typing their name isn't really random. But if you measured it in microseconds, it is likely that the last digit of the time would be a pretty good random value. If you made a 32 digit number out of the last digit of the times between the last 32 keystrokes that the user typed in it would be a pretty good random number.

(Note to the programmers reading this. Obviously my example is simplified, and I know about problems like hardware interfaces that change the timing of the user events, kernel synchronization issues, etc.)

I'm not a programmer, but it seems to me that making anything random in a program would be nearly impossible, since everything the computer does comes from an instruction it's given. How do you tell a computer to do ANYTHING at random?

There are three general approaches I've seen used:

Use hardware which is designed to produce randomness. There are many physical processes which are, over moderate timespans, essentially random. Unfortunately, many of them are only useful for generating randomness at moderate speeds.
Look at the state of uninitialized hardware. A lot of 1980's video games did this, but it's really not a good approach on modern machines. Among other things, a lot of today's hardware doesn't start up nearly as randomly as hardware in the past.
Observe some process to a level of detail that is somewhat unpredictable, e.g. counting the number of milliseconds between keystrokes. This approach is good, to a point, but there are limits as to how quickly it can generate good randomness.

If one has a procedure to generate a vaguely-randomish bit, it's possible to feed the bits into a hashing function such that there is no meaningful correlation between the input and output bit sequences. The tricky part then is figuring out how much input one has to put in to get a certain amount of randomness out.

Suppose that a particular randomish function will, 90% of the time return the same value as it did the previous time. In that case, there's an 81% probability that the two bits following a particular "0" will be "00"; an 9% probability that they'll be "01", a 9% probability that they'll be "11", and a 1% probability that they'll be "10". Someone who knows what the hash would return with a value of "00" would be able to guess the output of the hash 81% of the time (simply by guessing the generator will in fact produce "00"). Generating more bits will help things somewhat, but if one feeds 8 bits into that method the probability of them being "00000000" is about 43%. Pretty good odds for an attacker who should face a 1/256 chance.

On the other hand, if one adds enough bits into the hash, even using the bad generation function, the probability of a successful attack drifts into the noise level. If one feeds the hash with 1,000 such bits, for example, the probability of picking all zeroes drops to one in 10^46. Even though the input suffered from a strong correlation bias, feeding enough input into the hash function will cause it to be diluted.

If one only needs a few random numbers, and one doesn't need them very fast, it's easy to generate numbers that are, for all practical purposes, completely random, such that no person with any amount of knowledge of anything and everything other than the generator's concealed state would have reason to regard any particular value as being more probable than any other; knowledge of previous output values, or even reasonably-accurate (but not totally accurate) knowledge of the input values, would be useless toward guessing the output.

Unfortunately, generating good random numbers more quickly is difficult. Grabbing numbers from the hash function more quickly is easy, but knowing whether they're random enough is hard. If I'm generating a 128-bit session key, I would like to ensure that no particular key value will appear with a probability over, say, 2^96. Ideally they'd all appear with probability 2^128, but 2^96 is still perfectly good. If I feed 1,000 bits into my generator, I'll be fine even if the inputs suffer from 90% correlation. If I feed in 10,000 bits I'll be fine even if they suffer from 99% correlation. On the other hand, having to take in 10,000 input bits to generate a 128-bit key could be rather a nuisance. What's tough is knowing how many bits are required to achieve a particular level of randomness; knowing that requires knowing a lot about the character of the input data stream.

If you made a 32 digit number out of the last digit of the times between the last 32 keystrokes that the user typed in it would be a pretty good random number.

Actually, you probably won't.

On the other hand, if you have an 8-byte buffer, and every time a user types a keystroke you XOR the lower word of that buffer with a high-resolution keystroke timer and then DES-encrypt the buffer with some arbitrary key, then after a thousand keystrokes or so the buffer will probably be, for all practical purposes, random. If not after one thousand keystrokes, then almost certainly after 10,000.

Individual keystroke timing by have a strong correlation bias with regard to earlier keystroke, but DES-encrypting after each keystroke will allow each keystroke to affect the results independently; the amount of entropy will thus continue to increase asymptotically toward pure randomness. What's tough is knowing when enough randomness has been injected into a system for it to safely be called "random".

Bookmarking for later

As I noted in my disclaimer, my example was intended to illustrate the principle, not propose an actual algorithm.

That said, if you have a system which allows actual measurement of the times of human input events at high enough resolution, then you can always choose a timing interval short enough so that some number of bits of the timing result (the number depends on resolution of the timer) are uncorrelated to the human's response time, and therefor generate a random number.

Practical issues of how actual computer input device interfaces work make this technique not as useful as other techniques, like the ones you outlined, but, for example if you set up a high speed oscillator and a counter, and count the number of nanoseconds between two keystrokes or button presses by a user, you'll see plenty of correlation in the millisecond range, but very little to none in the micro and nanosecond range.

I'm not a programmer, but it seems to me that making anything random in a program would be nearly impossible, since everything the computer does comes from an instruction it's given. How do you tell a computer to do ANYTHING at random?

The proper term is "pseudo-random number generator," rather than "random number generator." You're right, there's no way that a computer can come up with a completely random sequence of numbers. But instead, the idea is to come up with a sequence of numbers that's so large that when it eventually does repeat, the members of the sequence is so large that it appears to be random, and uses factors such as mouse position, values in certain memory locations, date and time, etc...

The only "real" random number generator that I'm aware of is based on the radioactive decay of an isotope.

Mark

The biggest issue is the support that is required just to “make it work”. I can have a Windows box up and running in less than 3 hours, a Linux box, not so much.”

I can have my Ubuntu 8.04 with a clean install up and running in an hour.

ROTFLMAO!!!

Geez, I thought open source meant “thousands of programmers” would review the source code and therefore the source code would be secure. WHAT A GAFF!

In a production server environment?