procmail (in)security

[Todd Underwood]

matthias, all,

On Mon, 10 Mar 2003, Matthias Andree wrote:

> Todd Underwood <todd-bogofilter at osogrande.com> writes:
> 
> > since i run qmail primarily for its security properties, introducing 
> > something as complex and with such a poor security record as procmail is 
> > definitely a no-no.
> 
> As a side note, when talking about qmail and security: The default qmail
> 1.03 install has always been prone to a memory exhaustion exploit (now
> the fifth year...) via qmail-smtpd. Dan later stated it was the admin's
> task to put proper resource limits in place -- however the qmail
> documentation doesn't tell you that.

this is, of course, crap.  it's off-topic crap, moreover.  best of all, 
matthias knows it's crap.

the issue is very simple and straightforward:  if you let untrusted people 
connect to a network port running a service and you impose *no* controls 
on how much memory those people can use (or how many processes they start, 
or how many file handles they open, etc.) then they might use lots of 
memory (or file handles or whatever).  if you run an operating system 
(like Solaris, or Linux, or xBSD, or even Windows!) that lets you restrict 
the amount of disk space or memory or processes that a given network 
process can use, you should probably do that.

matthias's implication that this is qmail's fault is silly.

the qmail install doesn't warn you that if all your local users have no 
quotas and they receive a lot of mail, they might fill up a partition.

the qmail install doesn't warn you that if you impose no per-user process 
restrictions then local users can create unlimited numbers of pop 
daemon's.  

in fact, even if you're not using qmail local users can fill up your 
filesystem if you don't have quotas!  qmail doesn't warn of this at all.

in fact, if you impose no logfile recycling restrictions, a remote user 
can fill up your /var partition simply by requesting a massive number of 
web pages from your apache server.  the apache install doesn't warn you of 
this at all.

this is just silly.

see:

http://cr.yp.to/docs/resources.html

for a more concrete and better description of the problem.

> Also, qmail's maildir delivery code was found to be faulty quite some
> time ago (Early 2001 IIRC) and again in a wider discussion earlier this
> year; it is not robust and can cause name collisions that result in mail
> loss later unless you only access with qmail-pop3d.

this one is actually an interesting condition.  race with super 
high-volume mail delivery and super high-volume mail checking (it requires 
a PID recycle or two), but it is theoretically possible.  

see:  
http://www.ornl.gov/cts/archives/mailing-lists/qmail/2003/01/msg00412.html
for the discussion.

> If you want a secure and robust mailer, consider Postfix. It has indeed
> had a similar fault to qmail's, but that was fixed long ago; the maildir
> delivery code has been fixed, and Postfix supports chrooting to some
> extent and is way faster. The drawback is that Postfix doesn't read
> .qmail files. It understands ~/.forward+extension files (with one level
> of extension) if the admin configured recipient_delimiter=+ though.

postfix was proven broken (not in coding but in design) within days of its 
release as the "IBM Secure Mailer".

see:

http://cr.yp.to/maildisasters/postfix.html

venema's designs are flawed, he reacts to genuine security problems in 
them with rancor and is therefore not to be trusted.

in any case, all of this is still off-topic. (i thought procmail security 
was on-topic since people were talking about how they use it and i was 
asking about how to get around needing it, but which MTA is better is 
definitely straying, don't you think?).

t.

-- 

todd underwood, sr. vp & cto
oso grande technologies, inc.
todd at osogrande.com

"The people never give up their liberties but under some delusion."
  	    --Edmund Burke, Speech at County Meeting of Bucks, 1784.