Mailing List Archive

qmail and qmail-verify vulnerabilities
Hi,

There's a security advisory just been released for qmail and qmail-verify.
Although the main qmail exploit looks non-trivial, it's still of concern. The
good news is that the main exploit is mitigated with a small patch to alloc.c,
as described in the advisory. Here's the advisory,

https://www.qualys.com/2020/05/19/cve-2005-1513/remote-code-execution-qmail.txt

Re. my qmail-verify patchset, this had 2 faults/vulnerabilities which the
advisory describes as "minor", which are fixed in the new version of qmail-
verify v1.50 (the fix is to incorporate the code in the advisory above; I've
also made some corrections to the qmail-verify man page),

https://free.acrconsulting.co.uk/email/qmail-verify.html

I believe that updated 'qmail' packages for Debian and Ubuntu are in
preparation that should incorporate the fixes proposed in the advisory.

Kind regards,

Andrew Richards.
--
====================================================================
* Custom email solutions * Systems Administration * Networking
http://www.acrconsulting.co.uk/
====================================================================
Re: qmail and qmail-verify vulnerabilities [ In reply to ]
Thus said "Andrew Richards" on 19 May 2020 18:45:43 +0100:

> There's a security advisory just been released for qmail and
> qmail-verify. Although the main qmail exploit looks non-trivial, it's
> still of concern.

Not only does it look non-trivial, it seems like it isn't possible if
one is limiting qmail-smtpd both via databytes and softlimit. Also, how
is one to exploit qmail-local via qmail-smtpd if qmail-smtpd has said
limits in place? Is it possible to inject via qmail-smtpd a message that
avoids the limits but then somehow triggers allocation problems in
qmail-local? Or is the qmail-local exploit only successful via local
injection (e.g. /var/qmail/bin/sendmail or /var/qmail/bin/qmail-inject)?

Thank you,

Andy
--
TAI64 timestamp: 400000005ec498c3
Re: qmail and qmail-verify vulnerabilities [ In reply to ]
On Wednesday, 20 May 2020 03:40:30 BST Andy Bradford wrote:
> Thus said "Andrew Richards" on 19 May 2020 18:45:43 +0100:
> > There's a security advisory just been released for qmail and
> > qmail-verify. Although the main qmail exploit looks non-trivial, it's
> > still of concern.
>
> Not only does it look non-trivial, it seems like it isn't possible if
> one is limiting qmail-smtpd both via databytes and softlimit. Also, how
> is one to exploit qmail-local via qmail-smtpd if qmail-smtpd has said
> limits in place? Is it possible to inject via qmail-smtpd a message that
> avoids the limits but then somehow triggers allocation problems in
> qmail-local? Or is the qmail-local exploit only successful via local
> injection (e.g. /var/qmail/bin/sendmail or /var/qmail/bin/qmail-inject)?

As you mention, if you've got softlimit and/or databytes / DATABYTES set then
that prevents most of the possible attack routes in the advisory, particularly
those via qmail-smtpd, and those steps don't require updating qmail itself.
The size of the message an attacker would need to send (> 4GB) seems to be
absurdly large, but given that 10 Gbps is not uncommon as a networking speed
(within a data centre for example), absurdly large emails are possible.

The sytems that seem to be most at risk here would be those running qmail
without softlimit/databytes protection.

From the advisory itself:

About our new discovery, Daniel J. Bernstein issues the following
statement:

"https://cr.yp.to/qmail/guarantee.html has for many years mentioned
qmail's assumption that allocated array lengths fit comfortably into
32 bits. I run each qmail service under softlimit -m12345678, and I
recommend the same for other installations."

Personally I'd consider,

- The key limit in the advisory seems to be 4GB, although "[roughly]"
512MB, 576MB are also mentioned. With softlimit, databytes and
DATABYTES taking integer values, those convert to 4294967296,
536870912, 603979776 resp.: Play safe and choose a number lower
(probably a lot lower) than at least the first if not all 3 of those,
but big enough for the largest message your system should handle;

- Check that your qmail services have softlimit enabled
taking the above step into account re. what limit you choose.

- Same for control/databytes.

- Restart/reload qmail etc. for those changed settings to take effect

- Apply the patches to qmail (alloc.c) and qmail-verify (for Debian/Ubuntu
this may just mean installing the updated package, although that hasn't
appeared yet).

As you and indeed DJB point out, softlimit/databytes is probably enough for
most systems; updating/patching adds extra certainty.

cheers,

Andrew.
--
====================================================================
* Custom email solutions * Systems Administration * Networking
http://www.acrconsulting.co.uk/
====================================================================
Re: qmail and qmail-verify vulnerabilities [ In reply to ]
hi all,

also - 32 bit binaries should not be affected (scream if I'm wrong).

Regards,

Michael Brunnbauer

On Wed, May 20, 2020 at 01:11:54PM +0100, Andrew Richards wrote:
> On Wednesday, 20 May 2020 03:40:30 BST Andy Bradford wrote:
> > Thus said "Andrew Richards" on 19 May 2020 18:45:43 +0100:
> > > There's a security advisory just been released for qmail and
> > > qmail-verify. Although the main qmail exploit looks non-trivial, it's
> > > still of concern.
> >
> > Not only does it look non-trivial, it seems like it isn't possible if
> > one is limiting qmail-smtpd both via databytes and softlimit. Also, how
> > is one to exploit qmail-local via qmail-smtpd if qmail-smtpd has said
> > limits in place? Is it possible to inject via qmail-smtpd a message that
> > avoids the limits but then somehow triggers allocation problems in
> > qmail-local? Or is the qmail-local exploit only successful via local
> > injection (e.g. /var/qmail/bin/sendmail or /var/qmail/bin/qmail-inject)?
>
> As you mention, if you've got softlimit and/or databytes / DATABYTES set then
> that prevents most of the possible attack routes in the advisory, particularly
> those via qmail-smtpd, and those steps don't require updating qmail itself.
> The size of the message an attacker would need to send (> 4GB) seems to be
> absurdly large, but given that 10 Gbps is not uncommon as a networking speed
> (within a data centre for example), absurdly large emails are possible.
>
> The sytems that seem to be most at risk here would be those running qmail
> without softlimit/databytes protection.
>
> >From the advisory itself:
>
> About our new discovery, Daniel J. Bernstein issues the following
> statement:
>
> "https://cr.yp.to/qmail/guarantee.html has for many years mentioned
> qmail's assumption that allocated array lengths fit comfortably into
> 32 bits. I run each qmail service under softlimit -m12345678, and I
> recommend the same for other installations."
>
> Personally I'd consider,
>
> - The key limit in the advisory seems to be 4GB, although "[roughly]"
> 512MB, 576MB are also mentioned. With softlimit, databytes and
> DATABYTES taking integer values, those convert to 4294967296,
> 536870912, 603979776 resp.: Play safe and choose a number lower
> (probably a lot lower) than at least the first if not all 3 of those,
> but big enough for the largest message your system should handle;
>
> - Check that your qmail services have softlimit enabled
> taking the above step into account re. what limit you choose.
>
> - Same for control/databytes.
>
> - Restart/reload qmail etc. for those changed settings to take effect
>
> - Apply the patches to qmail (alloc.c) and qmail-verify (for Debian/Ubuntu
> this may just mean installing the updated package, although that hasn't
> appeared yet).
>
> As you and indeed DJB point out, softlimit/databytes is probably enough for
> most systems; updating/patching adds extra certainty.
>
> cheers,
>
> Andrew.
> --
> ====================================================================
> * Custom email solutions * Systems Administration * Networking
> http://www.acrconsulting.co.uk/
> ====================================================================

--
++ Michael Brunnbauer
++ netEstate GmbH
++ Geisenhausener Stra?e 11a
++ 81379 M?nchen
++ Tel +49 89 32 19 77 80
++ Fax +49 89 32 19 77 89
++ E-Mail brunni@netestate.de
++ https://www.netestate.de/
++
++ Sitz: M?nchen, HRB Nr.142452 (Handelsregister B M?nchen)
++ USt-IdNr. DE221033342
++ Gesch?ftsf?hrer: Michael Brunnbauer, Franz Brunnbauer
++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
Re: qmail and qmail-verify vulnerabilities [ In reply to ]
On Wednesday, 20 May 2020 14:20:19 BST Michael Brunnbauer wrote:

> also - 32 bit binaries should not be affected (scream if I'm wrong).

I think that's right, but having a softlimit set is still a good idea.

> ...
--
====================================================================
* Custom email solutions * Systems Administration * Networking
http://www.acrconsulting.co.uk/
====================================================================
Re: qmail and qmail-verify vulnerabilities [ In reply to ]
On Wednesday, 20 May 2020 13:11:54 BST Andrew Richards wrote:
> On Wednesday, 20 May 2020 03:40:30 BST Andy Bradford wrote:
> > Thus said "Andrew Richards" on 19 May 2020 18:45:43 +0100:

..
> ...Play safe and choose a number lower
> (probably a lot lower) than at least the first if not all 3 of those,
> but big enough for the largest message your system should handle;
>
> - Check that your qmail services have softlimit enabled
> taking the above step into account re. what limit you choose.
>
> - Same for control/databytes.

I may have created some ambiguity:

- databytes is the "Maximum number of bytes allowed in a message, or 0
for no limit"

- softlimit values are for various system limits including relating to
memory used by a [e.g. qmail-smtpd] process.

So these values may well be and are typically different. Have a read of the
softlimit man page for more (I don't understand memory use by processes well
enough to try and explain here, someone else might like to have a go?).

cheers,

Andrew.
--
====================================================================
* Custom email solutions * Systems Administration * Networking
http://www.acrconsulting.co.uk/
====================================================================
Re: qmail and qmail-verify vulnerabilities [ In reply to ]
Andrew Richards <ar-djblists@acrconsulting.co.uk> wrote:
>
> - [set a value in] control/databytes.
>
> - Restart/reload qmail etc. for those changed settings to take effect

Nit: you don't have to restart anything for databytes to take effect;
qmail-smtpd reads its control files on every invocation. Just

echo 25000000 >/var/qmail/control/databytes

(pick a value) is sufficient.

Applying softlimit settings to the services, on the other hand, probably does
require restarting them.

Charles
--
--------------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at: http://pyropus.ca/software/
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
--------------------------------------------------------------------------