Bug 139382 - CAN-2004-1011 Multiple issues in cyrus-imapd (CAN-2004-1012 CAN-2004-1013 CAN-2004-1015)
Summary: CAN-2004-1011 Multiple issues in cyrus-imapd (CAN-2004-1012 CAN-2004-1013 CAN...
Alias: None
Product: Fedora
Classification: Fedora
Component: cyrus-imapd   
(Show other bugs)
Version: 3
Hardware: All Linux
Target Milestone: ---
Assignee: John Dennis
QA Contact:
Keywords: Security
: 140617 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-15 17:54 UTC by Josh Bressers
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-07 10:43:22 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Proposed patch for this issue. (2.46 KB, patch)
2004-11-15 18:00 UTC, Josh Bressers
no flags Details | Diff
Patch from upstream. (3.04 KB, patch)
2004-11-18 02:07 UTC, Josh Bressers
no flags Details | Diff
Latest patch for this issue plus a bit more. (3.89 KB, patch)
2004-11-23 14:47 UTC, Josh Bressers
no flags Details | Diff

Description Josh Bressers 2004-11-15 17:54:12 UTC
[01 - Cyrus IMAP Server - IMAPMAGICPLUS preauthentification overflow]

Affected Versions:
    2.2.4 - 2.2.8

    When the option imapmagicplus is activated LOGIN and some other
    commands do not properly check the length of the supplied username
    before copying it into a stack buffer. This results in an easy to
    exploit stack overflow.


    imap/imapd.c - line 290

    static int imapd_canon_user(sasl_conn_t *conn, void *context,
                    const char *user, unsigned ulen,
                    unsigned flags, const char *user_realm,
        char userbuf[MAX_MAILBOX_NAME+1], *p;
        size_t n;
        int r;

        if (!ulen) ulen = strlen(user);

        if (config_getswitch(IMAPOPT_IMAPMAGICPLUS)) {
        /* make a working copy of the auth[z]id */

        memcpy(userbuf, user, ulen);        <---- copy without check

        userbuf[ulen] = '\0';
        user = userbuf;

    imap/imapd.c - line 348

    static int imapd_proxy_policy(sasl_conn_t *conn,
                  void *context,
                  const char *requested_user, unsigned rlen,
                  const char *auth_identity, unsigned alen,
                  const char *def_realm,
                  unsigned urlen,
                  struct propctx *propctx)
        if (config_getswitch(IMAPOPT_IMAPMAGICPLUS)) {
        char userbuf[MAX_MAILBOX_NAME+1], *p;
        size_t n;

        /* make a working copy of the authzid */
        if (!rlen) rlen = strlen(requested_user);

        memcpy(userbuf, requested_user, rlen);  <-- copy without check

     userbuf[rlen] = '\0';

[02 - Cyrus IMAP Server - PARTIAL out of bounds memory corruption]

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

    In imapd versions prior to 2.2.7 the cmd_partial function did
    overwrite the closing '[' bracket of a body/body.peek entity.
    Due to a bug in the parser it is possible that this overwrite
    takes place outside of the allocated buffer. This is f.e. the
    case when the parser hits a "body[p" in this case the pointer
    is moved 10 forward which could lead to bypassing the end of
    the allocated buffer and could therefore result in remote
    code execution through a one byte heap control structure
    memory corruption


    imap/imapd.c - line 3157  (the wrong one bye write is fixed in 3172)

    void cmd_partial(const char *tag, const char *msgno, char *data,
             const char *start, const char *count)
        else if (!strncmp(data, "body[", 5) ||
             !strncmp(data, "body.peek[", 10)) {
        p = section = data + 5;
        if (*p == 'p') {
            p = section += 5;  <--- here we could leave the buffer

[03 - Cyrus IMAP Server - FETCH out of bounds memory corruption]

Affected Versions:
    <= 2.2.8

    Similiar to the PARTIAL out of bounds memory corruption the parser
    of the FETCH command may leave the allocated buffer when it hits a
    "BODY[P", "BINARY[S" or a "BINARY[P". The execution of the
    PARSE_PARTIAL macro after such an incident can lead to the same
    one byte memory corruption on the heap that could lead to remote
    code execution


    imap/imapd.c - lines 2774, 2777, 2817

    void cmd_fetch(char *tag, char *sequence, int usinguid)
        char *cmd = usinguid ? "UID Fetch" : "Fetch";
        static struct buf fetchatt, fieldname;
       case 'B':
            if (!strncmp(fetchatt.s, "BINARY[", 7) ||
            !strncmp(fetchatt.s, "BINARY.PEEK[", 12) ||
            !strncmp(fetchatt.s, "BINARY.SIZE[", 12)) {
            int binsize = 0;

            p = section = fetchatt.s + 7;
            if (*p == 'P') {
                p = section += 5;   <--- possible break here
            else if (*p == 'S') {
                p = section += 5;   <--- another break here
                binsize = 1;
             else if (!strncmp(fetchatt.s, "BODY[", 5) ||
                  !strncmp(fetchatt.s, "BODY.PEEK[", 10)) {
             p = section = fetchatt.s + 5;
             if (*p == 'P') {
                 p = section += 5;   <--- and again here

Comment 1 Josh Bressers 2004-11-15 17:55:29 UTC
This issue is currently under embargo.  The exact release date is not
yet known, but it is expected to be soon as the cyrus-imapd upstream
wishes to release sometime this week.

Developer please follow guidelines for creating an embargoed Fedora
branch before commmitting any fix.

Comment 2 Josh Bressers 2004-11-15 18:00:24 UTC
Created attachment 106730 [details]
Proposed patch for this issue.

Comment 4 Josh Bressers 2004-11-18 02:07:41 UTC
Created attachment 106927 [details]
Patch from upstream.

According to upstream:

2.2.9 will be in testing by the end of the week and if no problems are
found will be released Monday.

Comment 8 Josh Bressers 2004-11-23 14:47:30 UTC
Created attachment 107302 [details]
Latest patch for this issue plus a bit more.

It has been discovered that a very similar buffer overflow exists in Proxyd.c

This patch contains the full complete fix for this issue.

Comment 9 Josh Bressers 2004-11-23 15:00:04 UTC
Upstream plans to release version 2.2.10 later today to address these
new issues.

Comment 12 John Dennis 2004-11-23 22:41:54 UTC
*** Bug 140617 has been marked as a duplicate of this bug. ***

Comment 13 Mark J. Cox 2004-11-24 09:59:39 UTC
Removing embargo.  Marked demo as private.

Comment 14 John Dennis 2004-11-24 17:54:01 UTC
FYI: cyrus-imapd-2.2.10-1.RHEL4.1 has been built into RHEL4. However, 
please note I have not yet installed and tested this version 
therefore it would premature to update anything yet. FWIW this rpm 
should install on either FC3 or RHEL4.

Comment 15 Andreas Müller 2004-11-30 22:30:30 UTC
What is the current status of the updates? FC2 needs an update, too.

Comment 16 John Dennis 2004-11-30 22:35:09 UTC
RE comment #15, 2.2.10 has been built for both FC2 and FC3, both are currently
working their way through the release process. I expect you'll see the updates
in a few hours.

Comment 17 Mark J. Cox 2004-12-07 10:43:22 UTC
Was released 20041201 as FEDORA-2004-489, FEDORA-2004-487

Note You need to log in before you can comment on or make changes to this bug.