OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: qmail, from bugtraq
From: Marek Habersack (grendelvip.net.pl)
Date: Fri Feb 04 2000 - 07:10:37 CST

* D. J. Bernstein said:
> http://cr.yp.to/qmail/guarantee.html
> http://cr.yp.to/qmail/venema.html
> http://cr.yp.to/maildisasters/postfix.html
>
> Wietse Venema writes:
> > I installed qmail as per author instructions and ran my machines
> > out of swap with a trivial exploit.
>
> That's because you neglected to use the tools that your system provides
> to allocate your resources.
This can be reversed. If a program claims to be secure, it should use all
the tools available (in that case APIs) to eliminate even remote possibility
to exploit this or another vulnerability. setrlimit(2) could be your friend
there - especially since you, as the author, have the best knowledge about
the demands of your product and can estimate the necessary values thus
protecting the user's system and at the same time not crippling your program
by tightening the limits too much.

> The crucial fact that you're failing to mention is that attackers can
> chew up all the memory on such systems BEFORE qmail is installed. It's
> rather idiotic to blame qmail for a problem that existed before qmail
> was installed.
No it's not. If the system(s) before installing qmail didn't run ANY daemons
accessible from the external world they weren't vulnerable for the remote
attacks. Only installing qmail which wasn't armed against such attacks made
it possible to exploit the, apparent, vulnerability.
 
> Of course, as a fraudulent marketing stunt, you carefully wrote _your_
> attack programs so that they would only work after qmail was installed.
> But security is defined by what _can_ be done, not by what _you_ did.
Oh, yes. And making a program immune to some attack _can_ be done, yet it
hadn't been.

marek

  • application/pgp-signature attachment: stored