Ralf S. Engelschall wrote:
> Hmmmm??? Do you mean it cannot occur in practice? Or do I misunderstand you
> here. As I said: We not even need an attacker: When an I/O read error occurs
> for gcache it already falls down. So the DoS attacker is just the worst case.

Aha. Now we get down to it. OK, please describe how an I/O error can
occur on a locally connected socket.

> > BTW, I'm not claiming that I can defend every piece of code I've ever
> > written. If I've got it wrong, I'm keen to hear about it, especially if
> > accompanied by patches. Where I draw the line is with statements like
> > "assertions are inherently bad".
> 
> I didn't say this. I said you're right that assertions are not bad in general.
> But any I/O or input related assertions are bad IMHO. And the patch is
> available, of course: diff gcache.c ssl_gcache.c, diff gcacheclient.c
> ssl_gcacheclient.c, diff gcachecommon.c ssl_gcachecommon.c.

This is far to general a criterion. Some kinds of I/O are completely
deterministic (given correct code). I agree that to assert on user input
is not a brilliant idea, but on a tightly linked client/server pair, it
seems to me no different to asserting on the value of a parameter.

> > I'll also admit that my coding style is more biased towards defending
> > against programmer error than attackers, but it is programmer errors
> > that attackers exploit, of course.
> 
> As I said: As long as the assertions are not I/O or input related they are ok.
> But they are very problematic for a production system when they depend on
> input coming from external sources.

And the external source in this case is?

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: [EMAIL PROTECTED] |
A.L. Digital Ltd,     |Apache-SSL author     http://www.apache-ssl.org/
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache/
______________________________________________________________________
Apache Interface to SSLeay (mod_ssl)   www.engelschall.com/sw/mod_ssl/
Official Support Mailing List               [EMAIL PROTECTED]
Automated List Manager                       [EMAIL PROTECTED]

Reply via email to