3 ms·
This exploit as posted is suboptimal. If I understood the format of a heartbeat message correctly, its one byte type followed by two bytes unchecked length. So
by revelation 13y ago
This exploit as posted is suboptimal. If I understood the format of a heartbeat message correctly, its one byte type followed by two bytes unchecked length.
So if you want to maximize the data extracted with each connection, you should send FF FF for length, instead of 0x0302 bytes as its requesting now (if n2s is for network byte order to short).
- DerpDerpDerp 13y agoWhen deployed against active servers, some people have reported trouble with extracting the maximum payload. It's possible this has been tuned to avoid some interference regarding that sort of thing.
- quasque 13y agoIt's requesting 0x4000 (16384) bytes. Here's what the bytes in the heartbeat packet sent by the PoC mean: 0x18 TLS content type: heartbeat [*] 0x03 0x02 protocol version: TLS 1.1 [RFC 4346, section A.1] 0x01 message type: heartbeat request [RFC 6520, section 3] 0x40 0x00 payload length: 16384 bytes [RFC 6520, section 4] This should be followed by a payload of that length, but if it isn't (as in the PoC) the vulnerable versions of OpenSSL will then carve it out of the heap to form the response packet - this is what leads to the data leakage. [*] see https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-5 https://www.iana.org/assignments/tls-parameters/tls-paramete...
- quasque 13y agoJust realised I accidentally deleted a line while I was reformatting, that should read: 0x18 TLS content type: heartbeat [*] 0x03 0x02 protocol version: TLS 1.1 [RFC 4346, section A.1] 0x00 0x03 content length: 3 bytes [RFC 4346, section A.1] 0x01 message type: heartbeat request [RFC 6520, section 3] 0x40 0x00 payload length: 16384 bytes [RFC 6520, section 4]