Scriblings Of A GEEK

Cyrus IMAP Server multiple remote vulnerabilities

Multiple venurabilities have been found in the Cyrus IMAP server.

Fot those who dunn know what is the Cyrus IMAP server a lill into on it below :

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.

The venrabilities are as below :

[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)

CVE Information

The Common Vulnerabilities and Exposures project 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.

This venurability is picked up from the e-matter security and GLSA.


Nitin

posted by Nitin @ 11/26/2004 09:55:00 AM