In message <[email protected]>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <[email protected]> wrote: >"Ronald F. Guilmette" <[email protected]> writes: >> Xin Li <[email protected]> writes: >> > For this bug, doing calloc() makes no difference. >> I would very much like to know how you reached that conclusion. > >It's very simple. The explpoit relies on reading past the end of the >allocated buffer. You're right, of course, and I missed that. My apologies. My other points still stand however, the most important of which is that the protocol definition itself seems to be asking for trouble, and that this bug was/is the almost inevitable outgrowth of an entirely poorly considered bit of the SSL protocol specification. Hummm... In fact, now that I look at the code some more I'm not even sure if my suggestion for using calloc() in place of malloc() throughout OpenSSL was even entirely off the mark... although the exact _place_ where that suggestion might have been most profitably applied is *not* within the dtls1_process_heartbeat() function itself, but rather is wherever the original receive buffer was allocated, i.e. the buffer that is pointed to by s->s3->rrec.data upon entry to the dtls1_process_heartbeat() function. I have not searched the code to find the place where this original packet receive buffer is allocated, however regardless of whereever this allocation takes place I think that it is safe to say that if such buffers were always allocated to the maximum possible size needed (1+2+65536+16) _and_ if they were always obtained via calls to calloc() or its functional equivalent, then there would never have been such a thing as the Heartbleed bug and this conversation would not now be taking place. Does anyone happen to have a copy of the complete original (unpatched) source code lying around? I have a sudden urge to look and see where exactly the buffer corresponding to s->s3->rrec.data is allocated, with an eye to trying to understand why on earth it was ever made shorter than 1+2+65536+16 bytes long. (Well, actually, it appears that these buffers could all have reasonably be allocated to the rather smaller fixed size of 2^14+16 if the OpenSSL authors had actually followed the RFC. See below.) Regards, rfg P.S. Public reports regarding this bug assert that an attacker can gulp down up to 64KB long chunks of one's private data at a time. I have no reason at present to disbelieve those assertions, however if those assertions are true, then that would seem to suggest that in addition to creating a rather awful bug, the implementors of OpenSSL may have also failed to perform range checking on the payload_length values provided within received HeartbeatRequest packets... range checking that is apparently *MANDITORY* in order to simply meet the requirements of the relevant RFC (6520): "The total length of a HeartbeatMessage MUST NOT exceed 2^14 or max_fragment_length when negotiated as defined in [RFC6066]." ... "If the payload_length of a received HeartbeatMessage is too large, the received HeartbeatMessage MUST be discarded silently. ^^^^ If the OpenSSL authors had simply bothered to implement the requirements of RFC6520, then it would appear that the worst case data leakage would have been on the order of 16KB(-3) per gulp... still quite an awful bug, but not quite as bad as the one currently making headlines. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"