back to article 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 …

COMMENTS

This topic is closed for new posts.

Page:

I don't get it..

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?

17
0
(Written by Reg staff) Silver badge

Re: I don't get it..

"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.

6
0

Re: I don't get it..

Call me paranoid....Who would like to be able to get userids and passwords without tricky legal issues.....

Tin foul hat at the ready.....

4
4
Silver badge

Re: I don't get it..

just suggesting, perhaps we could be a bit less crap at everything?

"C"

The path starts here.

9
9
Silver badge

Re: I don't get it..

> 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.

6
0
Silver badge

Re: I don't get it..

supplemental:

Submitted here:

http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c5082161b02a22116ad75f822b1

(it was in another Reg story). Also, this obligatory link:

http://xkcd.com/1353/

2
0

Re: I don't get it..

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 :)

12
42
Linux

Rust would help, but there's a reason it's not used there

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.

23
2

This post has been deleted by its author

Silver badge

Re: I don't get it..

Just to shame the asshat that caused all this misery. Robin Seggelmann you sir are nobody's hero right about now.

0
18
FAIL

Re: I don't get it..

""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.

8
6
Silver badge
Windows

This attitude is not the key to success

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.

8
10
Silver badge

Re: I don't get it..

Obviously the $1 000 000 question is why expect a length parameter at all ? That is metadata that can be calculated quite trivially.

5
5

Re: I don't get it..

> 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).

5
0

Re: I don't get it..

"> 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

2
1
Silver badge

Re: I don't get it..

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

5
0
Silver badge

Re: I don't get it..

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.

18
1
Silver badge

Re: This attitude is not the key to success

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.

17
1

Re: Rust would help, but there's a reason it's not used there

So, we use C because it's fast.

And it's fast because it has no bounds checking.

And we need bounds checking.

So we add it to our C code, except when we forget.

Isn't there some problem here?

14
0
Silver badge

Re: Rust would help, but there's a reason it's not used there

That is the problem. There are some very clever code analysis systems that can help to spot these kind of mistakes, but they can't spot everything.

0
0

Re: I don't get it..

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.

2
0

Re: I don't get it..

Hi Tombo software will never be totally secure, any more than code will ever be perfect. I think open and closed source are both good, but your citing of 2 bugs in 25 years is hardly an impressive argument against FOSS.

7
0
Holmes

Re: I don't get it..

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.

7
7
Anonymous Coward

Re: I don't get it..

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.

0
10

Re: Rust would help, but there's a reason it's not used there

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

2
0
Silver badge
Boffin

This article conatins a major flaw

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.

8
1
Facepalm

Re: I don't get it..

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.

10
0

Re: I don't get it..

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.

4
0

Re: I don't get it..

More importantly, with OSS, you can either wait for the fix to be released, or get the code and build your own.

Or stick the compile options workaround in.

Its open to you, and up to you.

2
0

Re: I don't get it..

Indeed. Within about 2 hours of hearing about this bug, my Ubuntu desktop got an automatic fix. Like to a Microsoft respond like that ;)

6
0
Anonymous Coward

Re: I don't get it..

"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...

2
3
Anonymous Coward

Re: I don't get it..

But when you heard about it wasn't when it was published. Several hours went by between announcements and patches.

Microsoft release patches at the SAME TIME they make such announcements...

1
8
Silver badge

Re: I don't get it..

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).

2
4
Silver badge

Re: I don't get it..

no.. it wouldn't.

But you also can't write lowlevel runtime libraries with Ada either.

It is either too slow, or the language itself prevents you from doing the things necessary.

1
0
Silver badge

Re: I don't get it..

But you don't know how long Microsoft sat on the announcement...

It could have been several days... or 17 years.

2
0
Silver badge

Re: I don't get it..

I know a few banks that actually have a no open source policy: They forbid use of open source software.

Well, they'll be laughing this week.

1
0

Re: I don't get it..

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.

1
0

Re: Rust would help, but there's a reason it's not used there

...or except when we deliberately remove checking for performance reasons.

http://article.gmane.org/gmane.os.openbsd.misc/211963

1
0

Re: I don't get it..

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.

1
0

Re: I don't get it..

>> 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

0
1

Re: I don't get it..

"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.

0
1
Silver badge

Simple script?

Not that simple - unless you can remember 50 lines of cipher hex codes off the top of your head.

What language is it anyway? Looks like some fucked up version of python. Ruby maybe?

0
24

Re: Simple script?

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.

2
0
(Written by Reg staff) Silver badge

Re: Simple script?

"Ruby maybe?"

Bingo. And by simple, I meant there's no screwing around with race conditions, crafting complicated structures, dodging ASLR, building ROP chains and what not. Just simply lie in a length header. Take the rest of the year off.

C

10
1
Silver badge

Re: Simple script?

"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.

1
46

This post has been deleted by its author

Silver badge
Facepalm

Re: Simple script?

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?

6
2
Anonymous Coward

Re: Simple script?

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 ....

16
2
Anonymous Coward

Re: Simple script?

> You seem to be insisting the script must be complicated, because you're too stupid to understand it

And looking through his post history I would say you have hit the nail on the head.

4
0
Boffin

Re: Simple script? @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.

Are you a script kiddie? I didn't get ROP but I do know what ASLR is. And indeed the script is simple as the only thing it does is send a malformed package (the phony heartbeat request) and get the juicy bytes in response. Compared to the weirdness usually involved with exploits like stack smashing/injecting shell code, it's pretty straightforward.

5
0

Page:

This topic is closed for new posts.

Forums

Biting the hand that feeds IT © 1998–2017