Advisory 15/2004: Cyrus IMAP Server multiple remote vulnerabilities

2004-11-2400:00:00

vulners.com

JSON

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

                       e-matters GmbH
                      www.e-matters.de

                  -= Security  Advisory =-



 Advisory: Cyrus IMAP Server multiple remote vulnerabilities

Release Date: 2004/11/22
Last Modified: 2004/11/22
Author: Stefan Esser [[email protected]]

Application: Cyrus IMAP Server <= 2.2.8
Severity: Several vulnerabilities within Cyrus IMAP Server
allow remote execution of arbitrary code
Risk: Critical
Vendor Status: Vendor has released a bugfixed version.
Reference: http://security.e-matters.de/advisories/152004.html

Overview:

IMAP (Internet Message Access Protocol) is an Internet standards-
track protocol for accessing messages (mail, bboards, news, etc).
The Cyrus IMAP server differs from other IMAP server implementations
in that it is generally intended to be run on sealed servers, where
normal users are not permitted to log in. The mailbox database is
stored in parts of the filesystem that are private to the Cyrus IMAP
system. All user access to mail is through the IMAP, POP3, or KPOP
protocols.

During an audit of imapd several vulnerabilities were discovered
ranging from a standard stack overflow, over out of bounds heap
corruptions, to a bug caused by the use of programming constructs
that are undefined according to the C standard.

All these bugs can lead to remote execution of arbitrary code
depending on the skills of the attacker.

Details:

[01 - IMAPMAGICPLUS preauthentification overflow]

Affected Versions: 2.2.4 - 2.2.8

When the option imapmagicplus is activated on a server the PROXY
and LOGIN commands suffer a standard stack overflow, because the
username is not checked against a maximum length when it is copied
into a temporary stack buffer. This bug is especially dangerous
because it can be triggered before any kind of authentification
took place.

[02 - PARTIAL command out of bounds memory corruption]

Affected Versions: <= 2.2.6 (because unexploitable in 2.2.7, 2.2.8)

Due to a bug within the argument parser of the partial command an
argument like "body[p" will be wrongly detected as "body.peek".
Because of this the bufferposition gets increased by 10 instead of 5
and could therefore point outside the allocated memory buffer for
the rest of the parsing process.
In imapd versions prior to 2.2.7 the handling of "body" or "bodypeek"
arguments was broken so that the terminating ']' got overwritten by
a '\0'. Combined the two problems allow a potential attacker to
overwrite a single byte of malloc() control structures, which leads
to remote code execution if the attacker successfully controls the
heap layout.

[03 - FETCH command out of bounds memory corruption]

Affected Versions: <= 2.2.8

The argument parser of the fetch command suffers a bug very similiar
to the partial command problem. Arguments like "body[p", "binary[p"
or "binary[p" will be wrongly detected and the bufferposition can
point outside of the allocated buffer for the rest of the parsing
process.
When the parser triggers the PARSE_PARTIAL macro after such a
malformed argument was received this can lead to a similiar one byte
memory corruption and allows remote code execution, when the heap
layout was successfully controlled by the attacker.

[04 - APPEND command uses undefined programming construct ]

Affected Version: 2.2.7, 2.2.8

To support MULTIAPPENDS the cmd_append handler uses the global
stage array. This array is one of the things that gets destructed
when the fatal() function is triggered.
When the Cyrus IMAP code adds new entries to this array this is
done with the help of the postfix increment operator in combination
with memory allocation functions. The increment is performed on a
global variable counting the number of allocated stages. Because
the memory allocation function can fail and therefore internally
call fatal() this construct is undefined arcording to ANSI C.
This means that it is not clearly defined if the numstage counter
is already increased when fatal() is called or not. While older
gcc versions increase the counter after the memory allocation
function has returned, on newer gcc versions (3.x) the counter
gets actually increased before.
In such a case the stage destructing process will try to free an
uninitialised and maybe attacker supplied pointer. Which again
could lead to remote code execution. (Because it is hard for an
attacker to let the memory allocation functions fail in the right
moment no PoC code for this problem was designed)

Proof of Concept:

e-matters is not going to release exploits for any of these
vulnerabilities to the public.

Disclosure Timeline:

November 2004 - Sent an email to the Cyrus IMAP team
November 2004 - Got reply from the Cyrus developers and
shared the information with vendor-sec
November 2004 - Cyurs IMAP team contacted vendor-sec with
the official patch
November 2004 - Cyrus IMAP Server 2.2.9 released
November 2004 - Public Disclosure

CVE Information:

The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2004-1011 to issue 01, the name CAN-2004-1012
to issue 02 and the name CAN-2004-1013 to issue 03.

Recommendation:

It is strongly recommended to upgrade to the updated version of
Cyrus IMAP Server as soon as possible because there is no
workaround.

GPG-Key:

http://security.e-matters.de/gpg_key.asc

pub 1024D/3004C4BC 2004-05-17 e-matters GmbH - Securityteam
Key fingerprint = 3FFB 7C86 7BE8 6981 D1DA A71A 6F7D 572D 3004 C4BC

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFBoh47b31XLTAExLwRAvzFAKDbh+j4e7Ik8ZZLLRE2yQgl3JE9DQCg4dFk
Scr8eho+REasVTQgw7tF42E=
=1wJv
-----END PGP SIGNATURE-----