OpenSSL "Heartbleed" Bug: Security hole can reveal client memory, breaking a huge chunk of encryptio
76 replies, posted
Source: [url]https://www.openssl.org/news/secadv_20140407.txt[/url]
[quote]OpenSSL Security Advisory [07 Apr 2014]
========================================
TLS heartbeat read overrun (CVE-2014-0160)
==========================================
A missing bounds check in the handling of the TLS heartbeat extension can be
used to reveal up to 64k of memory to a connected client or server.
Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately
upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.
1.0.2 will be fixed in 1.0.2-beta2.[/quote]
See also: [url]http://heartbleed.com/[/url]
[quote][b]What leaks in practice?[/b]
We have tested some of our own services from attacker's perspective. We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication.
[b]How to stop the leak?[/b]
As long as the vulnerable version of OpenSSL is in use it can be abused. Fixed OpenSSL has been released and now it has to be deployed. Operating system vendors and distribution, appliance vendors, independent software vendors have to adopt the fix and notify their users. Service providers and users have to install the fix as it becomes available for the operating systems, networked appliances and software they use.
[/quote]
Good job this showed up here, I just installed OpenSSL 1.0.1f last night.
OpenSSL has so many security flaws.
Gotta love that open source security software.
[QUOTE=pentium;44484017]Gotta love that open source security software.[/QUOTE]
Better than security by obscurity.
[QUOTE=pentium;44484017]Gotta love that open source security software.[/QUOTE]
To be honest this seems more a testament to the open source security if anything. If this was closed source and the exploit happened (it would, companies are totally shit at software development) we wouldn't be able to see what the problem is and fix it ourselves. We'd have to hope the company developing it makes the fixes and deploys it for all systems that could be affected.
[QUOTE=pentium;44484017]Gotta love that open source security software.[/QUOTE]
You mean the part where the bug was fixed and patches released in less than 6 hours after public disclosure?
Rather than the closed model where they don't even fucking tell you that they fucked up.
Still waiting on AWS to patch their load balancers... this is gonna be a long night.
[QUOTE=pentium;44484017]Gotta love that open source security software.[/QUOTE]
Any good kind of an encryption system is going to be open source. Period.
[QUOTE=Map in a box;44483880]OpenSSL has so many security flaws.[/QUOTE]
whats the alternative?
[QUOTE=Map in a box;44483880]OpenSSL has so many security flaws.[/QUOTE]
List?
[QUOTE=sloppy_joes;44491159]List?[/QUOTE]
It's literally one of the most vulnerable and most used libraries. You don't need a list, you just need a few minutes to research it yourself. It was made by an inexperienced programmer who kept adding on to it instead of trying to fix the (many) issues. It's not as bad now, but it's still rather rough
[QUOTE=Map in a box;44493687]It's literally one of the most vulnerable and most used libraries. You don't need a list, you just need a few minutes to research it yourself. It was made by an inexperienced programmer who kept adding on to it instead of trying to fix the (many) issues. It's not as bad now, but it's still rather rough[/QUOTE]
All I can find is that it's hard to use. If you have a source, you should be able to give it to us.
It's also used on like half the internet, considering how widely it's used and such I'd say it's doing a good job. Also the google search "openssl security flaws" only returns this.
[QUOTE=sloppy_joes;44493749]It's also used on like half the internet, considering how widely it's used and such I'd say it's doing a good job. Also the google search "openssl security flaws" only returns this.[/QUOTE]
You can specify a range to remove results in the past day, but even so, the only results are only bugs that have since been fixed.
I've heard the claim that it was basically a "programmers first encryption library" that was held together by duct tape, but if it works then really those claims don't mean much. Apparently GnuTLS is much worse.
[QUOTE=TheDecryptor;44493773]I've heard the claim that it was basically a "programmers first encryption library" that was held together by duct tape, but if it works then really those claims don't mean much. Apparently GnuTLS is much worse.[/QUOTE]
Tons of huge companies use OpenSSL. If it was that bad, we'd be hearing about vulnerabilities much more often than this.
Whatever OpenSSL was at its inception is in no way representative of what it is today.
More information on this exploit:
[media]http://www.youtube.com/watch?v=rE5dW3BTpn4[/media]
[QUOTE=Map in a box;44493687]It's literally one of the most vulnerable and most used libraries. You don't need a list, you just need a few minutes to research it yourself. It was made by an inexperienced programmer who kept adding on to it instead of trying to fix the (many) issues. It's not as bad now, but it's still rather rough[/QUOTE]
Being one of the most used libraries as well as security related does get you a lot of attention though. It's possible that other libraries have just as high a vulnerability rate, they just don't get discovered so much.
[QUOTE=supersnail11;44493838]Tons of huge companies use OpenSSL. If it was that bad, we'd be hearing about vulnerabilities much more often than this.[/QUOTE]
Its the benefit of the fact that its open source, there's so many people looking at the code issues (should) be spotted quite quickly and they have been in the past.
OpenSSL is pretty much a 2-man project, and the codestyle is so fucking awful, nobody wants to read through it.
It's basically luck someone found this bug.
We really need a proper, readable, library for this stuff. OpenSSL can't really be cleaned at this point, it's better to start over.
At this point it could be considered security through obscurity
[QUOTE=Map in a box;44494807]At this point it could be considered security through obscurity[/QUOTE]
If the choice is between OpenSSL and writing your own (and there doesn't seem to be many alternatives), OpenSSL is obviously the better choice. Sure, a bug like this went unnoticed since 1.01 (about 2 years), but if you write your own, you might not find out that you have a bug until it's already been used against you.
Never did I say roll your own, which is indeed a bad idea
If you guys want to know how incompitent the OpenSSL team is just read this:
[url]http://article.gmane.org/gmane.os.openbsd.misc/211963[/url]
[quote] From: Theo de Raadt <deraadt <at> cvs.openbsd.org>
Subject: Re: FYA: [url]http://heartbleed.com/[/url]
Newsgroups: gmane.os.openbsd.misc
Date: 2014-04-08 19:40:56 GMT (1 day and 37 minutes ago)
> On Tue, Apr 08, 2014 at 15:09, Mike Small wrote:
> > nobody <openbsd.as.a.desktop <at> gmail.com> writes:
> >
> >> "read overrun, so ASLR won't save you"
> >
> > What if malloc's "G" option were turned on? You know, assuming the
> > subset of the worlds' programs you use is good enough to run with that.
>
> No. OpenSSL has exploit mitigation countermeasures to make sure it's
> exploitable.
What Ted is saying may sound like a joke...
So years ago we added exploit mitigations counter measures to libc
malloc and mmap, so that a variety of bugs can be exposed. Such
memory accesses will cause an immediate crash, or even a core dump,
then the bug can be analyed, and fixed forever.
Some other debugging toolkits get them too. To a large extent these
come with almost no performance cost.
But around that time OpenSSL adds a wrapper around malloc & free so
that the library will cache memory on it's own, and not free it to the
protective malloc.
You can find the comment in their sources ...
#ifndef OPENSSL_NO_BUF_FREELISTS
/* On some platforms, malloc() performance is bad enough that you can't just
OH, because SOME platforms have slow performance, it means even if you
build protective technology into malloc() and free(), it will be
ineffective. On ALL PLATFORMS, because that option is the default,
and Ted's tests show you can't turn it off because they haven't tested
without it in ages.
So then a bug shows up which leaks the content of memory mishandled by
that layer. If the memoory had been properly returned via free, it
would likely have been handed to munmap, and triggered a daemon crash
instead of leaking your keys.
OpenSSL is not developed by a responsible team.
[/quote]
Here's quote from reddit
[quote]Fucking hell. The things that had to come together to make this do what it does and stay hidden for so long blows my mind.
A custom allocator that is written in a way so that it won't crash or show any unusual behavior when allocation bounds are overrun even after many requests.
A custom allocator that favours re-using recently used areas of memory. Which as we've seen, tends to lead it to it expose recently decoded https requests.
Avoidance of third party memory testing measures that test against such flaws under the guise of speed on some platforms.
A Heartbeat feature that actually responds to users that haven't got any sort of authorization.
A Heartbeat feature that has no logging mechanism at all.
A Heartbeat feature that isn't part of the TLS standard and isn't implemented by any other project.
A Heartbeat feature that was submitted in a patch on 2011-12-31 which is before the RFC 6520 it's based on was created. By the same author as the RFC.
Code that is extremely obfuscated without reason.[/quote]
just goes to show you that years of implementing lazy hacky shit while you think you're being clever eventually just bites you in the ass.
[QUOTE=Map in a box;44493687]It's literally one of the most vulnerable and most used libraries. [b]You don't need a list, you just need a few minutes to research it yourself.[/b] It was made by an inexperienced programmer who kept adding on to it instead of trying to fix the (many) issues. It's not as bad now, but it's still rather rough[/QUOTE]
Wow really? You should always be able and willing to cite your sources in an argument, if you aren't it's fair to assume your statements are bullshit. Tell that to a college professor and see what they have to say about it.
I'm not saying you're wrong about OpenSSL, I don't know because you haven't told us anything, but what I've bolded is completely absurd. The guy above me has the right idea. We just wanted to know what you were talking about you know?
[QUOTE=sloppy_joes;44500869]Here's quote from reddit
just goes to show you that years of implementing lazy hacky shit while you think you're being clever eventually just bites you in the ass.[/QUOTE]
The thing is, some of these have actually good reasons behind them:
"A custom allocator that is written in a way so that it won't crash or show any unusual behavior when allocation bounds are overrun even after many requests."
"A Heartbeat feature that has no logging mechanism at all."
The less you give the attacker, the better. Error messages can show a lot about the system, so it's best to not show any at all or show a very vague one.
"A custom allocator that favours re-using recently used areas of memory. Which as we've seen, tends to lead it to it expose recently decoded https requests."
It should clear the memory before it reallocates it, but this is meant to avoid leaving any trace of sensitive data in RAM after the computer shuts off. It might seem crazy, but this can be a real problem (especially depending on what type of storage is being used, how long the data is stored, and how often it's updated - for instance, Java Card will store all classes and instance variables in EEPROM).
"Code that is extremely obfuscated without reason."
Bad coding practices.
You might wonder why there isn't a way to change any of these decisions, but it's because the developers follow the belief that programmers aren't cryptographers, and if you present the end user with a choice they don't have knowledge to make, they'll make the wrong choice.
[QUOTE=supersnail11;44501135]The thing is, some of these have actually good reasons behind them:
"A custom allocator that is written in a way so that it won't crash or show any unusual behavior when allocation bounds are overrun even after many requests."
"A Heartbeat feature that has no logging mechanism at all."
The less you give the attacker, the better. Error messages can show a lot about the system, so it's best to not show any at all or show a very vague one.
[/QUOTE]
What? It means internal error messages. Like if something goes wrong with the system then the programmer has no idea that it's not behaving as expected. Protecting against buffer overflows and underflows and such.
[quote]
"A custom allocator that favours re-using recently used areas of memory. Which as we've seen, tends to lead it to it expose recently decoded https requests."
It should clear the memory before it reallocates it, but this is meant to avoid leaving any trace of sensitive data in RAM after the computer shuts off.
[/quote]
Not certain, but I'm pretty sure they made it prefer reallocating using recently used areas of memories for caching purposes. Either way, because they didn't zero the RAM before reusing it OR check for buffer underflows, they inadvertently allowed all this to happen.
[quote]
"Code that is extremely obfuscated without reason."
Bad coding practices.
[/quote]
You're agreeing with me?
[quote]
You might wonder why there isn't a way to change any of these decisions, but it's because the developers follow the belief that programmers aren't cryptographers, and if you present the end user with a choice they don't have knowledge to make, they'll make the wrong choice.[/quote]
It seems to me that they are just incompetent and lazy, apparently they created the custom allocator because malloc is slow on certain platforms, but they also didn't continually test it because they had tested it when it was first created, leading to this series of unfortunate fuckups.
[QUOTE=sloppy_joes;44501445]What? It means internal error messages. Like if something goes wrong with the system then the programmer has no idea that it's not behaving as expected. Protecting against buffer overflows and underflows and such.[/quote]
Any information is information an attacker can get, and information a programmer might misuse (like writing every error to a logfile and never removing it - really easy to leak sensitive information that way). This might be a little overboard, but it's the idea behind it.
[quote]Not certain, but I'm pretty sure they made it prefer reallocating using recently used areas of memories for caching purposes. Either way, because they didn't clear the RAM before reusing it, they inadvertently allowed all this to happen.[/quote]
Sure, they should've cleared the memory, but [URL="https://en.wikipedia.org/wiki/Data_remanence"]data remanence[/URL] is a serious problem and making sure your sensitive data isn't accessible after it's needed is important. Do you have a source on whether it was for caching purposes or not?
[quote]You're agreeing with me?[/quote]
I think he meant obfuscating as in "attempting to make the code unreadable" instead of "accidentally making the code unreadable."
[quote]It seems to me that they are just incompetent and lazy, apparently they created the custom allocator because malloc is slow on certain platforms, but they also didn't continually test it because they had tested it when it was first created, leading to this series of unfortunate fuckups.[/QUOTE]
Using malloc has different results depending on the platform, and you can't always trust the OS with it. It might allocate memory in a place that other applications can read, or you won't know where it allocated the memory (making it difficult to make sure you deleted it later). It might interfere with the calling application. Again, do you have a source on the lack of testing?
Sorry, you need to Log In to post a reply to this thread.