[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    [oss-security] Re: Courier mail server: Write heap overflow in mailbot tool and out of bounds heap r
From:       cve-assign () mitre ! org
Date:       2015-06-29 15:33:44
Message-ID: 20150629153344.89A5A72E070 () smtpvbsrv1 ! mitre ! org
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> The allocation only reserves one byte
> for the zero termination, however it must be the size of the pointer (8
> bytes on 64 bit systems). Therefore it causes a write heap overflow of
> seven zero bytes.

Is this relevant:

  http://googleprojectzero.blogspot.com/2014/08/the-poisoned-nul-byte-2014-edition.html
  "An odd malloc() size will always result in an off-by-one off the
  end being harmless, due to malloc() minimum alignment being
  sizeof(void*)."

?

If there's a malloc implementation that relies on the values of these
seven bytes, then the issue can have a CVE ID.

Also, here's a general (but, in this case, probably unimportant)
comment about whether command-line arguments (for a non-setuid
program) are relevant to CVE inclusion:

> The code parses command line data, therefore it is
> unlikely that any attacker controlled input is affected.

maildrop/testsuite.in gives this example:

  LANG=en_US.utf-8 ./mailbot -T feedback -R abuse -n -N -m testmailbot.msg \
      --feedback-source-ip 127.0.0.1 \
      --feedback-incidents 2 \

However, this type of command line isn't necessarily under the control
of a local user. The purpose of mailbot is to send automatic responses
to e-mail. It seems plausible that the command line would be
dynamically constructed based on information available from an MTA,
e.g., maybe mailbot is called from a .qmail file with something like:

  mailbot -T feedback -R abuse -n -N -m testmailbot.msg \
      --feedback-original-mail-from $QUOTEDSENDER

where $QUOTEDSENDER is derived from the SENDER environment variable
supplied by qmail-local, and the value of SENDER can be set
arbitrarily by a remote SMTP client.

In the current case, it appears that this would not be especially
helpful to exploitation. It looks like the replyfeedback function
would copy the string "original-mail-from" to the heap but would not
copy the sender e-mail address to the heap. However, part of the SMTP
DATA is copied to the heap. Thus, an attacker interested in
controlling heap-memory contents would probably rely on DATA, not an
envelope address that could possibly affect a command line.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)

iQEcBAEBAgAGBQJVkWSDAAoJEKllVAevmvmsAWUH/11sOu9V+jwp0nNZnaJysMHy
xKgBEvQCCUEaIGSIaSH+XNCEzg9R/liwBSwAM8cq+cjto0VmeLjK247AWIau96GK
CxRoA+ukbgTrkGZKYjnPpbAXoQfDTRnK6xMfZUK8f/N8ekDY3a0vcT5vgvX3Da3a
gA3JgUZR86S66LKFt+wzWYoGSoMlAVxmqB8+XlBwjXa6Kk+k0gQK7FfuRtSs+D2o
sqR5LKgG2ZspaZJP5g/t5M56z1guBrhALdzm8PouObUEOTsyeELVIRBTO5a/is5l
/Gydj2BPkFf6XPa7Vl9NEo0+3xpUFI2qgf63JBT6VOpymS2fVNCvQ259/DSFngw=
=AJxg
-----END PGP SIGNATURE-----
[prev in list] [next in list] [prev in thread] [next in thread]