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 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. > > > Yes, but if you look at the tests, it is quite obvious that the > typical reason for something "impossible" happening is that a buffer > is too small for its purpose, and that it is quite unlikely that > memory has already been corrupted before the consistency check (and, > thanks to the consistency check, memory won't be corrupted at all). > Just look at your patch, these are the first checks that you added: > > + die(s->s2->conn_id_length <= sizeof s->s2->conn_id); > memcpy(s->s2->conn_id,p,s->s2->tmp.conn_id_length); > > + die(i <= SSL_MAX_KEY_ARG_LENGTH); > if (i > 0) RAND_pseudo_bytes(sess->key_arg,i); > > + die(i <= sizeof sess->master_key); > if (RAND_bytes(sess->master_key,i) <= 0) > > + die(karg <= sizeof sess->key_arg); > memcpy(d,sess->key_arg,(unsigned int)karg);
So how did the buffer get to be too small? The bottom line is that in this case the safest thing to do is die. If you want to be clever and reason about how unlikely an exploit is, then by all means, expose yourself to that risk. If you insist on this being a possibility, I propose we have a compile time flag that determines whether impossible conditions are fatal or return errors, then we can stop arguing about it, you can set the flag to the dangerous position, and I can set it to the safe one. 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]
