Vulnerability

    exim

Affected

    exim

Description

    Megyer Laszlo found following.  accept.c, line 2506:

        else if (smtp_reply != NULL) moan_smtp_batch(NULL, smtp_reply);

    while moan_smtp_batch is like this:

        moan_smtp_batch(char *cmd_buffer, char *format, ...)

    So when smtp_reply contains format strings, it get transformed  by
    moan_smtp_batch().

    This piece  of code  is only  executed when  exim is configured to
    check  incoming  mails'  headers:  /etc/exim.conf  should  have an
    option set: headers_check_syntax

    By default it's turned  OFF, only few ppl  turn it on so  it's NOT
    vulnerable BY DEFAULT.

    For exploitation try this:

        lez:~$ /usr/sbin/exim -bS
        mail from:lez@lez
        rcpt to:hax0r@lez
        data
        From:@@%p%p%p%p%p%p%p%p%p%p

        .

    Somewhere in the answers you should see:

        550 Syntax error in 'From' header: domain missing or malformed:  failing address is:  @@0x80beba00x804d2690x80be6600x80be6680x80bd050(nil)(nil)(nil)(nil)0x80b9d40

    If you  change %p's  to %s's,  you get  segfault.   With carefully
    constructed thing,  it's easy  to overwrite  saved eip  with %n's,
    and get root out of this bug.

    No exploit yet, but after the many local format bug exploits  it's
    not a big work to write one for a skilled man.

Solution

    No one  with sense  runs an  MTA as  root, and  the exim  security
    information strongly suggests you do not.  Yes, this looks like  a
    real problem  but it  should also  serve as  a good  time to check
    that as little as possible runs as root.

    For Debian Linux:

        http://security.debian.org/dists/stable/updates/main/source/exim_3.12-10.1.diff.gz
        http://security.debian.org/dists/stable/updates/main/source/exim_3.12-10.1.dsc
        http://security.debian.org/dists/stable/updates/main/source/exim_3.12.orig.tar.gz
        http://security.debian.org/dists/stable/updates/main/binary-arm/exim_3.12-10.1_arm.deb
        http://security.debian.org/dists/stable/updates/main/binary-arm/eximon_3.12-10.1_arm.deb
        http://security.debian.org/dists/stable/updates/main/binary-alpha/exim_3.12-10.1_alpha.deb
        http://security.debian.org/dists/stable/updates/main/binary-alpha/eximon_3.12-10.1_alpha.deb
        http://security.debian.org/dists/stable/updates/main/binary-i386/exim_3.12-10.1_i386.deb
        http://security.debian.org/dists/stable/updates/main/binary-i386/eximon_3.12-10.1_i386.deb
        http://security.debian.org/dists/stable/updates/main/binary-m68k/exim_3.12-10.1_m68k.deb
        http://security.debian.org/dists/stable/updates/main/binary-m68k/eximon_3.12-10.1_m68k.deb
        http://security.debian.org/dists/stable/updates/main/binary-powerpc/exim_3.12-10.1_powerpc.deb
        http://security.debian.org/dists/stable/updates/main/binary-powerpc/eximon_3.12-10.1_powerpc.deb
        http://security.debian.org/dists/stable/updates/main/binary-sparc/exim_3.12-10.1_sparc.deb
        http://security.debian.org/dists/stable/updates/main/binary-sparc/eximon_3.12-10.1_sparc.deb

    For Conectiva Linux:

        ftp://atualizacoes.conectiva.com.br/6.0/SRPMS/exim-3.16-4U60_1cl.src.rpm
        ftp://atualizacoes.conectiva.com.br/6.0/RPMS/exim-3.16-4U60_1cl.i386.rpm
        ftp://atualizacoes.conectiva.com.br/6.0/RPMS/exim-doc-3.16-4U60_1cl.i386.rpm
        ftp://atualizacoes.conectiva.com.br/6.0/RPMS/exim-mon-3.16-4U60_1cl.i386.rpm

    The following patch should work against this ugly format bug:

    --- accept.c.orig       Tue Jun 12 11:33:01 2001
    +++ accept.c    Tue Jun 12 11:33:38 2001
    @@ -2503,7 +2503,7 @@
       nothing on success. The function moan_smtp_batch() does not return -
       it exits from the program with a non-zero return code. */
    
    -  else if (smtp_reply != NULL) moan_smtp_batch(NULL, smtp_reply);
    +  else if (smtp_reply != NULL) moan_smtp_batch(NULL, "%s", smtp_reply);
       }
    
    /* Reset headers so that logging of rejects for a subsequent message
    doesn't

    The author has stated on the exim-users mailing list that this  is
    the correct patch to resolve  this problem.  It'll be  rolled into
    the next release, 3.30, which is expected out shortly.