Anatomy of OpenSSL's Heartbleed: Just four bytes trigger horror bug The password-leaking OpenSSL bug dubbed Heartbleed is so bad, switching off the internet for a while sounds like a good plan. A tiny flaw in the widely used encryption library allows anyone to trivially and secretly dip into vulnerable systems, from your bank's HTTPS server to your private VPN, to steal passwords, login …
I'm wondering again how code gets written without bounds-checking, on "message length" parameters. It's not the first time is it?
Is the leaked data simply the junk that was in de-assigned memory? It looks kind of important stuff you might not want to write over - let alone send over the internet.
perhaps as a general rule, apart from the obvious bounds checking, one should clear all memory as it becomes (re-)assigned? - or better on de-assignment.
Perhaps generally these under-run or their over-run brethren should be detected and escalated as a general principle.
just suggesting, perhaps we could be a bit less crap at everything?
"Is the leaked data simply the junk that was in de-assigned memory?"
Yeah, it appears to be dead or alive blocks of memory allocated via some malloc()-like magic. If dead, one wonders why it wasn't zeroed on release.
"just suggesting, perhaps we could be a bit less crap at everything?"
This is why I'm learning Rust for its better pointer and array bounds handling, tho I'm not sure it could have helped here.
C.
System libraries usually need to be implemented in the most efficient possible way. That efficiency is achieved by working as close as possible to the "bare metal" — And C gets you there. For code that will be executed thousands of times every minute, in millions of servers all around the world (such as OpenSSL), this efficiency is a must.
And when writing in a language without the memory management bits we have come to get used to... does not come without a price. Writing in C means you have to be much more careful — precisely because of this kind of issues.
System libraries usually need to be implemented in the most efficient possible way. That efficiency is achieved by working as close as possible to the "bare metal" — And C gets you there.
BOLD TALK ... FROM THE EIGHTIES! Well, already in 1984: The Lilith
Writing in C means you have to be much more careful
THIS ZIMMER FRAME REALLY GETS ME THERE FASTER, I JUST HAVE TO BE CAREFUL WHEN GOING DOWNSTAIRS. SURE I BROKE MY NECK A FEW TIMES, BUT IT'S NOT GONNA HAPPEN AGAIN.
System libraries usually need to be implemented in the most efficient possible way. That efficiency is achieved by working as close as possible to the "bare metal" — And C gets you there.BOLD TALK ... FROM THE EIGHTIES! Well, already in 1984: The Lilith
Writing in C means you have to be much more careful
THIS ZIMMER FRAME REALLY GETS ME THERE FASTER, I JUST HAVE TO BE CAREFUL WHEN GOING DOWNSTAIRS. SURE I BROKE MY NECK A FEW TIMES, BUT IT'S NOT GONNA HAPPEN AGAIN.
This kind attitude to coding is exactly why many current applications and indeed operating systems are so staggeringly inefficient and slow compared to the equivalent of even a few years ago despite the hardware being orders of magnitude faster.
The lower level the API the less appropriate it is that it is implemented using "managed" code. If you had an understanding about just how much more processor resources (memory and CPU cycles) are consumed by managed code than unmanaged code then you would understand. Some things are appropriate implemented one way, some another. No one programming technique is appropriate for all cases and attempting to use one across all or to use the wrong technique is utterly stupid.
...or except when we deliberately remove checking for performance reasons.
according to wikipedia "Performance of safe code is expected to be ... comparable to C++ code that manually takes precautions comparable to what the Rust language mandates"
If it has met those objectives, then it seems to me you'd have to have a pretty compelling reason not to use Rust
Modern kernels tend to leave memory unzerod even when after it is "freed", often for virtual memory / performance reasons. Even though the memory is free and available for re-use, pointers are maintained to it in case the same data is needed again soon afterwards. Eg. Solaris 10. Upon being malloced/added to a different process, it is then zerod, obviously.
This instance seems to be a case of a process requesting data from a legitimate partner process, where the two already have a legitimate, authenticated relationship. So I am not sure how the kernel/system could prevent that. It doesn't know about the application's (openssl) data design.
It's able to grab whatever 64KB off the heap is near the object it's supposed to be able to ask for, so that can include memory from live or dead objects, because C doesn't stop you from shooting yourself in the foot by running off the end of an array.
The reason the memory of the dead objects wasn't zeroed on release is that, by default, OpenSSL keeps its own pool of memory and doesn't bother using malloc() very often (because on some systems, that might be slow, which would make managers sad), so OpenSSL doesn't call free() when it's done with those objects, and therefore if you've got a malloc()/free() system that has extra protection, like zeroing stuff or putting guard pages after chunks of memory to keep you from running off the ends, it doesn't waste time doing that.
So yeah, modern Linuxes give you lots of cool tools, but they're not compiled in by default.
C is still my favorite programming language after all these decades, but most people really shouldn't be allowed to use it, certainly not without extensive oversight of anything security-critical.
"one wonders why it wasn't zeroed" -- It's just a heartbeat. All one has to do is compare the lengths and message. If they don't match, ignore. You're done. What you are suggesting would make it easier to pull off a denial-of-service attack. Next you will be suggesting rebooting between heartbeats.
> Tin foul hat at the ready.....
You're meant to wear it on your head. That's the problem right there.
I share your paranoia; but this looks more like a slacker's foul up that nobody noticed rather than alphabet interference. Be interesting to see who submitted the code though, just in case.
This post has been deleted by its author
I'll take the downvotes on posting the author's name above. Yes its a common mistake but if you are going to screw up code make sure its not code half the world uses. And yes many other people are responsible as well including especially his main reviewer Stephen Henson (a Brit I assume).
""C"
The path starts here."
@Destroy,
We'll all get tons of downvotes for this obviously, but I completely agree with you. C does not have any idea of objects, their size, bound checks etc ...
It's time IMHO to start using a really secure language for those critical security components.
This fiasco wouldn't have happened on a lib written in ADA.
You can't trust a language which allows a tab (erm, sorry, a pointer, since tab don't exist) to access memory anywhere with no control.
I don't get it either, all the open source morons have been saying for years their OSS crap is more secure, then we get things like this. Oh and the 23 year old x windows vuln exposed a few months ago.Hint: down arrow is below, morons lol :)
Nice troll.
Mistakes are made equally in Open Source Software and Closed Source Software. The point with OSS is that it can be made more secure. This kind of fault in closed source may never get spotted or reported and then you'll be in an even worse situation where you don't know about the fault or how long it's been there.
Only problem is, nobody is actually examining Open Source for such errors.
Apart from the alphabet soup agencies, the malware writers, and the companies that make money finding defects, that is. The only people who do have an interest in finding exploitable defects.
Clearly, while the reasoning behind the "many eyes" idea appears to be reasonable, in practice it does NOT work. A bit of economic theory will tell you immediately why this is so, and also why the bad guys are the most likely people to find these defects.
"This kind of fault in closed source may never get spotted"
Or exploited then.
"where you don't know about the fault or how long it's been there."
I don't know with Open Source either. What I do know is that it's much easier to go find new holes in Open Source given the motivation as you can look at the source code...
>> I don't know with Open Source either. What I do know is that it's much easier to go find
>> new holes in Open Source given the motivation as you can look at the source code...
Cobblers. Holes are mainly found by fuzzing, not by poring through source code. Exploits rely on code mishandling user-supplied data - fuzzing involves sending enormous quantities of deliberately broken data at something until it does something it's not supposed to. This is far easier than having to work out what some piece of logic is supposed to be doing, what it's actually doing, and why it's broken in this or that edge case. Chuck a load of crap at a victim machine (that you also control), wait for it to go bang, and then work out what you are going to be able to do while the smoke's clearing.
http://en.wikipedia.org/wiki/Fuzz_testing
This post has been deleted by its author
> why expect a length parameter at all ? That is metadata that can be calculated quite trivially.
How? A socket connection is just a stream of octets, there are no record delimiters (except as provided by your own protocol).
And then you need to detect with partial data (eg. interruption on the network).
"> why expect a length parameter at all ? That is metadata that can be calculated quite trivially.
How? A socket connection is just a stream of octets, there are no record delimiters (except as provided by your own protocol).
And then you need to detect with partial data (eg. interruption on the network)."
A long time ago, XDR solved those problems. It just needs to be used.
http://man7.org/linux/man-pages/man3/xdr.3.html
I would suggest the key issue is that there are two specifications of the length of the data, not one. One has to wonder about the reason for this redundancy (it may be useful in another context, I do not know enough about the SSL libraries and protocols), but here it causes a problem. It could be used to check for malformed heartbeats, of course, but the moment you store information in two places, and fail to ensure consistency of the information, you can get into trouble.
Using a calloc rather than malloc to allocate the space for the incoming heartbeat data based on the SSL3 length field and then storing the payload_length size chunk in it (after checking payload_length<=SSL3_record.length) should have avoided the problem, I would think. Of course calloc could be a touch more costly than malloc, but in the context of security (or indeed delays in the network) I would think this hardly figures in the grand scheme of things.
Just my tuppence
It isn't stored in two places. The count inside the packet is sent by the originator, and is supposed to say how big the payload is. The other count is the size of the packet actually received - it could differ for example if there was an I/O error of some kind. Having two sources of the same info allows it to be verified, but this was unfortunately missed.
It really is unpleasant to see how many poeple are dissing the folk who provide the whole world with free and usually superb quality software.
Hmmm... [checks wrist watch, confirms 'Yes, it's 2014...'] perhaps the compilers could be programmed to watch for such things. The compilers could essentially follow the input data around the code and make sure that somebody, somewhere has "sanitized" it. They already do similar checks on code; this is a tiny forward step.
I'm not a coder drone, but once upon a time I wrote a nice 30+ foot long chunk of code (overnight) for serious industrial purposes. Every single last module I wrote checked and double-checked all the inputs and all the outputs, both on entry and on exit. That chunk of code was used for about a decade with zero bugs.
AC suggested he is not a coder drone and proposes that bounds checking be done in the compiler.
The first problem is that at compile time the bounds are not known. So the compiler can't check.
The second problem is that, in the kernel of an O/S, especially in Unix/Linux type of O/S's, there are many places where bounds checking is just inappropriate. Very carefully controlled ways of ignoring bounds checking are used so that your PC responds fast, at the speed you want. Context Swaps, Process Creation, memory paging, device IO. These are things that need to be done fast and efficiently.
There is no doubt that Heartbleed is a big bug. But it was a simple mistake. It was not deliberate. So holding up the whole of the FOSS community to ridicule, and the author of this code specifically, is pointless. In any event, the patch was out the same day it was discovered and people were patching their SSL code straight away. Ask how quickly microsoft/IBM/Oracle/Sybase come up with fixes to such problems.
This article glosses over the issue that the buffer overflow returns RANDOM DATA, not specifically keys or passwords. An actual attack would require, generally, a whole lot of queries each returning 64K of RANDOM DATA. Such an ACTIVE attack might be noticed, for starters, and is not assured of ever returning useful data. Having said that, I certainly don't want to downplay this vulnerability. But even this article is, as it's first sentence shows, overly alarmist rather than rational.
After reviewing the code, I can't help but wonder if C is an appropriate language for critical stuff like ssl. A language where the programmer has the power to return the contents of a chunk of memory to the caller in a critical area like this would be akin to allowing bank tellers access to the entire contents of the bank's vaults to service customer requests. It just makes very little sense.
Time for a rethink and a re-write I think.
When did simple=being able to remember it off the top of your head?
I can't remember the entirety of many web applications I have had write in my time off the top of my head, a fair number of them I would regard as simple however. Simple can mean that when you read it, making sense of what it does and being able to write a variant is easy. Which in this case, it seems like it is.
"And by simple, I meant there's no screwing around with race conditions, "
Err , you should never get race conditions on a half duplex protocol.
"dodging ASLR, building ROP chains and what not."
What not? Oh dear. No more acronyms to impress us with? Shame.
Most people definitions of "simple" mean something like a 10 line script sending one or 2 strings down the line. Not 300 lines of code doing challenge response.
"Take the rest of the year off."
Thanks for the advice. Here's some for you - buy yourself a dictionary.
Most people definitions of "simple" mean something like a 10 line script sending one or 2 strings down the line. Not 300 lines of code doing challenge response.
"Most people" are fucking idiots challenged by the simple task of cleaning up the stall behind themselves.
Sending one or 2 strings down the line is not "simple", it's a problem for the "differently abled" (or more charitably, for "first steps" exercises)
Doing challenge response in a 10 line script that can be read and understood by the tester is "simple" and done at the right level of abstraction.
Check out Erlang, then report back, mkay?
boltar - "Most people definitions of "simple" mean something like a 10 line script sending one or 2 strings down the line. Not 300 lines of code doing challenge response."
Well, I'm not a dev, but I read and understood what's going on with the script, with no great difficulty. Probably wouldn't have done, if it'd have been in C or C++
You seem to be insisting the script must be complicated, because you're too stupid to understand it... maybe the explanation isn't that the script is complicated ....
"Well, I'm not a dev, but I read and understood what's going on with the script, with no great difficulty. Probably wouldn't have done, if it'd have been in C or C++"
Like the other the dimwits on here you're confusing "understand" with "simple". I understand most of the 230K line c++ framework I'm debugging at the moment - I wouldn't call it simple. I understand everything this script does, but I wouldn't call it simple. printf("hello world\n"); is simple. This script isn't.
Interestingly I got 7 thumbs down for pointing out that the script is NOT written in C. Which I think shows the general IQ level of the posters on this group. Doubtless these knuckle dragging mouth breathers will mark this down too.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
