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:

Silver badge

What is heartbeat used for?

Can someone explain why it was added, and what use it is, and why it is enabled by default?

It looks to me to be a way for the client to send something to the server and have it echoed back. Is there a reason why the server should be echoing back client supplied data, and in what way this (as opposed to sending back data that the client doesn't control) is a useful addition to the protocol?

Beyond bad programming, I'm wondering if this is a "kitchen sink" mentality, where stuff that is of narrow interest has been included, but was enabled by default against all best practices.

4
1

Re: What is heartbeat used for?

"Is there a reason why the server should be echoing back client supplied data"

Sure, it is for a future internet distributed storage system. Or an awesome built in DDOS amplifier.

"Maybe it is for making enormous swiss cheese.

No. The beam would last for what, 15 seconds?

What good is that? -I respect you, but I graduated.

Let the engineers figure that out.

Maybe it already has a use...

...for which it's designed. "

0
2
Silver badge

Re: What is heartbeat used for?

I imagine the idea was to allow the client to put an internal ID, time, or similar in the request which could then picked back up by the client from the response so that a decision may be taken about that particular connection.

Next huge Internet exploit next week: "A malicious server could craft a fake heartbeat response which crashes all clients connecting running library x..."

It would probably have better just to design the thing to send back a ping without any data.

1
0
Paris Hilton

Re: What is heartbeat used for?

Upvote. I have the same question for the reasons why this was ever implemented.

It seems to me that to keep the connection alive, you could just send a single byte, or a SYN-ACK, back and forth, no need for elaborate stuff.

Anyone knows the logic for what is being done?

0
0

Re: What is heartbeat used for?

It is really ping for TLS. If you have ever run an ssh terminal session and had it drop after 5 minutes of idleness, when you have forgotten to run a "ping localhost" or "watch date" you will know why.

The reason for variable sized packets (and such large packets) is allegedly to enable an application to use this protocol extension to find the maximum size of packets it can send along the connection without fragmentation.

2
0
Anonymous Coward

Re: What is heartbeat used for?

More to the point, I wonder why they don't just set SO_KEEPALIVE on the socket and let the TCP stack do the keep-alive.

2
0
Anonymous Coward

Re: What is heartbeat used for?

> don't just set SO_KEEPALIVE

The SO_KEEPALIVE can be effectively disabled at the kernel level by setting a high interval time. The application can not do anything about this.

The KEEPALIVE keeps the socket active but does not test the application listening to that socket is active. I've had many a hung process were to all intents and purposes the socket is still connected but the process is off somewhere else and will never service that socket.

Re: VeganVegan

The SYN-ACK packet is only ever sent when the socket is first established.

0
0
Black Helicopters

Client-side implications?

I'm a medical doctor, so trying to get my head around SSL is a bit o.t. to me...

What's the client-side implication of all this? Is changing passwords after the server-side certs have been renewed enough? Or are the libraries found in BYOD environments - what I'm saying is, is a leak inherently possible at either end, and equally dangerous?

0
0

Re: Client-side implications?

Let me take a stab at your questions, @DaDoc:

Q: What's the client-side implication of all this? Is changing passwords after the server-side certs have been renewed enough?

A: Nope. The server's OpenSSL implementation has to be upgraded or re-compiled to get rid of the vuln. FIRST, then server-side cert renewal SECOND. You can change your passwords after that.

Q: Or are the libraries found in BYOD environments - what I'm saying is, is a leak inherently possible at either end, and equally dangerous?

A: Possibly. I've no clue. If the "client" is being logged into by others, then yes, I guess.

2
0
Anonymous Coward

So having been caught out by this problem, will those organisations using these open-source libraries start examining the source updates to ensure they are secure?

Will they pay other organisations to validate the source for them, if they don't have the expertise in-house?

I only ask because surely the real problem will be if everyone sighs about the bug and updates their systems, but then learn nothing from it and just hope it doesn't happen again.....

2
0
Anonymous Coward

Sloppiness or malice?

The RFC (6520, Feb 2012) is quite explicit in what must be checked.

<quote>

The total length of a HeartbeatMessage MUST NOT exceed 2^14 or

max_fragment_length when negotiated as defined in [RFC6066].

</quote>

There seems to be no check in the OpenSSL code for this part of the *standard*. Indeed I *still* do not see this being checked.

<quote>

If the payload_length of a received HeartbeatMessage is too large,

the received HeartbeatMessage MUST be discarded silently. "

</quote>

Now although "too large" is not defined (is this > 2^14 or max_fragment_length, or is this greater than the received packet length -19) one would have thought there would be some evidence of consideration of this part of the RFC in the code - there generally is in all other parts of the Open SSL code I have seen. Proper consideration of this paragraph of what is a blessedly short RFC would have made the "bug" much more difficult to overlook. As it is this paragraph (along with seems to have been completely ignored (until the patch).

So this would seem not to be ordinary programming sloppiness, but an actual ignoring of part of the RFC that would have been in front of the programmer at the time.

6
0
Gold badge
Trollface

Re: Sloppiness or malice?

So the RFC iasued in 2012 tells you how to do it. And the code submitted in 2011 does it a different way? I suppose that is possible in a causal universe, where you can't tell the future; it's Einstein's fault.

8
0
Silver badge

Re: Sloppiness or malice?

If I was the coder, i'd be pointing my finger at the NSA and saying "they made me do it."

Everyone would believe that, and who could prove otherwise? Who'd BELIEVE any proof the NSA provided that they weren't responsible?

1
0
Anonymous Coward

Re: Sloppiness or malice?

Well the draft from July 2011 is even more explicit (albeit it changed semantically by the time the final standard was written to (a) actually require padding, and (b) to require silent dropping).

Here is the July 2011 draft version of it

<quote>

If payload_length is either shorter than expected and thus indicates

padding in a HeartbeatResponse or exceeds the actual message length

in any message type, an illegal parameter alert MUST be sent in

response.

</quote>

So I think in all cases an explicit instruction to check payload_length has been part of the draft and final RFC.

The December 4 2011 version is essentially the same as the final 2012 RFC.

2
0

Re: Sloppiness or malice?

RFC 6520 was coauthored by the same chap that created the bug. He could have hardly been oblivious to it. Make what you wish of it -you couldn't have it better for whatever conspiracy theory tickles your pickle- but my take is that this is just a simple oversight despite its catastrophic consequences.

1
0

This works both ways

The article concentrates on attacks against servers, but this works both ways. (See the Use Cases at https://tools.ietf.org/html/rfc6520). Either end can send a heartbeat packet. A malicious or compromised server can extract a vulnerable client's memory. How long before all those will be patched, including anything that is statically linked?...

3
0
Anonymous Coward

will someone please think of the CHILDREN!!!

0
0
Anonymous Coward

So what happened to the coder

Responsible for that commit? Clearly their commits now needs to be checked thoroughly and continue to be scrutinized closely from here on. When you're coding a opensource security library as critical as openssl there needs to be a line of reponsibility that needs to be enforced.

I can only hope that nobody contributing to the OpenSSL code base is working for spy agencies - but that's a big ask.

If the OpenSSL team was in the financial sector or such, the coder would've normally been put on leave at the very least.

The code commit (improper bound checking) is a very very stupid mistake to make for C or C++ coders, it's such a newbie mistake. I'm also surprised they don't do proper TDD which would've caught these issues before they're released.

1
0

Re: So what happened to the coder

Re: "the coder would've normally been put on leave at the very least."

For a moment there I thought you were going to say 'put to sleep'.

Almost the entirety of the source code universe is a total mess. A bug like this should be impossible in burned-in mission critical code like this. Unfortunately, a lot of evil habits are actually cultivated by design. The programmers don't know any better and they are immune to reasoning about it.

The C language is the language of memory corruption. It is a 'high' low level language designed to build operating systems and compilers. Code that does not do bounds checking is faster. In some cases speed differentials are astonishing due to the hierarchy of storage from the CPU registers through L1, L2, L3 level caches and ordinary RAM. Stuff that stays within the L1 cache operates at lightening speed -- about 200 times as fast as a reference to RAM.

It is fair game for called code to have expectations. If you pass a memory reference, you don't want every nested call to check its validity. In some cases, called code could not do bounds checking because the extent of the bound is only known back up the call chain somewhere.

When you look at the sources, you find that these bugs are usually in code that has other tell-tale flaws as well. Older code contains errors by even good programmers. Dennis Ritchie was a god, but not all of his code examples are keepers and he was guilty of some faulty practices.

The worst stuff is stuff that was written or maintained by talented journeymen programmers whose short-term memory was at a maximum and whose coding experience led them to believe that clever code was a good thing that showed off their talent. I doubt it is even true these days, but Duff's Device is an extreme optimization that *may* be a necessary evil at times, but when not necessary simply devolves to being evil. I know of at least one nascent small C compiler that fails to generate correct code when it encounters Duff's Device. A beginner or a journeyman will blame the compiler when it fails. Someone more experienced will blame the coder. Every time you do something fanciful in code you take a chance that a maintainer will have to debug and recode. An experienced, literate and conscientious programmer should not be doing this.

Beyond a failure in coding, this current situation demonstrates something that I have often commented upon in these forums. Our system is insecure and it is essentially insecure by design. Given the enormous resources spent on systems using this SSL code, does it make any sense at all that it suffers from such a mundane flaw? It does if you realize that security is not that important to the people holding the purse-strings and calling the shots.

This is about the most serious security bug I have ever seen. Cleanup is going to be a real bitch. Repairing and replacing the code is the least of the work effort. Prediction: Most of the systems that had this issue will not have passwords changed and keys replaced. If a significant number of systems were actually compromised, we will be living with the consequences of this for a long time.

Despite the severity of this bug, it pales in comparison to the inherent systemic insecurity of the Internet. There is no question in my mind that people in the know are protecting important things with air gaps, enormous keys created with very good sources of entropy, decoy layers, etc. That is to say, nobody who understands this stuff could possibly have any faith in the current security systems as actually deployed.

It is very hard to look at the current state of the Internet, particularly things like the failed introduction of IPv6 and not think that people with influence who understand security have encouraged this situation precisely because they wish it to remain vulnerable to them.

13
0
Silver badge
Pint

Re: So what happened to the coder

"Almost the entirety of the source code universe is a total mess"

Why, the entire universe is a total mess. Entropy is one of the most fundamental qualities of it, and an important driving force. It would be folly to hope that our puny sources would be unaffected by the Almighty Mess.

Excellent comment, though.

0
0

Re: So what happened to the coder

If the OpenSSL team was in the financial sector or such, the coder would've normally been put on leave at the very least

That is really not a great idea, if you punish people badly for making coding errors, it doesn't exactly encourage them to come forward and admit them. That sort of reaction encourages people to sweep problems they notice under the capet and pretend they don't exist, rather than risk being punished.

0
0
Facepalm

Workaround: Clients could refuse to connect to vulnerable websites

Surely if the client SSL library was altered to try this exploit once during certificate exchange, the client could drop the connection if anything extra was returned in the heartbeat request. It's a heuristic thing - the larger the "exploit" request size, the easier it would be for the client to tell that the server was unpatched - but it is at least *something* that could be done at the client end to catch connections to insecure servers.

2
0
Unhappy

Does the leak cross services?

given a situation of a server running openssl for email authentication and openssl for apache, can apache be exploited to reveal email passwords or is the information stored in memory restricted to that service (apache)?

0
0
Silver badge

Re: Does the leak cross services?

From what I know about this the answer is 'It depends'. But I suspect that if you can access OpenSSL for any service on a server you can assume that everything on that server is compromised.

I'm not sure if this can cross the boundary of virtual systems running on the same iron or not though.

0
0

So which major sites are / were affected?

While the technicalities of this are all a bit beyond me, my understanding is that if any services I have used at any point in the past have been compromised, my data may have been swiped. In such cases I need to wait for them to patch their systems, renew the server-side certificates, *then* change my password. That's marvellous, but how do I know which systems are / were affected? Is anyone maintaining a list anywhere? It would be easier to glance down that than to manually check every site for which I have a login. I know there's a website checker at heartbleed.com, but surely this won't pick up a system which was patched on Monday, for example, but from which my data might already have been taken several months ago? I appreciate it's a bit stable door / horse bolted in some ways, but I'd still like to know, and to change the pw anyway.

1
0

Re: So which major sites are / were affected?

This morning (as per last night), using Chrome, Twitter is still throwing up a warning that I might be signing in to a fake site due to SSL issues. Using Opera, no warning.

0
0

I didn't ask for no heartbeat...

No one mentioned this, but IMHO at least *part* of the problem is that a little used TLS extension was not only implemented, but *enabled by default* in the first place.

Security is one place where conservatism really pays off quite well.

4
0

Re: I didn't ask for no heartbeat...

Conservatism is right. A Debian server of mine is safe from Hearbleed, purely because it is still on Debian 6. I haven't upgrades to 7 yet, even though support runs out in a month or so.

For secure systems, a balance is needed so that the system does not become too out-of-date, but not too up-to-date either. These low level libraries contain some of the most important code in the world, it seems, and they have perhaps got the balance a bit wrong this time.

1
0

Re: I didn't ask for no heartbeat...

Our situtation exactly...

+2 for Debian Squeeze servers, conservatism payed of (again)

-2 for Ubuntu 12.04 LTS well we do have a love and hate relationship with you

0
0
Linux

I'm happy to see that the bulletproof OS is still bulletproof.

0
0

Quite.

This being a userspace application, the problem is not kernel or OS related.

Is that what you meant?

2
2
Anonymous Coward

Yep - Windows Server is not affected.

2
1
Silver badge

Why is heartbeat a variable length?

Why not have a fixed length test to check server is up and running? Surely a 4 or 8 byte fixed length message is enough to prove that it responds with what you sent and then there is no need for the length parameter.

3
0
Silver badge
Boffin

@PropieTards

We will not know which versions of IIS are affected, but IIS has had a "long" history of very embarrassing flaws, one of which was the ".." vuln that allowed you to download any file on the file system, yes, you could even download the registry and bruteforce passwords!!!!

However, this issue affects version 1.0.1 to 1.0.1f, and yes, the most widely used versions are 0.97 & 0.98 branches and, to some lesser extent, the 1.0.0 branch ... 1.0.1 is "pretty recent".

from heartbleed.com:

What versions of the OpenSSL are affected?

Status of different versions:

OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable

OpenSSL 1.0.1g is NOT vulnerable

OpenSSL 1.0.0 branch is NOT vulnerable

OpenSSL 0.9.8 branch is NOT vulnerable

I call this a lot of noise for some BS.

3
0
Anonymous Coward

Re: @PropieTards

"We will not know which versions of IIS are affected, "

We already know - none.

"but IIS has had a "long" history of very embarrassing flaws"

Not since NT4. Since then its had far fewer than say Apache...

1
4
WTF?

Payload???

What's the point of being able to attach a payload of 64k of arbitrary data to a heartbeat message anyway?

What's wrong with a simple sequence number?

Did they think the case where the other end was sufficiently functional to interpret and respond to a protocol message, but somehow incapable of copying a block of memory correctly was worth detecting?

Did this Request for Comments actually get any comments?

1
0

61 minutes to midnight

So that's just...22:59, then?

1
0

'Secure' websites

Maybe now all those shopping websites etc will take down those fictitious 'your data is 100% safe with us' logos that they all seem so proud of.

1
0

I was fairly shocked to read about this. I run OpenVPN on my home server....surely OpenVPN hasn't let me down I thought?,.........it had. Bugger.

Still at least it was an easy fix. Updated OpenVPN Access Server to latest and now I appear to be clear. Changed my openvpn and server passwords to be safe also.

0
0
Anonymous Coward

And this is why i use a one time pass code with openvpn.

0
0
Bronze badge

'...the blunder is far worse than Apple's gotofail...'

No it isn't.

0
0
Silver badge

Puzzled

I am curious as to why a response to a KeepAlive message, ie the hearbeat, needed to contain the original packet other than to say that the comms wasn't garbled.

The specs should have said that something like ten bytes expected and ten bytes returned.

Or, even better, have with that packet of data going in there would be a checksum. So if a shortened packet was sent the the checksum would be wrong because it wouldn't match the outgoing checksum of the data packet going out.

0
0

Article

Just wanted to say good work for such an informative and interesting article. As a software developer (mostly) working in a different language it was enough for me to understand and not too much to bore. Well done.

Now I just have to contact all the vendors of my enterprise grade firewalls for patches since they all use OpenSSL code without exception...

0
0

Years and years ago (early 1990s), I was on a project which did static analysis on a safety-critical system. By static analysis, I mean automated code verification using a tool which checked for all sorts of consistency issues (but it could not deal with anything which involved concurrency, e.g. shared memory).

It would easily have picked up both the OpenSSL bug and the recent Apple GotoFail.

The technology exists, and has existed for a while now (the tool was written in Algol and was old even when I was using it). But it is slow and expensive to use (the tool's users need to be experts).

You get what you pay for.

1
0

None so blind as those who will not see

@Richard Pennington 1:

Those tools are torture to use, but they work. Problem is, they work. When people see the monstrous cascade of errors coming out of these things they head for the hills.

Splint is not one of the tools above, but even splint sends out showers of warning messages on old code. I use it toward the end of development of stuff I need to be confident is clean. I don't usually bother with older code. For reasons that elude me, some programmers aggressively defend the most dreadful practices even when directly confronted with the consequences.

Here is something that shows how extreme programmer denial can get:

For years now, people have been opening tickets due to a horrendous security flaw in FileZilla. Except for this persistent report that I re-opened four years ago and keeps getting re-opened, they keep getting closed. Anybody with casual access to the file system is able to get FTP passwords with a single command line. They don't have to know anything beyond that. Reason: passwords are stored in the clear in an easily found and inspected place.

Do this on a windows machine with FileZilla on it and it will cheerily show you a list of hosts and their FTP passwords:

find "Pass" "%APPDATA%\FileZilla\sitemanager.xml"

Here is the programmer's take on it in his own words:

http://trac.filezilla-project.org/ticket/5530#comment:6

status changed from new to closed

priority changed from critical to normal

resolution set to rejected

Whether passwords are stored encrypted or in plaintext makes no difference in security.

----------

The above is a critical design flaw that routinely gives up FTP passwords to hackers. The developer is adamant that this design is beyond reproach and will never change.

----------

I confess that I have been programming for more than 30 years and have been fairly involved in one aspect or another with security for about half that time. However, the programming errors and the security issues surely cannot be that hard to understand. Perhaps the solution to the above security flaw is not easy. However, the fact that the single command line above reveals dozens of server passwords just can't be that hard to understand. If you look at the other comments on the ticket above you will see that it is *only* the programmer who seems immune to understanding.

2
0

There are a lot of comments here...

...so this may have been covered already. Apologies if it has.

Some poor guy is now being pilloried as being responsible for this because he 'commited' it. The real culprit is the QA process that lead up to that commit. Name them.

That's all.

1
0

Re: There are a lot of comments here...

@Andrew Commons

Upvote for you. Professional testers (not weekend beta testers) are the unsung heroes of software development. Programmers have tunnel-vision (as they should) and are terrible at reviewing and validating their own code. Testing is a difficult, dreary and thankless job, but on large projects it can make the difference between success and failure.

1
0

I believe the client/server practically will leak at most 16KB of its heap content, not 64KB as commented in the fix description. Although the payload length is 16-bit (and have max value of 64K - 1), the copying function dtls1_write_bytes() would have aborted if the total payload is greater than 16K.

Comment?

0
0

Page:

This topic is closed for new posts.

Forums

Biting the hand that feeds IT © 1998–2018