Hacker News Reader

That's close but you actually want to change the size of your packet, not the size of the requested return data.

// Essentially OpenSSLs bug is the following buffer = malloc(payload_claimed) // we aren't going over these bounds // Later memcpy(buffer, your_actual_payload, payload_claimed) // we are going over your_actual_payloads bounds

By changing your actual payloads size you can influence what data we get. The payload claimed doesn't really matter, that's just the amount we copy starting from wherever our actual payload ends up so that should always be 65536 for best results.

Incidentally i got the following off the server (a payload size of 0x1D seems to hit it) but it doesn't seem to accept it as the real RSA key.

I wonder if someones spamming requests containing false keys to the server or if they've just stopped accepting answers.

Excuse the formatting above, it seems to have eaten my whitespace.

Just for further reference i recommend reading about OpenSSLs freelists implementation. Essentially if you have an object that uses a specific amount of space it will be stored in a specific location. Which is why private key extraction is possible. You just need to craft a request that puts your_actual_payload in a location so that the 65536 bytes that are read from it into a buffer also end up reading the key.

http://www.tedunangst.com/flak/post/analysis-of-openssl-free...

Doesn't seem to match https://gist.github.com/indutny/a11c2568533abcf8b9a1

How do you know when you've found a piece of a key?

store everything, reconstruct it all later by trying to work out which part of the heap each request is from. there is likely some sort of efficiency calculus you can do here (i'm not good at math so I have no idea what i'm talking about) where you could calculate for heap size x and probabilities y and z etc. just how many requests and what size they should be to cover the entire process heap.

edit: OpenSSL wraps malloc, so it is different on different systems. You could find out what the probabilities are by looking at the source. For some reason FreeBSD's malloc gave up private keys with the default exploit length and not much effort. It was only a matter of time before other platforms were also figured out.

Note that the FreeBSD exploit worked on a fresh server after boot, which might have also been the case here.

Note that in the heap there are the intermediate values that and are used when constructing the connection and doing the encryption, you aren't exactly looking for '------BEGIN PRIVATE KEY------' or base64 string, you'd be looking for those - each which have a unique data type.

> Note that in the heap there are the intermediate values that and are used when constructing the connection and doing the encryption, you aren't exactly looking for '------BEGIN PRIVATE KEY------' or base64 string, you'd be looking for those - each which have a unique data type.

That's what I thought as well when I saw people POSTing strings like that and other people finding them. But when the key is first loaded from file, wouldn't actually all those base64 strings be in memory?

Probably just pretty unlikely that they would persist for a long time without being overwritten.

It shouldn't be about it eventually being overwritten, sensitive information like that (which isn't needed for runtime) should be actively scrubbed before the block of memory is freed.

You can't, however, get away with not having the private key modulus in memory (in some form) all the time.

From a piece? Hard.

But brute force everything you get back? Easy.

Take every key-sized chunk of heap you got back, and see if, when interpreted as the key, it is the private key to the public cert. When found, send it in!

I would think that there could be some application of how genome sequencing is done? From what I understand chains of DNA are cut by restriction enzymes and these random chains are assembled together by some clever algorithms?

Depending on the nature of the strings, yes. If there is no repetition or errors in the representation of the sequence, you could use overlap layout consensus if it were small, or de-brujn or string graphs if it were large. For repetitive but error free sequences, de-brujn and string graph will do. For error-containing sequences, only the de-brujn graph (with the proviso that you'll reconstruct some false-positive sequences too).

Brute force is infeasible if you get random heap data along with key fragments. Based on the way the exploit works[0], my amateur guess would be they sent small payloads and actually did get SSLv3 records, because they found the right heap allocation strategy for a specific build on a specific platform.

[0] http://blog.existentialize.com/diagnosis-of-the-openssl-hear...

I get your point, but CloudFlare actually fixed that 7 days before the public disclosure, that is 12 days ago.

"We fixed the flaw on Monday March 31, 2014 for all CloudFlare customers, with public notification on Monday April 7, 2014, after the researchers' public announcement." -- https://support.cloudflare.com/hc/en-us/articles/201660084-U...

>we had the bug 16 days early, no we had the bug 18 days early

And we didn't know what to do about it...

CIA and FBI had knowledge of variations of this vulnerability nearly 10 years ago.

OpenSSL has been patching variations of this bug for that whole time, and every good hacker, (and the bad ones) have been exploiting OpenSSL since its creation.

https://www.openssl.org/news/secadv_20030930.txt

People act surprised, but OpenSSL has never had a secure release. Ever.

> CIA and FBI had knowledge of variations of this vulnerability nearly 10 years ago.

Source?

CIA and FBI servers are easy to find, and many run OpenSSL. Go see which ones have the vulnerability.

You won't find it on them. Their branch doesn't have the issue.

Also look through this http://web.nvd.nist.gov/view/vuln/search-results?query=opens...

You will see mentions of this bug in products that use OpenSSL quite often.

haven't seen a mention of it yet.

Do you have evidence of that being true a week ago? It's no surprise that the CIA and FBI would scramble to lock down vulnerabilities as soon as they were announced, but that's not proof that they never had them in the first place.

After the Snowden business, I wouldn't be hugely surprised if the gov't was secretly aware of Heartbleed, but I'm not comfortable taking a random stranger's word for it.

If the government was aware of Heartbleed,you can be sure that knowledge was buried deep in the NSA, not at your local FBI office. It is laughable to think the FBI knew about this.

The bug wasn't even implemented 10 years ago.

BS. Those bugs are completely unrelated.

If there is a common denomenator between all OpenSSL bugs in the last 10 years is that they often come from basic problems/difficulties with C (array out of bounds, length checks and such).

Which is what caused those particular vulnerabilities.

OpenSSL has been vulnerable as you state because it is C rather than managed code, and managing memory has never been one of the core teams strong suits.

I get the reason for using C, OpenSSL is probably the most performant SSL solutions available. It is much less resource intensive than say Polar. (NSS is getting there, but is not really a solution for embedded systems [routers and such])

>all OpenSSL bugs in the last 10 years is that they often come from basic problems/difficulties with C (array out of bounds, length checks and such)

When you have a means to over flow or retrieve memory you can get at data or execute code to give you data. Which is the bug that is causing heart bleed.

What is making heart bleed worse is that it goes back so many versions so for the first time in a long time there is a well known vulnerability that is the same on everyone who runs it.

It isn't a "worse" vulnerability it is a "more common one". Think of it like a Genetic defect. If 1 animal in 10 has it, the herd still has "herd immunity". Or the old "there are no viruses for mac" back when mac had like 2% of the market share so even when there were viruses they were hard to spread. We are now at a point everybody who wants to be malicious knows how to attack, and there are a lot of thing to attack, so more attackers will get "lucky" and find something interesting, especially since there will be so many servers that no one remember they need to track down and fix.

CIA and FBI had knowledge of variations of this vulnerability nearly 10 years ago.

This isn't true. Don't make things up - this bug is bad enough without misinformation.

OpenSSL has been patching variations of this bug for that whole time

Untrue. OpenSSL has been patching unrelated bugs since it was created (as has most software).

https://www.openssl.org/news/secadv_20030930.txt*

This is unrelated to heartbleed.

It is related in that there has never been a release of OpenSSL that was secure. Not one. Ever.
The known vulnerabilities list for OpenSSL has never had a release that didn't have a flaw that allowed some amount of "backdooring", Dataextraction, or data manipulation. (as opposed to just a path for a DoS attack)
>Don't make things up -
I don't have to make things up. The CIA and FBI keep a list of known vulnerabilities, publicly and not publicly documented. They use this information for doing investigations. I have personally run in to issues where I was contacted by FBI because we had created fixes for our deployments and they contacted us to "unfix" them, because their warrants were "no knock" and they didn't wish to tell us who they were attempting to do surveillance on.
Feel free to Google me (Brandon Wirtz) if you need some background on my credentials in the security space.
But thanks for jumping to I make stuff up. The mis-information that is out there is that OpenSSL has ever been secure.
I'm more sad nobody beyond XKCD did a good job explaining how the bug works, or doing the demonstration I like where you bash on the server and do data alignment to show a couple of gigs worth of data from a single server. People aren't scared enough of this stuff.
All those people saying "change your passwords on every site", but nobody is creating a huge public list of which sites are currently not patched.
so >bad enough without misinformation
No. People are too complacent and the OpenSource community doesn't own up to the things they let slip by. The "smart" guys at CDN's and Banks, were never at risk because they use proxies that have extremely short "memory life" because data is streaming through rather than stored (by the time you could get a second value to do finger printing everything would have changed), and are running NSS, or Matrix or Polar.
Hearbleed is an issue because too many people are too complacent, too trustworthy, and too uninformed.

Which kind of proxies? What are they using them actually?

Just one example, but this is a typical setup.
http://www.cisco.com/c/en/us/td/docs/interfaces_modules/serv...
I don't suggest doing the Clear Text between server and proxy, but the idea is the same. You use a proxy so that you don't ever have user names or passwords in memory longer than a few ms.
Once a user is authenticated data passes through quickly making it very very difficult to do a fingerprint match of the data you do extract.
Also because you can load balance across proxies you may not even hit the same machine with a second "hear beat".
The Cert still has to be there somewhere, so you could still end up giving up a cert, and you could give away anything that fits on a single HTML page as it is flying by in the stream... But most sites know better than to display a password, or a username and a bank account number at the same time (not all, but most).
Heart Bleed is more of an issue because too many people built monoliths, rather than compartmentalizing. The Titanic didn't sink because it was compartmentalized, it sank because the man at the Wheel didn't know to let one compartment take all of the force, and instead spread it over a larger surface.
Your proxy should be disposable. Nothing of value should be on the thing that talks to the user, and shouldn't retain data for any length of time.

This is a great example of why a little knowledge is a bad thing. It almost sounds like you know what you are talking about, which probably confuses people.
Heartbleed is dangerous because it exposes private keys, and that let's you decrypt SSL traffic. That in turn may let you read passwords.
Don't conflate the two separate things.
Compartmentizing is good, but doesn't protect against Heartbleed.
Disposable proxies don't protect you.
Perfect Forward Secrecy does protect you because the private keys aren't reused. It is notable that you didn't mention the one technique that actually helps.
To me that shows you misunderstand what heartbleed is. Some if your critisms of OpenSSL are valid, but not for the reasons you claim.

The Private key thing is "bad" but far less bad than the user data that is being exposed.
The Private Key Exposure lets you do impersonation, but you would have to do something with DNS, or such to get it to work. Where as me getting your user/pass, or account information has immediate impact, and can't be "undone".
PS Conflate doesn't mean what you think it does. Conflate has to be wrapper for several topics or ideas that are related.
I can't "conflate" two unrelated things because conflation is by default "true". If we were discussing Gentrification, and Inflation in the housing market of San Francisco then we be talking about the conflated issue of "The San Francisco Housing Crisis".
Just as you can't "inflate" something with a vacuum or sand, or peanut butter, you can't conflate it with something that is unrelated.
This issue of the understanding of the word conflate comes from the fact that people think that "confused" sounds so much like it, and when they are trying to sound smart they use the word conflate when they really mean confuse, and think the two are synonyms.
-Brandon Wirtz
PlexiNLP (I know my words)

"Conflate" is very often, and properly, used to mean "treating two unrelated things as though they were related," which I believe is exactly what the poster meant to say you are doing. You can make an argument that "trying to conflate" would be more accurate, but only if you're more of a linguistic prescriptivist than most editors.

So would you say Polar SSL is less likely to contain exploitable code?

It seems to have a history of having fewer exploits that can result in leaking data. It has had more DoS exploits (I think) but most of them could be mitigated through configuration.
I think that the revenue model for Polar has put more money in to making sure it is secure. OpenSSL has always suffered from the fact that it is mostly "leach Ware". People use but they don't contribute because it isn't related to their core competency, so they don't mod or upgrade it. Polar on the other hand has people paid to test, patch and maintain the code.

To paraphrase Thomas, a core issue is getting the right eyes auditing code. We need more CTFs that offer cred and prizes to keep projects honest. Also, important core projects like OpenSSH, OpenSSL, GnuPG and core projects like zlib need to be held to a greater deal of scrutiny and adversarial reporting. But as it stands now, projects like zlib dont even bother GPG sign releases, so how much confidence can you have in the rest of their security posture? This is failure by way of academic happy-clappy laziness waiting to happen. Also other important projects like Glibc that were massive big balls of mud are likely to conceal all sorts of vulns by their enormous codebase and number of features AND poor support history, hence Debian's selection of eglibc.
So in conclusion there are a number of hard but necessary steps to reduce the threat surface from this sort of thing ever happening again. Because doing the same thing and expecting a different result is the literal definition of "stupid."
FOSS is part of the economy and important projects should be treated with the seriousness, responsibility and customer service of a business, even if the sale price is $0.

Yup, the threat horizon for Heartbleed only starts at March 14, 2012 with the first release of OpenSSL 1.0.1.
http://openssl.6102.n7.nabble.com/OpenSSL-1-0-1-released-td3...