On Tue, Aug 13, 2002 at 05:10:34PM +0100, Ben Laurie wrote: > Bodo Moeller wrote: >> Ben Laurie <[EMAIL PROTECTED]>:
>>> As noted elsewhere, I really object to returning internal errors! >>> It makes no sense to attempt to continue after the impossible has >>> occurred. >> If we could be absolutely sure that these events are strictly >> "impossible", then it wouldn't make a difference if we call abort(), >> return an internal error, or post a coredump to alt.binaries: nothing >> of this could ever happen. In fact we don't "continue" -- we return >> an error, meaning that the current handshake will be aborted. > Yes, and the application will continue as if it were sensible to do so. In fact it *is* often sensible to do so because such supposedly "impossible events" are triggered by certain conditions (such as unusual parameters in a certain protocol version) that will not apply to all connections. In such cases we cannot continue the one connection where a potential buffer overflow was detected, but there's no reason to completely kill the application. The internal error terminates the single connection for which OpenSSL does not know how to continue. There is no reason why this should affect the rest of the program. >> We test this *before* accessing the buffer and return an internal >> error *instead*, so what bad thing could happen? > The application could continue to run with corrupt memory, thus exposing > it to an unknown exploit, in the case where the error really is internal > and not a protocol error. The consistency checks don't detect that memory *has* been corrupted. They detect that memory *would* be corrupted if the library simply continued to do what it is doing. But if we return an internal error, this does not actually happen. -- Bodo Möller <[EMAIL PROTECTED]> PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
