procmail (in)security

[Matthias Andree]

Todd Underwood <todd-bogofilter at osogrande.com> writes:

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

Todd, what is the problem with Dan's adding a line "you must use
softlimit or similar tools to enforce memory limits"?

There is a difference between remotely-exploitable and
locally-exploitable (no quota) -- socially, and in the particular case
when it comes to how well the OS deals with running out of memory or
with running out of disk space. ENOSPC doesn't bring your system down,
ENOMEM is evil on many systems, not few to memory overcommit (i. e. they
must kill processes run out of memory) and even if they don't
overcommit, it's still a remote DoS.

All it takes to fix this is add a note to the INSTALL document and for
better results, also to the configuration example.

Life with qmail shows how it's done right. Dan needs to fix his qmail
documentation and code.

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

Whether it's qmail's fault or no, is debatable. Fact is that the qmail
installation instructions don't mention with a single word that
something like this must be done. If someone sued Dan for compensation
because of violation of due diligence, things would get really nasty.

>> 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.

At higher rate with operating systems that randomize PIDs from a narrow
PID space, say OpenBSD.

> 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

Yay, that infamous defamation file. The flaw has been fixed 1998-12-24,
the design was fixed one day later -- Dan's rant is outdated since then,
and when asked why he doesn't fix the document for fairness and mention
the bug is fixed, he says that's because Venema hasn't
apologized. Calumny/Defamation and Coercion/"Blackmail".

Note that Postfix 1.0.0 was released on 2001-02-28, long after the
issues have been fixed. Even the previous three pre-stable releases
(19991231, 19990906 and 19990317) didn't have that bug.

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

>From the same POV, DJB's designs are flawed, he reacts to genuine bugs
with shifting responsibility off to somebody or something else and
cannot be trusted. Say the local DoS in daemontools before 0.75, with
any POSIX-compliant system looping tightly when the ./run script failed:
he claimed it was BSDI's fault, it didn't have a return value for sleep
(the fact is that DJB's code didn't check). Would you want to shout that
from the rooftops? The counter argument would be "that's a beta, so
expect trouble".

If Venema is so untrustworthy as you falsely suggest, then why has he
admitted Postfix had a similar SMTPD memory exhaustion bugfix when he
was the first to find the problem? Why did he release bugfixes and
announce them as widely as possible? Why didn't he fix them in silence
and tell nobody?

Why has Dan still not fixed qmail's maildir code? Why has Dan still not
updated his qmail documentation to point to docs/resources.html? He's
not in the position to point his finger towards anybody else, do you think?

> 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?).

It's no more off-topic than MDA issues are. The old DJB disciple game
(Charles Cazabon has mastered this): call others trolls when you're
running out of arguments.

It takes intricate knowledge to run qmail securely, knowledge that
people aren't told when they look at the documents that ship with qmail
and that aren't obvious. I'd bet that more than 50% of the qmail
installations are NOT proof against the security issue.

The bare minimum is running qmail-smtpd from tcpserver with softlimit
enabled, and to use maildrop for maildir delivery. This still doesn't
fix the many other issues mentioned at
http://mandree.home.pages.de/qmail-bugs.html -- admittedly, some
(RFC-2821) weren't issues when qmail was released, but if Dan has no
interest in keeping qmail up to the current standards, he'd better say
so and pass qmail on to trustworthy hands. All it takes is maybe 10
lines of code or 20, and I really hope the net-qmail project (discussed
on the qmail list) flies to address some of the issues. Interestingly
enough, when somebody else (not me) comes up with the same complaint and
the same patch offer, they get their stuff accepted, whereas when I post
the very same observation and fix suggestion, that's called "trolling"
because I don't use qmail. Of course not, because it's not open source
and it has flaws I'm not willing to accomodate.

If you want to discuss my document, please reply in private mail.

I'm not saying Postfix is bug-free, but it has none of the security
issues qmail has or that Postfix had in 1998, and it gets SMTP routing
and RFC-1652 right.

-- 
Matthias Andree