
Qmail is a vector for bash shellshock - kag
http://marc.info/?l=qmail&m=141183309314366&w=2
======
aye
Does this mean he gets the $500?

[http://cr.yp.to/qmail/guarantee.html](http://cr.yp.to/qmail/guarantee.html)

~~~
SwellJoe
Seems unlikely:

"Of course, ``security hole in qmail'' does not include problems outside of
qmail: for example, NFS security problems, TCP/IP security problems, DNS
security problems, bugs in scripts run from .forward files, and operating
system bugs generally. It's silly to blame a problem on qmail if the system
was already vulnerable before qmail was installed!"

But, I think he can take great satisfaction in thinking of a potential hole
that even djb didn't consider. That's pretty impressive (though less
impressive since everybody was sitting around trying to think of places where
a shell might be invoked in non-obvious ways...I spent half an hour talking to
my co-founder and employee during our regular meeting trying to think of ways
our users could be effected outside of the already discussed ways, and we
spent quite a bit of time testing various theories; one of the vectors we
discussed was procmail being called by Postfix).

Edit: And, just in case anyone was wondering, Wietse seems to have considered
the environment variable problem, and took measures to prevent exploits in
Postfix, so it does not _seem_ to be exploitable by Shellshock, even when
calling out to procmail.

~~~
drinchev
It's really incredible how much time qmail has been alive without any security
hole bugs and still distributions use sendmail by default.

~~~
SwellJoe
Distributions _couldn 't_ distribute qmail in the past because the license
agreement made it impossible (or at least required such stupid things that no
one in their right mind would do so). Its license became public domain in
2007, and I suppose would allow distributors to do sane things with the
packages, but Postfix had already supplanted Sendmail as the preferred MTA on
Linux and nobody really cared about qmail...since qmail isn't demonstrably
more secure than Postfix (and both are maintained by well-known and well-
respected security researchers).

And, to be clear, most distributions no longer use Sendmail as the default.
Postfix is the default on RHEL/CentOS/Scientific Linux. exim was the default
in Debian for many many years, not sure if it still is. Postfix is the default
on Ubuntu, I believe. I can't think of any distros for which sendmail is the
default MTA.

~~~
tptacek
Postfix has a marginally poorer security track record than qmail does, but
Postfix is the saner default choice for normal users. Both of them are head
and shoulders better than _every_ other MTA.

~~~
SwellJoe
I would argue that this is at least partly because Postfix has a larger
surface area...it does more, and thus, should reasonably be expected to have
had a few more run-ins with security problems. Unless things have changed a
lot over the past several years, qmail isn't capable of even functioning in a
number of modern email environments, without significant patching.

Once qmail has been patched up to modern MTA standards, it no longer has the
pedigree of being built and maintained by djb. I don't know the people who
maintain the huge patch sets for qmail...maybe they're good. I know Wietse is
more than competent.

But, that may be what you're getting at with "Postfix is the saner default
choice for normal users". We support all of them (Sendmail, Postfix, qmail,
and exim) in Virtualmin to varying degrees, but we configure Postfix, by
default, and very strongly encourage its use over the alternatives (mostly
because we know Postfix so much better, and because so many more people use
it). About 95% of our users stick with Postfix, though we do have some users
of all of the others.

------
baudehlo
Another great reason to have a good filtering proxy in front of qmail, such as
Qpsmtpd or my own Haraka. Both validate MAIL FROM and RCPT TO commands to
ensure they are valid according to RFC 5321 (the newer version of RFC 2821),
and will reject any command not complying with those specifications. Qmail
alone is just too fragile.

------
Qantourisc
I would still argue the bug is not entirely bash it's fault. A feature that
causes security bugs, is imo the fault of the application using a program that
has these feature. It's like not escaping strings/CLI-commands/SQL commands.

Or did I miss something where this bash feature is not suppose to work under
all circumstances ?

~~~
cnvogel
It's certainly bash's fault!

First, and foremost: user-provided data has been passed in environment
variables since the stone-age. That's why, for example, we explicitly guard
against LD_PRELOAD'ing a shared library into a suid-binary... But it was
common knowledge, that this selection of dangerous/benign variables can be
made based on the NAME of the variable, NOT the CONTENT. And bash basically
calls eval(name+' '+env[name]) for every variable containing the magic
substring.

Imagine any of your other favourite script languages scanning random places
for "things that look as if they could be imported/included/executed"... and
tell me that this is a smart thing to do.

The second mistake was to not just create a function-definition inside the
currently running program, but to actually eval the complete content of the
variable. If bash would just postpone the evaluation of the function to the
point in time where it's actually called, no one would be bothered, because
the script would have to be tricked into executing a command called
"RECIPIENT" (or DHCP_OPTION_1234, or COOKIE, ...).

------
jedisct1
This also applies to pure-ftpd when using an external authentication module:
[https://gist.github.com/jedisct1/88c62ee34e6fa92c31dc](https://gist.github.com/jedisct1/88c62ee34e6fa92c31dc)

------
jingo
I thought of mentioning this - specifically, people who use the .qmail file in
the mail directory.

Anyway, djb uses shell scripts liberally in his software projects but I've
never seen him include a shell script with Bash-isms. That tells me he does
not _assume_ his users to be using Bash.

Everyone has a choice. And if you are trying to practice "secure" computing,
then some choices are wiser than others.

If a user thinks Bash is the bee's knees, then djb's software will work just
fine; it does not discriminate against that user.

But if a user does not use Bash, and prefers to use a more simple, POSIX-like
shell, that will work just fine too.

This is purely my opinion but unlike so many other software authors, djb does
not appear to discriminate against people who prefer simple software systems
that are not loaded with "features"; he does not intentionally or
unintentionally force them to embrace complexity or be ignored.

That said, it also appears he is a self-professed Ubuntu user these days. For
example, read his latest blog.cr.yp.to entry.

I do not understand how he can tolerate the amount of complexity in Ubuntu
that is on by default and hidden from the user. But maybe I'm just too stupid
to understand.

There seems to be a choice of at least two options:

1\. keep Bash installed and try to determine every possible untrusted user
input accepting or internet facing application that might at some time use the
system shell, or

2\. uninstall Bash and use a barebones POSIX-like shell without extra
features.

Preserving the continued use of shell scripts with Bash-isms as a reason to
choose option #1 does not make sense to me. Maybe there are other "compelling"
reasons? (Interactive shell features?) With a little effort, these Bash script
authors could probably learn to write scripts that do not use Bash-isms. Is
that really so terrible as to make option #2 untenable?

If there are enormous Bash scripts being relied on in security senstive
settings which "cannot" be rewritten in POSIX shell, then maybe the mistake
was ever "deploying" such monstrosities in the first place.

Shell scripts, no matter what shell, should always be relatively small
assuming the author has any common sense.

~~~
kag
>> 2\. uninstall Bash and use a barebones POSIX-like shell without extra
features.

It's not that simple. True, djb doesn't say you need bash. But qmail uses
/bin/sh (not configurable without recompiling). Try changing /bin/sh to, say,
ksh on Ubuntu and watch as nothing else on the system works. The distributions
make use of shell-specific features.

~~~
comex
Doesn't Ubuntu ship dash as /bin/sh already? dash isn't ksh, but it is
minimalist (and not vulnerable to this).

~~~
kag
Yeah, it does. I meant Debian, but it looks like Debian changed too. My bad.
My point was that changing /bin/sh from the distro-chosen one to something
else _could_ cause problems.

------
regularfry
This would also affect Exim's pipe filter if it accepted '()' in author names.

~~~
baudehlo
That depends on whether Exim validates MAIL FROM according to RFC 5321 or not.
I would like to assume it does. Rudimentary testing on cam.ac.uk (where Exim
was developed) shows that it does, so Exim is not vulnerable as far as I can
tell.

