Bodo Moeller wrote: > 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.
I have already said that where the problem is caused by correctly detecting erroneous external input I have no objection to an error being returned. >>>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. Not so - they detect that an "impossible" condition has occurred, so we do not know whether corruption (or other nastiness) has already occurred or not. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
