what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

cryus.imap.2.2.8.txt

cryus.imap.2.2.8.txt
Posted Nov 24, 2004
Authored by Stefan Esser | Site security.e-matters.de

Cryus v2.2.8 and below contains four remote vulnerabilities, including one which is pre-authentication. Fix available here.

tags | advisory, remote, vulnerability
advisories | CVE-2004-1011, CVE-2004-1012, CVE-2004-1013
SHA-256 | 54d472e1537f333c599a3d7c14b3c297aa87884e8449678168feafb1d6d5a268

cryus.imap.2.2.8.txt

Change Mirror Download
   Release Date: 2004/11/22
Author: [4]Stefan Esser [s.esser@ematters.de]
Application: Cyrus IMAP Server <= 2.2.8
Severity: Several vulnerabilities within Cyrus IMAP Server allow
remote execution of arbitrary code
Risk: Critical
Reference: [5]http://security.e-matters.de/advisories/152004.html
Last Modified: 2004/11/22




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
06. Nov 2004 Sent an email to the Cyrus IMAP team
11. Nov 2004 Got reply from the Cyrus developers and shared the
information with vendor-sec
17. Nov 2004 Cyurs IMAP team contacted vendor-sec with the official
patch
22. Nov 2004 Cyrus IMAP Server 2.2.9 released
22. Nov 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
[6][DOWNLOAD NEW GPG-KEY]
pub 1024D/3004C4BC 2004-05-17 e-matters GmbH - Securityteam
Key fingerprint = 3FFB 7C86 7BE8 6981 D1DA A71A 6F7D 572D 3004 C4BC



Copyright 2004 [7]Stefan Esser. All rights reserved.
Login or Register to add favorites

File Archive:

December 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Dec 1st
    0 Files
  • 2
    Dec 2nd
    41 Files
  • 3
    Dec 3rd
    0 Files
  • 4
    Dec 4th
    0 Files
  • 5
    Dec 5th
    0 Files
  • 6
    Dec 6th
    0 Files
  • 7
    Dec 7th
    0 Files
  • 8
    Dec 8th
    0 Files
  • 9
    Dec 9th
    0 Files
  • 10
    Dec 10th
    0 Files
  • 11
    Dec 11th
    0 Files
  • 12
    Dec 12th
    0 Files
  • 13
    Dec 13th
    0 Files
  • 14
    Dec 14th
    0 Files
  • 15
    Dec 15th
    0 Files
  • 16
    Dec 16th
    0 Files
  • 17
    Dec 17th
    0 Files
  • 18
    Dec 18th
    0 Files
  • 19
    Dec 19th
    0 Files
  • 20
    Dec 20th
    0 Files
  • 21
    Dec 21st
    0 Files
  • 22
    Dec 22nd
    0 Files
  • 23
    Dec 23rd
    0 Files
  • 24
    Dec 24th
    0 Files
  • 25
    Dec 25th
    0 Files
  • 26
    Dec 26th
    0 Files
  • 27
    Dec 27th
    0 Files
  • 28
    Dec 28th
    0 Files
  • 29
    Dec 29th
    0 Files
  • 30
    Dec 30th
    0 Files
  • 31
    Dec 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2024 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close