From owner-freebsd-chat Mon Apr 1 16:22:26 2002 Delivered-To: freebsd-chat@freebsd.org Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by hub.freebsd.org (Postfix) with SMTP id B1A9D37B400 for ; Mon, 1 Apr 2002 16:22:11 -0800 (PST) Received: (qmail 1148 invoked by uid 1001); 2 Apr 2002 00:21:08 -0000 Date: 2 Apr 2002 00:21:08 -0000 Message-ID: <20020402002108.4432.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: chat@freebsd.org Subject: Re: qmail (Was: Maintaining Access Control Lists ) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org rsidd@online.fr writes: > The only one I'm aware of, which Wietse pointed out years ago and > continues to harp on, is the memory exhaustion thing, which in Dan's > opinion is the job of the operating system and not the MTA Yes, I think it's the OS's job. The OS itself agrees with me. The UNIX kernel, with the cooperation of the standard shells, gives the sysadmin configurable, easy-to-use per-process memory rlimits. Reinevnting the same feature by adding separate code to every program to impose artificial limits on every dynamically allocated structure for network data is remarkably bad engineering. Last November, years after I made these comments on my web pages, someone discovered that Venema had forgotten to put an artificial limit on Postfix's dynamically allocated session log. Consequently an attacker could trivially convince Postfix's smtpd to use all available memory. Did Venema scream that Postfix had ``A BUG'' that ``made'' systems ``vulnerable to memory exhaustion attacks''? Did he post an ``exploit'' for this Postfix ``BUG''? Did he try to have Postfix entries added to vulnerability databases? Did he admit that his approach was vastly more complicated and error-prone than system resource limits? No, he didn't. I spend quite a bit of time analyzing system failures and investigating how they could have been prevented by better programming practices--- preferably practices that also save time for the programmers. Frankly, in this case, there's no contest. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message