Worried OpenSSL uses NSA-tainted crypto? This BUG has got your back As fears grow that US and UK spies have deliberately hamstrung key components in today's encryption systems, users of OpenSSL can certainly relax about one thing. It has been revealed that the cryptography toolkit – used by reams of software from web browsers for HTTPS to SSH for secure terminals – is not using the discredited …
Definitely. Who validates your validators?
How the f*** did it pass validation if it was producing the same output all the time. I bet the "validators" were chuckling madly allong while drafting the validation report.
For me this is the best confirmation so far on the efforts to cripple the Internet as we know it by Комитет Государственной Безопасности.
If I knew how to do it, I'd verify that certain distros are actually affected by this bug and someone hasn't somehow inadvertently fixed it for binary release.
I wonder if there is a sufficiently sophisticated news outlet lying around, who could take this story to an Al fixated milliner's fulfilment?
Cheers
Jon
PS. RHEL/CentOS, SLES int al. would be a good start
To get FIPS support you need to either use a prebuilt "FIPS capable" version of OpenSSL, which few distros provide, or build it yourself, so the problem is largely moot.
The only prebuilt version I could find with FIPS support is openssl-0.9.8e-22.el5_8.3, which is specifically certified by NIST. An examination of the sources reveals no fips_drbg_ec.c patch at all, much less the patch in question ("t = s;"), and indeed that file is completely missing.
The same goes for Fedora, CentOS, Debian and Gentoo. I gave up checking after that.
It seems you have to go to some effort to let the NSA spy on you in this manner, and by all indications no one has yet done so.
I don't think most companies use FIPS 140-2 because they think it is a good idea. I think they use it because the US government mandates it for certain purposes. That makes the point having the certification and nobody gives a rat's ass about whether it works or how well it works. You used the government mandated and certified process so you're off the hook.
Yes, this use to irritate me quite a bit. But in my dotage my jaded is getting even more jaded.
That's not what the article said. The software works and complies with FIPS 140-2 so long as you use a different pseudo-random number generator. Since the software came with others, it worked.
While I agree it should not have been certified with that bug, that doesn't mean the whole thing is broken.
For some reason some people (especially older, non-tech savvy 60-something politicians) seem to think that it's fine to snoop and control online traffic, yet if you suggested that some secret agency should open everyone's letters and photocopy them and store them indefinitely in some giant filing system on the off chance you may have written something that might incriminate you, there'd be absolute uproar.
Unfortunately, I still think there is a generation of rather ill-informed people out there who just think "internet = bad and scary" and that it must be controlled, monitored and censored in a way that would be totally unacceptable in any traditional medium.
Note how these spying scandals really kicked off when people realised that they might be listening to telephone conversations (a traditional medium).
Unfortunately, I think all this has done is completely undermined people's ability to trust online communication security. We've enough problems dealing with hackers, credit card and identity theft online without having to also assume that several big brothers (some friendly and some not so friendly) are probably gobbling up anything of national commercial interest too.
Doesn't really leave a lot of scope for cloud computing with anything that might be sensitive intellectual property or business decisions that could be 'interesting' to a major world power.
The whole thing is a total mess and it seems everyone's now slurping data 'because they can' rather than thinking about what the consequences of that might be to the entire IT sector.
"if you suggested that some secret agency should open everyone's letters and photocopy them and store them indefinitely in some giant filing system on the off chance you may have written something that might incriminate you, there'd be absolute uproar."
Yet that is what is done, and has been done since at least the early 1980s when the NSA started opening ALL mail going across US borders. Meanwhile here in the UK the secret services have been copying all the letters printed in news papers from before I was born and almost certainly have had access to the NSA's data about postage from here to the States (at least). You can be sure that all the regular posters here have a file on them, together with their real names and email addresses for future reference.
People in power have one common goal: to stay in power. They don't even have to be bad people, just people with mortgages and kids and bills that their salary for being a member of the NSA or MI6 pays for; they don't want the budget cut - quite the opposite.
Of course, some of them ARE bad people and it's important that they are dug out and dealt with otherwise you end up with a situation like the Catholic priesthood or London's Met where the denial of anything being wrong makes the organization more and more attractive to criminals to join until almost the whole thing is rotten. I particularly remember some cardinal saying "it's not as if paedophiles would do seven years of seminary school just to get access to kids, is it?". Complacency like that is a gift that just keeps giving.
If you're going to use an analogy you need to use the right one. What they have admitted to gathering is the meta data. So the proper snail mail equivalent is "they scanned every destination and return address and put the information in a database along with a time stamp of when the letter was sent."
Frankly, in that context most people don't care. Same thing with the phone data. Most people don't care that someone knows when they call whom on their cell phones or land lines and when they do it. Maybe they should. But that's a difficult argument to win in an age where most people post their month long vacation plans on social networks and tweet it to the world.
This discovery actually puts a dent in the theory that the NSA were relying on this weak random number generator to crack SSL encrypted traffic. If they had been so reliant, they would have spotted early on that OpenSSL implementations weren't vunerable despite including the flawed generator. Yet they never reported the bug to OpenSSL, even though we are told it should have been in their interests to do so.
So can we conclude that either the NSA have more than one 'backdoor' into SSL and so they didn't need Dual EC DRBG working in OpenSSL, or the rumours about them exploiting Dual EC weren't true to begin with?
The Snowdon leaks have played into the NSA's hands in one respect, if terrorist feel they cannot trust the internet they'll go back to the old method of using trusted couriers to communicate and that is great news for spies. They can't simultaneously watch all internet cafes, hotels, libraries and other locations of public internet access to follow subjects back to their hiding places, but they can follow a man from A to B. It's a cheap, reliable and very well rehearsed bit of spy craft, they were doing it throughout the cold war.
Exactly - if the OpenSSL function had been a problem then if would have been fixed since it's widely used. So it's safe to assume that it's not a big problem for the NSA to crack the other algorithms.
Don't write anything you can phone. Don't phone anything you can talk. Don't talk anything you can whisper. Don't whisper anything you can smile. Don't smile anything you can nod. Don't nod anything you can wink. - Earl K. Long
No, it's not. One of the spy agencies has as it's motto "The truth shall set you free." The truth is, if you understand the maths you will know whether or not there is an issue. If you don't you won't.
I happen to fall into the "you won't" category. Assuming most of the security guys outside the NSA aren't on an NSA black ops payroll, it sounds like it is borked. But I don't know that to the point I'd claim it as a known fact.
But you can't play psychological games with these guys. Because if they couldn't break the bit we're bitching about, and they could all the rest the best way to kill it all would be to convince people it was borked and they should stay away from it. And even if Snowden caught them off guard, they could be turning lemons into lemonade. Well, at least from their perspective.
Stay grounded in who you are and what you know. If you try to move into their territory you'll be lost in a maze of mirrors.
>So can we conclude that either the NSA have more than one 'backdoor' into SSL
SSL != OpenSSL. OpenSSL is not the only SSL/TLS library that exists.
>and so they didn't need Dual EC DRBG working in OpenSSL,
Or they weren't targeting OpenSSL.
>or the rumours about them exploiting Dual EC weren't true to begin with?
Or they weren't targeting OpenSSL.
Aha! But by knowing which SSL implementation was NOT compromised and keeping it secret, informed intelligence services and their friends no doubt believed they held a valuable "ace in the hole".
In other words I can spy on you, but you can't spy on me. Then I can transmit disinformation on a known compromised channel and fool ya into believing something that ain't true.
Somewhat inspired if double-think, bluffing and bald-faced lies are your stock in trade.
Not so much, if confidential data, trade secrets and IP are your stock in trade and you believed state-approved security standards would protect you from your competitors and criminal adversaries. Because now it looks not so much inspired as downright criminally irresponsable.
If state-sponsored, engineered vulnerabilities are indeed the new reality, then a very dangerous game of chicken will be continually played out between our fearless cyber-spies and lots of cyber-criminals. Our economic recovery and livelihood is the prize and it is currently trapped between these guys' headlights. Remember, when encryption is outlawed, only criminals (and spies) will have encryption.
IMHO, until someone takes away the car keys, revokes the players' driving licenses and puts the main race-organizers into the pokey this can only get worse.
Once these bad boys are contained, I then recommend universal driver safety courses and better-designed manufacturing standards for all of our data vehicles. Let's try improved privacy legislation, legislated data compartmentalization, default, mandatory anonymization of all data held by third parties, and ubiquitous encryption. We can start there and work our way down via public debate. Outlaw the trafficking or non-disclosure of vulnerabilities by State players so they can be part of the solution instead of the problem.
If Snowden releases many more gems like this one (and I believe he will), it is only a matter of time before an organization that has suffered some major financial grief from an "engineered vulnerability" (and can prove it) takes their case to court and seeks civil redress. The obvious defendants will be the agencies that enabled or devised these techniques and the companies that let their products be "enabled". Not sure that a free get-out-of-jail card will be enough to contain the inevitable legal sh*t storm that will ensue.
And don't forget the foreign companies subjected to state-enabled industrial espionage that will take their cases to the WTO.
And can someone please explain to me again why the terrorists are the ones threatening our way of life?
Or you could just make the data holders explicitly and irrevocably responsible for all economic damages incurred if the data leaks.
Which back in Jack and Jane land (instead of James Bond world) would probably would have helped Target avoid their most recent breach.
I'm surprised to see this many comments and nobody yet mentioned what leapt out at me as soon as I read the article.
Say you have a high-value exploit, and want to have it easy to turn on when you really need it, but difficult to detect until then. What better way that to do the "injection" and the "activation" in separate steps. That way, there is less chance of some nosy kids and their dog sniffing peculiar behavior and blowing the whistle before you have even selected your first high-value target.
Then later, a simple "one line" bug fix turns on the spigot.
RE: nobody yet mentioned what leapt out at me as soon as I read the article.
Same here, however what I noticed was that we have here a very interesting example of the realities around the practise of code review or not as the case may be.
It doesn't really matter how the bug got into the code, what is important is that it remained undetected by the wider community (I don't buy the conspiracy of silence), including those involved in the FIPS validation of OpenSSL for an extended period of time. If this can happen with a key component of an open source project, I wonder about what is lurking in other open source projects and more particularly all those closed source code bases - the products of which, the majority of IT users use everyday...
This is a trick question right?
Maybe because the fix is a one line change in the source code. After which it has to be compiled and distributed. Because if you're going to inject a segment of compiled code into the target system, that implies you've already got admin access to it. In which case there are probably far easier ways of getting the rest of the information you want.
Full disclosure: I haven't done any programming since I had that introductory PCI (PC/i?) class back in college. Before that I worked on TRS-80s. Unless you count some long but simple WordPerfect Macro stuff I did about 15 years ago, which I don't.
I apologize for use of double quotes
one can only guess how this "bug" was "missed", but the post above yours is as good an explanation as we're likely to get. See below:
bigtimehustler
Sounds to me like someone implemented this 'bug' on purpose so nothing actually used the selected crippled algorithm...
The thousand eyes protocol really does depend on the thousand eyes. First you sort out all the people who don't do math to begin with. Then you sort out the people who can't do basic algebra. Then you remove the ones who can't make it past geometry. Then trig, and calculus and probability and statistics and maybe some set theory.
What you are left with is a fairly small group of people. If they produce a proof which others accept as valid you wind up with an algorithm that programmers can implement without understanding. (For instance years ago I tried to get a handle on the microprocessor Two's Complement method of subtracting by adding. I could never quite do it. But with the process in hand I could replicate it whenever needed. I get that it works and somebody has done the proof, but I'll never understand it.) Now if the weakness is subtle and in the algorithm itself as opposed to a coding limitation, it probably won't get noticed.
Then you remove the ones who can't make it past geometry. Then trig, and calculus and probability and statistics and maybe some set theory.
I can't think of anything in OpenSSL that requires much knowledge of geometry, trigonometry, or calculus; and statistics would only be slightly useful, for things like checking PRNG distributions. It's all discrete mathematics. Still, I take your point: there aren't that many people who are capable of understanding both the code in question and the mathematics it implements, and fewer who also understand the security protocols it's meant to enforce (and the FIPS requirements that apply in this case), and fewer yet who are going to take the time.
All that said, there are some impressively dumb comments being made in this forum.
The "wider community" never noticed the bug because Dual EC DRBG isn't enabled by default, and clear has never been used by anyone with an unpatched OpenSSL-based implementation. If you build OpenSSL with Dual EC DRBG enabled and try to use it, you get errors from the engine (because the generator is "stuck").
As Marquess describes in his note, Dual EC DRBG was added at the request of a sponsor, and the request was granted because 1) it's a standard algorithm, 2) OpenSSL is a toolkit which contains many known-to-be-crap algorithms as well as the good stuff, and 3) because FIPS certification is expensive, it's customary to try to pack as much stuff in as possible, so you can certify everything in one go.
The bug is a bug. It's an easy mistake to make. There's no reason, aside from clownish conspiracy theorizing, to believe anyone added it (or subtracted it, really) deliberately.
FIPS certification doesn't involve testing every algorithm the module claims to support. Perhaps it should; perhaps the OpenSSL team should have tested the Dual EC DRBG implementation. (The test Marquess provides is simple, if you're already set up to build OpenSSL in FIPS-compliant mode.) But they focus on testing stuff that people actually use.
A slightly larger danger - maybe - is that someone altered the OpenSSL implementation (for a "private label" SSL/TLS implementation, i.e. OpenSSL provided under someone else's brand) to remove the "additional input" step of OpenSSL's Dual EC DRBG implementation. As Marquess notes, that would bypass the bug, and also make the generator vulnerable to duplicating state when an SSL-using process forked. It's possible there could be, say, a line of commodity devices with embedded SSL/TLS implementations based on OpenSSL with such a vulnerability, and whoever hacked away the additional-input logic would know about it, and know those devices might be coaxed into using Dual EC DRBG... But that's a rather specific and, I think, pretty unlikely scenario (not least because Dual EC DRBG has always been considered suspect and second-rate at best).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
