On Sat, Oct 31, 1998, Ben Laurie wrote:
> Ah, I also forgot to mention that an attacker with the ability to talk
> to gcache can completely screw you with just legitimate messages - by
> poisoning your cache. They can presumably also get access to session
> keys. So, if anyone can talk to gcache apart from Apache-SSL, you've had
> it anyway.
Correct, of course. Nevertheless we shouldn't accept the assertion problems
(the exit) just because in the worst case there can be even more bad things
happen at other edges. Because my opinion is that I/O errors or other
non-attacker-based invalid input occurs at least as often than attacker-based
invalid input. So we should take care of them, too. And one way to take care
of them is to make sure that the processes don't fall down. And here not using
assertions _at least_ for those I/O related things sounds very reasonable to
me. Ben, you don't have to eliminate all assertions, of course. Some of them
can be ok. But the I/O related ones should be replaced by different error
checking code...
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
