After Debian's epic SSL blunder, a world of hurt for security pros
Admins: Heal thy certificates
SaaS data loss: The problem you didn’t know you had
It's been more than a week since Debian patched a massive security hole in the library the operating system uses to create cryptographic keys for securing email, websites and administrative servers. Now the hard work begins, as legions of admins are saddled with the odious task of regenerating keys too numerous for anyone to estimate.
The flaw in Debian's random number generator means that OpenSSL keys generated over the past 20 months are so predictable that an attacker can correctly guess them in a matter of hours. Not exactly a comforting thought when considering the keys in many cases are the only thing guarding an organization's most precious assets. Obtain the key and you gain instant access to trusted administrative accounts and the ability to spoof or spy on sensitive email and web servers.
Security pros have rightfully reacted swiftly to word of Debian debacle. But if you think last week's patch is like most other security fixes, you're dead wrong. Installing it is probably the easiest part of mopping up the resulting mess. Once it's installed, admins will be forced to search sometimes sprawling systems for every key that's ever interacted with the buggy version of Debian and a host of other OSes and applications that relied on it.
Certificates for defective keys will have to be revoked, new keys will have to be generated and, in the case of SSL certificates, registered with VeriSign or another certificate authority. No one knows how many keys need to be replaced, but it could number in the hundreds of thousands or millions. The keys are used for Secure Sockets Layer (SSL) transactions, which authenticate servers handling trusted websites and email, and to authenticate Secure Shell (SSH), which provides encrypted channels between sensitive computers.
The heft and tedium of tracking down, testing and regenerating so many keys, and the cost of paying certificate authorities to register them, has left some people feeling pessimistic about the prospects the problem will be fixed anytime soon.
"There's the pain-in-the-ass factor and then there's the cost factor," says Jacob Appelbaum, an independent security researcher, as he ticks off the reasons he believes organizations will be slow to tackle the problem. Sure, some will make an earnest effort, but "even those people are going to be overwhelmed and patch a lot of their systems but not all of them," he adds.
Next page: Weakened White House
COMMENTS
Oh Entropy
Well of course you want the source of randomness to be random - and it is not that hard.
I hazily recall having to bash away at the keyboard; in some quasi finger dance to different melodies mixed by a DJ with no concept of the fade buttons.
And having to quaff a few pints (actual number of pints and music listened to not revealed, so as to reduce chance of replay attack), in the spirit of entropy creation.
Oh, those were the days.
Debugging Randomizers
I do think someone above, should perhaps revisit their maths' books.
Take a dice roll, roll that dice once and we would say that the dice had a 1 in 3 chance of being a a 3 or 4.
But roll that dice a million times, and you will find that the average of the rolls tends to 3.5.
Now, every roll of the dice is random and you cannot predict what will be shown, but to test if something is random, you can run a basic test like this, and on average you will also see that the numbers selected are all fairly evenly spread, as long as the sample set is large.
If the numbers are not evenly spread, then your random system is not that random.
Sure there is a chance that a random system will return always the same number, but I personally would not use such a system, and in fact a sequence of +1 would be more secure than a random system that returned the same number each time.
And using uninitialized memory is not secure from being gamed either.
@anonymous coward
"See, opensource is great, but we are giving it lip service in many areas, and I personally would like to see some commercial benefit for developers of opensource code, ie. I think that monetary recompense to the developer for code, would actually create better opensource applications, and that's what we should be working on."
The overwhelming majority of work on open source software (OSS) is paid work, as demonstrated by extensive automated analysis of contributions to Linux based on source code line-count and copyright signoff, see
http://lwn.net/Articles/222773/
The motivations for creating software are various. In my case this research supports teaching I am paid for. Some software creation is motivated by the sale of packages which might be harmed by opensourcing them, but package sales are a minority interest amongst programmers.
When looking at the benefits of OSS to its creators the greatest is the reduction in transaction costs in a world where a useful system has to be integrated from contributions by hundreds of thousands of programmers working for tens of thousands of independent organisations, for which sale of the software could never be our main line of business because the transaction costs would be greater than the sales value.
Creators of this code do want your lip service to support our viral method of distribution, but we value your custom when you buy one of our courses, consultancy services, software publications or hardware in which OSS is embedded or which is sold on the back of OSS even more. If you can help identify and fix a bug or contribute a useful patch that works for you and which benefits you by having it included in the upstream version even better.
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Enabling efficient data center monitoring
