In article <[EMAIL PROTECTED]> you wrote:
>[...a interesting discussion on the apache-ssl list with
>Ben Laurie whether assertions in server code are reasonable or not...]
>
> The discussion is pointless unless you can indicate a way in which it
> makes Apache-SSL function incorrectly.
How
On Fri, Oct 30, 1998, Marc Slemko wrote:
> On Fri, 30 Oct 1998, Ralf S. Engelschall wrote:
>
> > So on a typical system an attacker who gained access to _any_ account (not
> > necessarily the UID of the httpd or the gcache process) can simply dropping
> > down gcache and this way all httpds by j
On Fri, 30 Oct 1998, Ralf S. Engelschall wrote:
> So on a typical system an attacker who gained access to _any_ account (not
> necessarily the UID of the httpd or the gcache process) can simply dropping
> down gcache and this way all httpds by just sending garbage to the gcache
> port.
What doe
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 l
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 hap
Ralf S. Engelschall wrote:
> H??? 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, p
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.
Che
On Sat, Oct 31, 1998, Ben Laurie wrote:
> Ralf S. Engelschall wrote:
> > H??? 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 t
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
Ralf S. Engelschall wrote:
>
> On Sat, Oct 31, 1998, Ben Laurie wrote:
>
> > Ralf S. Engelschall wrote:
> > > H??? 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
On Sat, Oct 31, 1998, Ben Laurie wrote:
> >[...]
> > | 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 occu
Ralf S. Engelschall wrote:
>
> On Sat, Oct 31, 1998, Ben Laurie wrote:
>
> > >[...]
> > > | 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 er
On Sat, Oct 31, 1998, Ben Laurie wrote:
> > > >[...]
> > > > | 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 comm
Ralf S. Engelschall wrote:
> Yes, and the only problem is that although we both are the opinion that
> something is wrong under those situations we still differ in the opinion which
> action should be done. I'm still convinced that it's not really reasonable to
> use assertions (which do the exit
On Sat, Oct 31, 1998, Ben Laurie wrote:
>[...]
> > Nevertheless I _personally_ prefer non-assertion based error checking where
> > error codes are passed up to the callers and where the processed don't die.
>
> What? We've already agreed that assertions should not be used in place
> of error han
On Sat, 31 Oct 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 a
On Sat, 31 Oct 1998, Ben Laurie wrote:
> 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 assertin
Marc Slemko wrote:
>
> On Sat, 31 Oct 1998, Ben Laurie wrote:
>
> > 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
> > se
Marc Slemko wrote:
>
> On Sat, 31 Oct 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.
red bad!? (was: Re: [apache-ssl]
Invalid method in request)
>On Sat, Oct 31, 1998, Ben Laurie wrote:
>
>> > > >[...]
>> > > > | nRead=saferead(nFD,&usLength,sizeof usLength);
>> > > > | assert(nRead == sizeof usLength);
>> > > >
On Sat, Oct 31, 1998, Ben Laurie wrote:
>[...]
> > While you may think that the only way to run a SSL server is where no one
> > can login, no users can run any programs on it, etc. in the real world
> > that isn't always possible.
>
> I have to say that my main interest is in secure servers. If
Ralf S. Engelschall wrote:
>
> On Sat, Oct 31, 1998, Ben Laurie wrote:
>
> >[...]
> > > While you may think that the only way to run a SSL server is where no one
> > > can login, no users can run any programs on it, etc. in the real world
> > > that isn't always possible.
> >
> > I have to say t
127.0.0.1 is just another interface. All possible errors can happen.
Imagine a server where the load is high enough that other processes don't
get to run much... they write to localhost, expecting what's on the other
end to get it, but the localhost interface buffers overflow.
Or the misconfigur
SPASTIC Member wrote:
>
> 127.0.0.1 is just another interface. All possible errors can happen.
> Imagine a server where the load is high enough that other processes don't
> get to run much... they write to localhost, expecting what's on the other
> end to get it, but the localhost interface buff
On Wed, Nov 18, 1998, Ben Laurie wrote:
>[...]
> > My $0.02, if it's worth anything. But if that's the way you code
> > Apache-SSL, I'm very glad my friend pointed me to mod_ssl.
>
> If you want to use a system where programming errors are "corrected" by
> removing the assertions that reveal t
Ralf S. Engelschall wrote:
>
> On Wed, Nov 18, 1998, Ben Laurie wrote:
>
> >[...]
> > > My $0.02, if it's worth anything. But if that's the way you code
> > > Apache-SSL, I'm very glad my friend pointed me to mod_ssl.
> >
> > If you want to use a system where programming errors are "corrected"
On Wed, Nov 18, 1998, Ben Laurie wrote:
> > Please be technical only and correct. The assertions were not just removed in
> > mod_ssl. They were replaced with run-time checks which pass the error up to
> > the callers and there it's handled without and exit().
>
> I don't understand the distinct
27 matches
Mail list logo
