[tor-relays] Long-term effect of Heartbleed on Tor

[Tom van der Woerdt]

Felix Büdenhölzer schreef op 10/04/14 22:13:
>> *However*, if there's a way to specify the data it sends back, that
>> wouldn't be a problem (I'm no legal specialist though). I have not yet
>> tested my theory, but sending a few extra bytes in the heartbeat
>> message (and of course incrementing 'length' in the 'ssl3_record_st'
>> struct) should do that. It would allow causing the server to return
>> data the client sent. If it's not sent back, the server isn't
>> vulnerable. No random memory is read as the server did in fact
>> allocate the memory, it's simply not supposed to use it.
> If I get you in the right way I think this is what you are asking for:
> https://github.com/FiloSottile/Heartbleed
> This guy is sending a string in and reads it back.
>
> BR
> Felix
>

Had a quick look at the code. It's almost doing what I wrote, though 
it's still trying to actively exploit the issue by asking for 100 extra 
bytes (bleed/heartbleed.go line 36, "len(payload)+100") which will be 
unknown.

Anyway, I tested my thoughts from yesterday and it turns out it won't 
work because the idea is flawed. I do wonder what happens when a second 
ssl3_record_st frame is sent together with the heartbeat exploit. Would 
you get the next frame back, as it'll be next in the stream? But that 
would only always work if you can guarantee it's being read by OpenSSL 
in the same recv() call.

Tom