On Sat, Oct 31, 1998, Ben Laurie wrote:
> 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.
How it actually can occur I don't know. Depends on the platform, I think. But
in general I don't think that Unix guarantees that a TCP connection to
localhost always can be performed without any problems. I've no actual
scenario of an I/O communication error at hand, but I've at least the code
parts at hand which then could fail:
| nRead=saferead(nFD,&usLength,sizeof usLength);
| assert(nRead == sizeof usLength);
Here the assert makes sure that really the requested number of bytes are read.
But when an I/O error or some other communication problem occurs the actual
number of read bytes can be different. Then the gcache process falls down.
And I've seen exactly gcache exits with this assertion on my boxes (Solaris
2.6) while I was mostly sure that no personal attacker was involved. Instead
I really assume it was just some I/O communication error...
> > > 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.
Yes, it may be a little bit too general criterion. But implemented parameter
variants depend only on the actually used parameter variants (all used
variants should be implemented). But no one can externally inject other
parameter variants into the code. While on I/O related things the used things
depend on the actually received data under runtime. Here replacing assertions
with normal error checks and error code returns seems more reasonable.
> > > 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?
The external source is the request data which comes in through the socket.
Sure, usually this source is the gcache client code. But as we already
discovered in the worst case this could also be a real attacker.
Greetings,
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]
