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" . > > He hasn't awarded the bounty yet, despite several > vulnerabilities found by us in 2005  and in 2020  > 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 , 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. > >  https://cr.yp.to/qmail/guarantee.html >  http://www.guninski.com/where_do_you_want_billg_to_go_today_4.html >  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.