On Fri, Oct 30, 1998, Ben Laurie wrote:
> Ralf S. Engelschall wrote:
> > And now I ask me why _isn't_ this better? I don't understand it, Ben. IMHO
> > this non-assertion way _is_ better, because it prevents the system from being
> > dropped down (kind of DoS) by a local attacker....
>
> I'm happy to admit that is is a marginal improvement wrt a local
> attacker, but I can't see that it makes a significant difference to your
> defences against a local attacker, for the following reasons:
>
> 1. You should be using a UNIX domain socket. With appropriate
> permissions, this cannot be exploited as described.
Correct, then you need at least gained access to the UID of the httpd
processes. But you know that mostly all Apache-SSL and mod_ssl users are using
TCP sockets with gcache because this was the default configuration for years.
You changed it in Apache-SSL only _recently_, Ben.
> 2. The local attacker can DoS you trivially simply by overloading the
> HTTP/HTTPS port.
That's not really trivially IMHO, but ok. Accepted. Nevertheless: just because
there are other DoS possibilities doesn't mean we can ignore the gcache
related ones. Actually we don't talk about gcache vs. httpd. We talk about
assertions which are used inside gcache and httpd in general. Because just
sending gcache an incorrect request is not the only way you can let it fall
down, of course. There are other I/O related assertions. For instance when you
break the communication while sending data it fall down, too.
> 3. On most OSes a local attacker can kill you anyway in many othe ways.
Sure, but again: Just because of this we cannot say I/O-related assertions are
then ok.
> 4. No secure server should have local attackers.
<grin> "should", yes....
> The downside is that, in the event of a remote attack that makes Apache
> behave incorrectly, you will continue to run. Whether it is worth
> defending against a local attacker (given that if you even have one,
> you've got a serious problem) rather than against the (rather more
> likely) remote attacker is a difficult question. So, on balance, I can't
> answer the question "is it better?". All I can say is that it is
> different, and addresses a different threat model. My threat model says
> that if I've got a local attacker, I've already lost, so that makes my
> solution better. I don't know what your threat model is, so I can't tell
> what your evaluation will be (except I can guess it won't favour me).
My threat model is that a server process should never just die because of
bogus external input, independent whether the input comes from remote or local
host. All the time error checks should apply and correctly deny access
without DoS problems.
> The bottom line is that neither of our solutions should ever be
> exercised, so the relative merit is largely academic.
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.
> 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.
> 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.
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]
