I just had a quick look at the code that caused the bug (good overview at http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html). The problem is that a length (unsigned short) is read from the incoming data but then it doesn't check whether there's actually enough data to read all of it.
The only way I can think of to check this is to manipulate the payload length. Making this length something lower than what we actually send should return in only a part of the original data being sent back. Of course this is behavior in both the bad and good versions, so we can't check it that way. We could also make the length field something higher than what we actually send, but this would mean getting back data.
*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.
Just a thought, maybe someone with more knowledge of these things can confirm it?
Tom
Alexander Dietrich schreef op 09/04/14 21:07:
According to Qualys, they have developed a test that "verifies the problem without retrieving any bytes from the server, other than the bytes we send in the heartbeat request": https://community.qualys.com/blogs/securitylabs/2014/04/08/ssl-labs-test-for...
Best regards, Alexander
PGP Key: 0xC55A356B | https://dietrich.cx/pgp
On 2014-04-09 20:51, Paul Pearce wrote:
- Should authorities scan for bad OpenSSL versions and force their
weight down to 20?
I'd be interested in hearing people's thoughts on how to do such scanning ethically (and perhaps legally). I was under the impression the only way to do this right now is to actually trigger the bounds bug and export some quantity (at least 1 byte) of memory from the vulnerable machine. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays