On Wed, Aug 14, 2002 at 08:42:47PM +0100, Ben Laurie wrote:
>>>I propose we have a compile
>>> time flag that determines whether impossible conditions are fatal or
>>> return errors,
>> Go ahead, compile time flags are how we usually handle such thin
Bodo Moeller wrote:
> On Wed, Aug 14, 2002 at 03:39:03PM +0100, Ben Laurie wrote:
>
>
>>So how did the buffer get to be too small?
>
>
> Well, in one of the cases it was improper protocol data checking
> (fixed in 0.9.6f). The others should really be impossible, but if
> they ever become poss
Arne Ansper wrote:
>
> On Wed, 14 Aug 2002, Ben Laurie wrote:
>
>
>>The point is that the application is now in an inconsistent state and
>>cannot reliably know anything. Even returning from a function could
>>cause an exploit. The only safe thing to do is abort (now I think about
>>it, probabl
On Wed, Aug 14, 2002 at 05:05:27PM +0300, Arne Ansper wrote:
>
>
> On Wed, 14 Aug 2002, Ben Laurie wrote:
>
> > The point is that the application is now in an inconsistent state and
> > cannot reliably know anything. Even returning from a function could
> > cause an exploit. The only safe thing
On Wed, Aug 14, 2002 at 03:39:03PM +0100, Ben Laurie wrote:
> So how did the buffer get to be too small?
Well, in one of the cases it was improper protocol data checking
(fixed in 0.9.6f). The others should really be impossible, but if
they ever become possible, this most likely is because of c
t;[EMAIL PROTECTED]>
> Subject: Re: cvs commit: openssl/util mkerr.pl
> Send reply to:[EMAIL PROTECTED]
>
>
> This is really amazing. A security library that can get corrupted
> and the developers don't have a clue on how to fix it properly. If a
> lib
Bodo Moeller wrote:
> On Wed, Aug 14, 2002 at 01:53:29PM +0100, Ben Laurie wrote:
>
>
>>>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
> For most of the consistency checks that your patch added, a failure
> would very likely indicate that there is an inconsistency in the
> OpenSSL source code similar to the potential inconsistency discussed
> above.
Precisely what happened with AES was added to OpenSSL; I reported an
internal bu
> 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.
If yo
On Wed, 14 Aug 2002, Ben Laurie wrote:
> The point is that the application is now in an inconsistent state and
> cannot reliably know anything. Even returning from a function could
> cause an exploit. The only safe thing to do is abort (now I think about
> it, probably die() shouldn't even prin
On Wed, Aug 14, 2002 at 01:57:32PM +0100, Ben Laurie wrote:
[...]
>> 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
Re: cvs commit: openssl/util mkerr.pl
Send reply to: [EMAIL PROTECTED]
This is really amazing. A security library that can get corrupted
and the developers don't have a clue on how to fix it properly. If a
library cannot detect a problem and report that problem to the
calling
On Wed, Aug 14, 2002 at 01:53:29PM +0100, Ben Laurie wrote:
>> 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 act
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
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
occ
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
>
Arne Ansper wrote:
>
>>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().
>
>
Bodo Moeller wrote:
> On Wed, Aug 14, 2002 at 01:24:32PM +0300, Arne Ansper wrote:
>
>
>>[...] what if some standalone application thinks that the
>>best solution for _its own_ problems is to reboot the machine? (happens
>>all the time under the windows btw, you install some crap a
On Wed, Aug 14, 2002 at 01:24:32PM +0300, Arne Ansper wrote:
> [...] what if some standalone application thinks that the
> best solution for _its own_ problems is to reboot the machine? (happens
> all the time under the windows btw, you install some crap and the
> installer happily
> 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().
to make it more extreme:
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 sensi
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 tri
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 absolut
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
> "impossib
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
[EMAIL PROTECTED] wrote:
> bodo02-Aug-2002 13:38:16
>
> Modified:.Tag: OpenSSL-engine-0_9_6-stable CHANGES Configure
> Makefile.org PROBLEMS STATUS config
>crypto Tag: OpenSSL-engine-0_9_6-stable cryptlib.h mem.c
>ssl
26 matches
Mail list logo
