Bodo Moeller wrote:
> On Tue, Aug 13, 2002 at 08:09:02PM +0200, Lutz Jaenicke wrote:
>
>>On Tue, Aug 13, 2002 at 07:45:30PM +0200, Bodo Moeller wrote:
>>
>>>On Tue, Aug 13, 2002 at 05:10:34PM +0100, Ben Laurie wrote:
>>
>
>>>>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 think we should define our terms clearly.
>>
>>For me an "internal error" is an error that must not occur at all and
>>that can only have appeared due to the library having failed somehow
>>such that an inconistent state occurs (in M$-notation: "an unexpected
>>error occured" :-). I consider an error like this to be fatal and think
>>that it is still sensible to abort().
>>By definition we have no explanation on how this could happen and so
>>we don't know how to continue.
>>Example: when working through the internal session cache we learn, that
>>the linked list is corrupted, we have dangling pointers and don't know
>>what is going on. This would touch all threads using the same SSL_CTX.
>>Thus: we don't know how to repair it -> abort().
>
>
> This is an example of an internal error where we do not know how to
> continue.
>
> But for various other potential errors, we do know what happened
> (e.g. a buffer has insufficient size) and we do know how to continue
> without doing significant harm (abort this one TLS/SSL connection, and
> in a way such that we have a likelihood of seeing a useful error
> message in some log file). These are still "internal errors".
>
> For example, here is a consistency check I added in April when I
> implemented the empty fragment protocol weakness workaround
> (ssl/s3_pkt.c):
>
> if (s->s3->wbuf.len < (size_t)prefix_len +
>SSL3_RT_MAX_PACKET_SIZE)
> {
> /* insufficient space */
> SSLerr(SSL_F_DO_SSL3_WRITE, ERR_R_INTERNAL_ERROR);
> goto err;
> }
>
> The buffer is allocated by the SSL library, but this happens
> elsewhere, so it's safer not to rely on buffer allocation being
> sufficient for what I plan to do with the buffer. If the buffer is
> not sufficient, this would be a bug in OpenSSL.
The buffer is _supposed_ to be big enough. We know of no path through
the code that should cause it to be not big enough. So if this condition
occurs something we don't understand has happened. Continuing under
these circumstances as if nothing were wrong strikes me as foolhardy.
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]
