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 _______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays