1

A race condition occurs when two or more threads access shared data and try to do so at the same time.

The Heartbleed attack is a vulnerability in OpenSSL, where a Client sends heartbeat requests to a Server. The heartbeat requests can be of variable length, the length of the request is specified, however not checked for. Therefore when manipulating the size field of the heartbeat request, the server would return a reply that could be very long and therefore contain security relevant information.

Now, how on earth is this vulnerability related to two threads trying to access shared data at the same time? This question has been asked in one of our previous exams and I really cannot answer this. Can somebody help?

Also, very much related to this question is the following: Can type-safety prevent race-conditions? Type-safety basically means: The programmer is no longer in charge of memory management. And since race-conditions arise whenever two or more threads are trying to access shared memory, type-safety provides a way to at least minimize race-conditions, doesn't it?

user503842
  • 257
  • 4
  • 10
  • have you read the CVEs? – schroeder Feb 20 '19 at 17:15
  • No. But I think the basic idea gets across pretty good in this little presentation: https://imada.sdu.dk/~jamik/dm557-16/material/recent-issues.pdf – user503842 Feb 20 '19 at 17:29
  • Then you have your answer? – schroeder Feb 20 '19 at 17:31
  • 2
    @user503842: a race condition is a condition which only happens when some more or less random conditions align with each other. This can happen with threads but can happen also without threads, for example if specific access pattern cause a specific memory layout. And specific memory layout is needed in order for heartbleed to leak not only memory but memory containing sensitive data (like the private key). – Steffen Ullrich Feb 20 '19 at 17:39
  • @SteffenUllrich Thx so much! So, can I say sth like: A race condition is a condition that needs to hold in order for the outcome of an operation to be dependent on the temporal behaviour of other operations; in the case of the heartbleed bug security relevant information will only then be leaked when it is within the buffer returned as heartbeat response. ... could a type-safe language have prevented this error ? I think it could have, since the programmer would not have been able to specify the length of the heartbeat request. – user503842 Feb 20 '19 at 17:52
  • 1
    @user503842: There are different levels of type-safety, some would have prevented this error (when the type-safety is strong enough to result in memory-safety) while others not. See also [wikipedia](https://en.wikipedia.org/wiki/Type_safety#C). – Steffen Ullrich Feb 20 '19 at 18:15
  • 1
    Where are you getting that this is a race condition? The only thing I see in the descriptions ([here's a detailed one](https://www.theregister.co.uk/2014/04/09/heartbleed_explained/)) indicate it's a bounds checking issue. The presentation you provide says only mentions a race condition in relation to 'dirty cow'. – JimmyJames Feb 20 '19 at 19:24

1 Answers1

6

Heartbleed was not an exploitation of a race condition... though you could argue the non-deterministic nature of the data returned is an outcome of a race condition. The exploit was a case of improperly placed trust (and improper bounds checking). The victim trusted the attacker to tell it how large it's heartbeat response payload should be (because the server code was written to write a response of the same length (asserted length via the payload_length field)).

In heartbleed the "hacker" sends a four-byte HeartbeatMessage with a 1 byte payload. this is the normal/correct length but the "hacker" claims the payload is huge in the payload_length field... lets say 65535 bytes in size. The victim reads 65535 bytes from its memory (instead of the 1 byte is should read). This read starts from the received HeartbeatMessage payload. It thus sends far more data than it should, leaking potentially useful/dangerous information.

Using the above a "hacker" can repeat this process as often as they like to try to find juicy info from a target.

DarkMatter
  • 2,671
  • 2
  • 5
  • 23
  • 2
    Yep. It seems like OP already knows how heartbleed works, they just can't figure out how race conditions are related. If they're not related, then that's the real answer. Although, while I wouldn't think of it as a race condition myself, based on Steffen's comment and wikipedia's definition of "race condition" I think you could consider the leaking of sensitive data a race condition. – AndrolGenhald Feb 20 '19 at 21:05
  • @AndrolGenhald ah thanks. I guess I didn't read the question carefully enough...the title just triggered me :) – DarkMatter Feb 20 '19 at 21:16
  • @AndrolGenhald Can you explain how this issue can be described as a 'race condition'? Let's start with the first sentence from the Wikipedia page for [Race Condition](https://en.wikipedia.org/wiki/Race_condition): "... where the system's substantive behavior is dependent on the sequence or timing of other uncontrollable events." I don't see how this can be fit into that definition. It's not related to sequencing events and timing is not relevant. There's uncontrolled here. I really think this is the right answer. It's not a race condition at all. – JimmyJames Feb 20 '19 at 21:39
  • @AndrolGenhald Errata: There's uncontrolled here -> There's *nothing* uncontrolled here – JimmyJames Feb 20 '19 at 21:45
  • @JimmyJames The data that is leaked is uncontrolled. It could be 64kb of 0s, or it could be the private key to the site's TLS certificate. But I'd agree it's not really how most people would categorize it. – AndrolGenhald Feb 20 '19 at 21:53
  • @AndrolGenhald OK but that's a bit of a stretch, I think. The cause of the issue is the lack of bounds checking and/or lack of input validation (why this would be an input value in the first place is silly.) The fact that arbitrary locations in memory may or may not have something interesting in them isn't a race condition assuming the other parts of the application that depend on what's in those locations are deterministic. The only way I can get there is if we are talking about it from the perspective of the exploiter but they are inherently misusing the application. – JimmyJames Feb 20 '19 at 22:29
  • @JimmyJames Agreed :) It's not like it's uncommon to think of it from the perspective of the exploiter, but if I were exploiting it, saying I was exploiting a race condition wouldn't be how I would explain it to someone. I think the definition does technically fit though, which is at least worth mentioning since that's what the question is about. – AndrolGenhald Feb 20 '19 at 22:35
  • thx guys! - I think I have a good understanding of this bug now! Btw you might be completely right, maybe this was a trick question and the answer is: The Heartbleed Bug does not exploit race conditions. – user503842 Feb 21 '19 at 09:00
  • @user503842 I think where we landed is that if anything the effectiveness of the exploit is (slightly) limited by the unpredictability of what will be available in the read memory which is the only thing here that can be considered a 'race condition'. – JimmyJames Feb 21 '19 at 14:22