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(). > > > to make it more extreme: why stop here? perhaps the right solution is to > reboot the machine? 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 reboots your system). for me it's not different if some > library thinks that the best solution for _its own_ problems is to kill > the application. the application must have a control. if the internal > error (it would be correct to call them bugs, btw) happens, application > must get this information and then it's up to the application to deal with > it. if it's simple commandline tool it can call abort by itself. if its > complex application it might unload the openssl and reload it later. or > save its state and restart. only application knows what the right thing to > do is.
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 print an error message). 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]
