Slashdot Mirror
NSA Allegedly Exploited Heartbleed
squiggleslash writes: "One question arose almost immediately upon the exposure of Heartbleed, the now-infamous OpenSSL exploit that can leak confidential information and even private keys to the Internet: Did the NSA know about it, and did they exploit if so? The answer, according to Bloomberg, is 'Yes.' 'The agency found the Heartbeat glitch shortly after its introduction, according to one of the people familiar with the matter, and it became a basic part of the agency's toolkit for stealing account passwords and other common tasks.'"
The NSA has denied this report. Nobody will believe them, but it's still a good idea to take it with a grain of salt until actual evidence is provided. CloudFlare did some testing and found it extremely difficult to extract private SSL keys. In fact, they weren't able to do it, though they stop short of claiming it's impossible. Dan Kaminsky has a post explaining the circumstances that led to Heartbleed, and today's xkcd has the "for dummies" depiction of how it works. Reader Goonie argues that the whole situation was a failure of risk analysis by the OpenSSL developers.
Why even have the same agency responsible for foreign electronic intelligence and put them in charge of "cyberdefence" (how I hate that term..).
It's a massive conflict of interest. You're virtually begging them to find and then sit on dangerous exploits.
YOU SON OF A BITCH
I can understand this happening. It would make sense that the NSA would have someone or multiple people review every patch and check-in for a package as important as OpenSSH, just looking for exploitable mistakes.
I would not be surprised if they review a great deal of FOSS software they deem important to national security.
Wax on, wax off baby!
The basic fact is, if they did not exploit it, then someone working for them is thinking "DAMN, I wish I thought of using that!"
excitingthingstodo.blogspot.com
it's a (NSA) feature...
Even if it's not an NSA feature...of course the knew about it! They would have to be even more incompetent than we think not to. They are HUGE, with something like 40,000 employees. At least of few of those employees must be dedicated to code review of OSS looking for vulnerabilities, and more in general looking for vulnerabilities in any widely used software. And if that's the case, then you'd think OpenSSL would be one of the first things they'd look at. The fact that they didn't tell anyone though shows that the S is NSA is bullshit. They cared more about being able to exploit the vulnerability themselves than making their country's computers more secure. If they cared one shit about their country's security then they'd have big teams dedicated to finding software vulnerabilities and working with vendors to fix them.
The author of this bug and the reviewer of the commit have both been very forthcoming about the mistake. There's little reason to suspect malicious intent in this particular instance.
That doesn't mean the NSA didn't know about it or exploit it, though.
#DeleteChrome
Glad you asked: it happens all the time, ever since the Tort Claims Act of 1948 substantially waived the sovereign immunity doctrine. You can read more about it at Wikipedia.
People sue the government all the time. It's literally an everyday occurrence.
OK guys. We've promoted Open Source for decades. We have to own up to our own problems.
This was a failure in the Open Source process. It is just as likely to happen to closed source software, and more likely to go unrevealed if it does, which is why we aren't already having our heads handed to us.
But we need to look at whether Open Source projects should be providing the world's security without any significant funding to do so.
Bruce Perens.
Theo de Raadt should fork OpenSSL. He could call it OpenOpenSSL.
.
Trolling is a art,
Bloomberg is the reporting organization, so they can't bee the source. They name no sources, just "two people familiar with the matter", which could mean they asked me twice.
Maybe, of course we cannot just believe them after seeing them repeatedly lying to Congress, but it strikes me likely in this particular case they are telling the truth. This bug, unless I am misunderstanding, essentially lets you read from a small contiguous pseudo-random block of memory. That's obviously not acceptable from a defender point of view - it could potentially expose any and all information so it's a severe flaw - but from an attackers point of view it seems less impressive.
You could probably try this thousands of times without actually obtaining any information of value. Sure, you might luck out and get the keys to the kingdom, but it seems like a crapshoot. From an attackers point of view, this might be better than nothing, but unless they have pretty near nothing to start from, it does not seem exciting.
And we know they have a lot more than nothing to start from. With Total Surveillance in effect on the net, with rootkits and zero-day exploits to deliver them, it's just really hard to see how this would add anything substantial to their toolkit.
No, I suspect this is exactly what it appears to be - a critical bug resulting from too much emphasis on fast and not enough on good. That's hardly unique to OpenSSL, it's a chronic problem across the industry as a whole.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Actually I wrote this yesterday but was unable to publish it:
...
I have not yet grasped the full scope of the implications of this bug, but if you take the stance that things that could have been done also has been done (imho the only safe assumption), is this a good characterization? Or are there any limiting factors that makes this impossible? Like for example the amount of memory that could be leaked while the application is running (as servers aren't restarted often) is certain information that is stored statically in memory potentially not reachable?
During the last two years:
1. Any/all certificates used by servers running openssl 1.0.1 might have been compromized and should be revoked (the big cert-reset of 2014?)
2. Because of 1, any/all data sent over a connection to such servers might now be know by a bad MITM (i.e. for large scale: the various security services/hostile ISPs, local scale/targeted attacks: depends on who else happened to know, and this person/organization happened to be your adversary, looks unlikely, but who knows...)
3. Any/all data stored in SSL-based client applications might have been compromised.
From a users perspective - change all passwords/keys that has been used on applications based on openSSL-1.0.1? How to know what services? To be safe, change them all? Consider private data potentially sent over SSL to be open and readable by the security services?
Thinking about the large-scale:
For how long has the NSA been picking up information leaked by Heartbleed (assuming that they have at least since late evening the 7:th or early morning the 8:th seems a given)?
-Not in the Snowden documents that has been revealed so far (absence of proof != proof of absence, but language might give a hint)
-No report of unusual heartbeat streams being spotted in the wild (was anyone looking?)
Let's assume for the sake of argument the NSA does not have people actually writing the OpenSSL code in the first place.
When did they know about it's existence?
time_to_find_bug = budget * complexity_of_bug / size_of_sourcecode * complexity_of_sourcecode * intention_to_find_bugs
Where
budget = manpower * skillset
and
time_to_find_bug < inf.
when
skillset >= complexity_of_bug
Heartbeat bug:
complexity_of_bug = low
OpenSSL:
size_of_sourcecode = 376409 lines of code (1.0.1 beta1)
complexity_of_sourcecode = high
NSA:
intention_to_find_bugs = 1
budget = $20 * 10^9 ?
=> manpower = 30k ?
skillset = high
Guesstimate: one to a few months -> early 2012 to go through the changes made to 1.0.1 building on earlier work already done on the 0.8.9 branch...
...
Or to say it another way, I think it is safe to assume that, given the simplicity of the bug, NSA knew about Heartbleed in early on. The anonymous comments to Bloomberg gives nice confirmation of this.
Welp, that didn't take long. Looks like someone solved CloudFlare's Heartbleed Challenge and got their private server key...
Just a minor correction - my piece does indeed suggest that the OpenSSL developers have some strange priorities. However, it lays the larger blame at the companies that used OpenSSL, when all the information necessary to suggest that this kind of thing could happen was already available, and the potential consequences for larger companies of a breach are easily enough to justify throwing a little money at the problem (which could have been used any number of ways to help prevent this).
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
I challenge anybody to review it and find (or notice) the bug.
It's actually kind of easy to see. I just use the same trick I use when trying to read almost anyone's code: I assume that some jackass obfuscated all of his variable names and so I rename them as I figure out what they actually represent so that the new names actually describe the variable. Once that's complete, I'm left with "memcpy(pointer_to_the_response_packet_we_are_constructing, pointer_to_some_bytes_in_the_packet_we_received, some_number_we_read_out_of_the_packet_we_received)" and it immediately raises a red flag.
I've read that the reason there's a packet length sent from the remote host is because this data is sent with random padding bytes added to each packet and so the packets need to indicate how much of the data is actually valid. So why isn't the packet size figured out closer to when the data first enters the program? First thing I would do when receiving a packet is read out this packet size, verify that the actual size of received packet is large enough to contain it, and toss the packet if it wasn't large enough since it was obviously corrupted (or malicious). Then I'd write the size into a structure for the packet's meta-data, along with any other data we find in every packet (like a packet type number), and every other part of the entire program would read the data from that structure. That's how you do these things. Everything received is "tainted" and, once you verify it isn't poisonous, you move it out into a data structure that the rest of your program trusts. Otherwise you have every piece of code that needs that data having to verify it every time it accesses it which just creates enormous opportunity for error.
So when you come across code like this which pulls data out of the packet and just uses it, it isn't just wrong, but it doesn't even resemble anything that might be correct. Thus, the poor variable naming just might be why this wasn't noticed. Since the data pulled out of the packet is stored into a variable named "payload" it's easy to imagine it's simply payload data, which doesn't have to be checked as it won't ever be used for anything other than being returned to the remote host, and so the absence of code that checks the validity of that data might be expected. If it were named even something as ambiguous as "payload_size" then you have to immediately wonder if it's a size that needs to be checked against anything when you see it being pulled out of a buffer of untrusted data. ...but then, you don't see that either, since the pointer is named "p" which doesn't scream "this is untrusted data" and, even if you look above to see that "p" was assigned from "&s->s3->rrec.data[0]" you're still left wondering what the fuck that might be. Maybe "rrec" refers to some sort of received record? Fuck, who knows.
I mean, right after the memcpy I see "RAND_pseudo_bytes(p, padding)." Is this even putting the padding bytes in the correct place? Well, "p" could be a pointer to anything so it's pretty easy to assume it could be correct. Hel
CloudFlare has retracted their statement that private key compromise is very hard. They started a challenge and at least 2 people successfully got private keys from their Heartbleed-enabled server with as few as 100K requests. (I am sure that with some optimization, the number could be even lower.)