[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200522121750.GA24868@openwall.com>
Date: Fri, 22 May 2020 14:17:50 +0200
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: Short notes on qmail security guarantee
Hi Georgi,
I am replying not to argue and not to cast a vote, but rather to bring
up a variety of thoughts and generalizations that I think are relevant
beyond qmail. I think other projects can learn from this. Thus, I try
to comment in a way that isn't biased by my own point of view on whether
a bug bounty should have been awarded or not.
On Thu, May 21, 2020 at 12:56:23PM +0300, Georgi Guninski wrote:
> From my blog:
> https://j.ludost.net/blog/archives/2020/05/21/short_notes_on_qmail_security_guarantee/index.html
>
> Short notes on qmail security guarantee
>
> Disclaimer: written in hurry, could be wrong.
I think some of what you wrote is right, but some is wrong. See below.
> djb offers monetary bounty for verifiable qmail exploit,
> called "qmail security guarantee" [1].
>
> He hasn't awarded the bounty yet, despite several
> vulnerabilities found by us in 2005 [2] and in 2020 [3]
> Qualys discovered that at least one of the vulnerabilities
> works in default qmail install.
>
> Both of these vulnerabilities require more that 4GB memory.
I assume "both" refers to both publications, not "vulnerabilities".
Qualys' contribution is primarily in finding a practical way to exploit
one of the vulnerabilities you had found in 2005.
BTW, as I understand, qmail misbehavior without a known security impact
can also be caused by data sizes moderately smaller than that.
> djb's main argument is that nobody gives a lot of memory
> to qmail-smtpd (and as djb might missed to all other
> qmail- components).
The Qualys advisory quotes DJB saying "I run each qmail service under
softlimit -m12345678", so apparently he did not miss that for his own
use. The issue is what recommendation was (not) provided publicly.
> We believe that the claim of memory limit is wrong for
> the following reasons:
>
> 1. qmail's install documentation doesn't mention memory limits
I've grepped the qmail-1.03 tree for the word "limit", and yes - I can't
find a mention of memory limits being required to use qmail safely. The
only(?) mention is in [1], and was apparently added after your findings
in 2005:
"In May 2005, Georgi Guninski claimed that some potential 64-bit
portability problems allowed a ``remote exploit in qmail-smtpd.'' This
claim is denied. Nobody gives gigabytes of memory to each qmail-smtpd
process, so there is no problem with qmail's assumption that allocated
array lengths fit comfortably into 32 bits."
This is denial of a claim rather than "install documentation", and it
doesn't mention components other than qmail-smtpd.
I also searched the qmail homepage https://cr.yp.to/qmail.html for the
word "limit", and the only memory-related mentions are:
"qmail allows inconceivably gigantic mailing lists. No random limits."
"header line length limited only by memory"
This doesn't say that a memory limit should to be imposed externally.
[ On a related note, regarding mailing lists: ezmlm (and ezmlm-idx) uses
the same memory and string allocation primitives as qmail, and thus, as
I understand, to use it safely a memory limit should be imposed
externally. When run via qmail, the limit gets inherited from qmail
(where it should be imposed by qmail's startup scripts anyway, as we now
know). However, if ezmlm(-idx) is ever used other than with qmail
(which is tricky and uncommon, but a quick web search shows that people
have been trying), its integer overflows may pose a separate problem
needing addressing with external memory limits in that setup as well. ]
> 2. Qualys claims that their exploit works on the default
> install of all packages they have seen
Per my reading, no, their tested exploit is for Debian 10's package of
qmail, but the described exploitation technique should work on a wider
range of packages. The technique is specific to glibc, but different
techniques might exist for other systems.
> (and all package maintainers have missed memory limits).
This is about right. Quoting the Qualys advisory, "we investigated many
qmail packages, and *all* of them limit qmail-smtpd's memory, but *none*
of them limits qmail-local's memory".
> 3. djb shouldn't assume that 4-8GB will be enough for the
> normal functioning of qmail. In theory libc might require
> more RAM in the future. Currently mobile phones have
> 32+GB RAM and there is clear trend in grow of RAM.
[ First the digression:
The factually wrong part is about mobile phones, where as far as I could
find current RAM sizes are up to 8 GB (possibly giving somewhat more
virtual memory than that with swap on zram?), but of course they will
reach 32+ GB RAM eventually. This is irrelevant for qmail, but
relevantly RAM sizes on servers also grow, and are already this high.
Also, while "in theory" a libc can allocate gigabytes of memory, that
would be a major problem on its own. Slightly less unrealistically, it
could allocate this much address space (like we see e.g. Java do), which
would make it tough to use system-provided resource limits (where the
only reliably working limit is in practice RLIMIT_AS). But that's also
currently in the imaginary territory, and I hope it stays there. ]
Now what's more relevant:
This is the usual debate about (lack of) arbitrary limits. Part of
qmail design was to avoid artificial memory limits, and this is why some
systems ended up being vulnerable to code execution.
Arguably, it's the sort of thinking that artificial limits are bad "in
theory" that led us to the vulnerabilities. Sure a few GB was far more
than "enough for the normal functioning of qmail" when it was written
and so far. That's ~25 years, an impressive lifetime for a program
that's been effectively abandoned upstream for 20+ years.
Writing code that avoids artificial limits yet is safe, is hard. One
way to do it is to avoid artificial limits throughout the code, but then
impose them at a higher level, where they can be adjusted easily. One
such higher level is the operating system, but that makes the program's
security dependent on its environment in this extra way (beyond many
others) and with greater risk impact (worse than DoS). Arguably, this
makes the program unnecessarily fragile. Another higher level would be
within the program, like we see in Qualys' patch for qmail now. This
reduces the dependency of the program's security on its environment.
Speaking of memory allocation sizes in particular, modern best practice
is to use data types that "can't" overflow on 64-bit systems. In C that
would be size_t (and ssize_t where appropriate). However, they're
32-bit on 32-bit systems (and even if we were to use uint64_t, it'd be
mishandled on malloc() and such), and allowing arbitrarily large
allocations everywhere (up to system-imposed limits) may result in more
or/and worse opportunities for DoS attacks (e.g., crashing a service
instead of denying one request). So this best practice does not
eliminate the need for artificial memory limits imposed somewhere.
> 4. By common sense, distributing software with known vulnerabilities
> is bad practice.
Yet it does reasonably happen for abandoned/EOL'ed software, or for
vulnerabilities of low to moderate severity. Arguably, part of the
problem may be that qmail was never officially abandoned/EOL'ed
upstream, nor its security guarantee officially withdrawn.
> 5. AFAIK djb teaches students about coding and security and he
> better lead by example of good coding.
>
> [1] https://cr.yp.to/qmail/guarantee.html
> [2] http://www.guninski.com/where_do_you_want_billg_to_go_today_4.html
> [3] https://www.openwall.com/lists/oss-security/2020/05/19/8
Alexander
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
