SecurityTracker.com
Keep Track of the Latest Vulnerabilities
with SecurityTracker!
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 
Sign Up
Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
Instant Alerts
Buy our Premium Vulnerability Notification Service to receive customized, instant alerts
Affiliates
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
Partners
Become a Partner and License Our Database or Notification Service
Report a Bug
Report a vulnerability that you have found to SecurityTracker
bugs
@
securitytracker.com






Category:   Application (E-mail Server)  >   Exim Vendors:   Exim.org
Exim Buffer Overflows in host_aton() and spa_base64_to_bits() May Let Local Users Gain Elevated Privileges
SecurityTracker Alert ID:  1012771
SecurityTracker URL:  http://securitytracker.com/id/1012771
CVE Reference:   CAN-2005-0021, CAN-2005-0022   (Links to External Site)
Updated:  Jan 10 2005
Original Entry Date:  Jan 5 2005
Impact:   Execution of arbitrary code via local system, User access via local system
Fix Available:  Yes  Vendor Confirmed:  Yes  
Version(s): 4.43 and prior versions
Description:   Two vulnerabilities were reported in Exim. A local user may be able to obtain elevated privileges.

Philip Hazel reported that there is a buffer overflow in the host_aton() function. A local user can supply an illegal IPv6 address with more than 8 components via the command line to trigger this flaw. It may be possible to execute arbitrary code with the privileges of the Exim process.

There is also a buffer overflow in the spa_base64_to_bits() function, used for SPA authentication. The impact was not specified.

Impact:   A local user may be able to execute arbitrary code with the privileges of the Exim process [but the report did not confirm this].
Solution:   The vendor has issued a fix in the latest snapshot:

ftp://ftp.csx.cam.ac.uk/pub/software/email/exim/Testing/exim-snapshot.tar.gz
ftp://ftp.csx.cam.ac.uk/pub/software/email/exim/Testing/exim-snapshot.tar.gz.sig

Also, patches for 4.43 are available at:

http://www.exim.org/mail-archives/exim-announce/2005/msg00000.html

Vendor URL:  www.exim.org/ (Links to External Site)
Cause:   Boundary error
Underlying OS:   Linux (Any), UNIX (Any)

Message History:   This archive entry has one or more follow-up message(s) listed below.
Jan 12 2005 (Debian Issues Fix) Exim Buffer Overflows in host_aton() and spa_base64_to_bits() May Let Local Users Gain Elevated Privileges   (joey@infodrom.org (Martin Schulze))
Debian has released a fix.
Jan 13 2005 (Debian Issues Fix for exim-tls) Exim Buffer Overflows in host_aton() and spa_base64_to_bits() May Let Local Users Gain Elevated Privileges   (joey@infodrom.org (Martin Schulze))
Debian has released a fix for exim-tls.



 Source Message Contents

Date:  Tue, 4 Jan 2005 14:54:45 +0000 (GMT)
Subject:  [exim-announce] 2 smallish security issues


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

Two relatively minor (IMHO) security issues in Exim were raised over the 
Christmas break. The patches below address them for the 4.43 release. The same 
patches will probably easily retrofit onto quite a number of prior releases. I
have also put these fixes into the current source, and made a new snapshot for
testing in

ftp://ftp.csx.cam.ac.uk/pub/software/email/exim/Testing/exim-snapshot.tar.gz
ftp://ftp.csx.cam.ac.uk/pub/software/email/exim/Testing/exim-snapshot.tar.gz.sig

In addition to the security patches, this snapshot contains some bug fixes and
tidies that were reported by testers of the previous snapshot.


Discussion of security issues
- -----------------------------

1. The function host_aton() can overflow a buffer if it is presented with an 
   illegal IPv6 address that has more than 8 components. The input to this 
   function is supposed to be checked; the report said that an unchecked value 
   could be passed via the command line (without specifying which command line 
   option, annoyingly). I found one such case, which was a call do a dnsdb
   lookup for a PTR record, as part of testing expansions using -be. The first
   patch below fixes this - as it happens, this change had already been made to
   the current source. 
   
   The report stated that Exim was running as "exim" when the problem occurred:
   with -be, Exim runs as the calling user. Therefore, either the report was
   wrong, or there is another case that I could not find. However, if there is
   another case, it will now be covered by the second patch below, which puts a
   test into the host_aton() function itself. (This should, of course, have
   been there all the time, as a bit of defensive programming, but hey, I'm
   only human. :-)

2. The second report described a buffer overflow in the function 
   spa_base64_to_bits(), which is part of the code for SPA authentication. This 
   code originated in the Samba project. The overflow can be exploited only if 
   you are using SPA authentication. The remaining patches below fix this 
   problem by adding a buffer length parameter to the problem function. I have 
   tested that SPA authentication still works, but I don't have the tools to 
   test that an attempt to exploit the overflow is now detected.

- -- 
Philip Hazel            University of Cambridge Computing Service,
ph10@xxxxxxxxxxxxx      Cambridge, England. Phone: +44 1223 334714.


- -----PATCHES-------------------------------------------------------------

*** exim-4.43/src/lookups/dnsdb.c   Tue Oct  5 09:32:08 2004
- --- dnsdb.c	 Wed Dec 29 09:36:13 2004
***************
*** 125,131 ****
  /* If the type is PTR, we have to construct the relevant magic lookup
  key. This code is now in a separate function. */
  
! if (type == T_PTR)
    {
    dns_build_reverse(keystring, buffer);
    keystring = buffer;
- --- 125,131 ----
  /* If the type is PTR, we have to construct the relevant magic lookup
  key. This code is now in a separate function. */
  
! if (type == T_PTR && string_is_ip_address(keystring, NULL))
    {
    dns_build_reverse(keystring, buffer);
    keystring = buffer;
*** exim-4.43/src/host.c    Tue Oct  5 09:32:08 2004
- --- host.c	Wed Dec 29 09:43:17 2004
***************
*** 710,721 ****
  
    if (*p == ':') p++;
  
!   /* Split the address into components separated by colons. */
  
    while (*p != 0)
      {
      int len = Ustrcspn(p, ":");
      if (len == 0) nulloffset = ci;
      component[ci++] = p;
      p += len;
      if (*p == ':') p++;
- --- 754,771 ----
  
    if (*p == ':') p++;
  
!   /* Split the address into components separated by colons. The input address 
!   is supposed to be checked for syntax. There was a case where this was 
!   overlooked; to guard against that happening again, check here and crash if 
!   there is a violation. */
  
    while (*p != 0)
      {
      int len = Ustrcspn(p, ":");
      if (len == 0) nulloffset = ci;
+     if (ci > 7) log_write(0, LOG_MAIN|LOG_PANIC_DIE, 
+       "Internal error: invalid IPv6 address \"%s\" passed to host_aton()",
+       address);  
      component[ci++] = p;
      p += len;
      if (*p == ':') p++;
*** exim-4.43/src/auths/auth-spa.c  Tue Oct  5 09:32:08 2004
- --- auth-spa.c	  Wed Dec 29 10:55:58 2004
***************
*** 404,411 ****
    *out = '\0';
  }
  
  int
! spa_base64_to_bits (char *out, const char *in)
  /* base 64 to raw bytes in quasi-big-endian order, returning count of bytes */
  {
    int len = 0;
- --- 406,416 ----
    *out = '\0';
  }
  
+ 
+ /* The outlength parameter was added by PH, December 2004 */
+ 
  int
! spa_base64_to_bits (char *out, int outlength, const char *in)
  /* base 64 to raw bytes in quasi-big-endian order, returning count of bytes */
  {
    int len = 0;
***************
*** 418,423 ****
- --- 423,430 ----
  
    do
      {
+       if (len >= outlength)                   /* Added by PH */
+         return (-1);                          /* Added by PH */
        digit1 = in[0];
        if (DECODE64 (digit1) == BAD)
         return (-1);
***************
*** 435,445 ****
- --- 442,456 ----
        ++len;
        if (digit3 != '=')
         {
+          if (len >= outlength)                   /* Added by PH */
+            return (-1);                          /* Added by PH */
           *out++ =
             ((DECODE64 (digit2) << 4) & 0xf0) | (DECODE64 (digit3) >> 2);
           ++len;
           if (digit4 != '=')
             {
+              if (len >= outlength)                   /* Added by PH */
+                return (-1);                          /* Added by PH */
               *out++ = ((DECODE64 (digit3) << 6) & 0xc0) | DECODE64 (digit4);
               ++len;
             }
*** exim-4.43/src/auths/auth-spa.h  Tue Oct  5 09:32:08 2004
- --- auth-spa.h	  Wed Dec 29 10:55:58 2004
***************
*** 9,14 ****
- --- 11,19 ----
   * All the code used here was torn by Marc Prud'hommeaux out of the
   * Samba project (by Andrew Tridgell, Jeremy Allison, and others).
   */
+  
+ /* December 2004: The spa_base64_to_bits() function has no length checking in 
+ it. I have added a check. PH */ 
  
  /* It seems that some systems have existing but different definitions of some
  of the following types. I received a complaint about "int16" causing
***************
*** 75,81 ****
  #define spa_request_length(ptr) (((ptr)->buffer - (uint8x*)(ptr)) + (ptr)->bufIndex)
  
  void spa_bits_to_base64 (unsigned char *, const unsigned char *, int);
! int spa_base64_to_bits(char *, const char *);
  void spa_build_auth_response (SPAAuthChallenge *challenge,
         SPAAuthResponse *response, char *user, char *password);
  void spa_build_auth_request (SPAAuthRequest *request, char *user,
- --- 80,86 ----
  #define spa_request_length(ptr) (((ptr)->buffer - (uint8x*)(ptr)) + (ptr)->bufIndex)
  
  void spa_bits_to_base64 (unsigned char *, const unsigned char *, int);
! int spa_base64_to_bits(char *, int, const char *);
  void spa_build_auth_response (SPAAuthChallenge *challenge,
         SPAAuthResponse *response, char *user, char *password);
  void spa_build_auth_request (SPAAuthRequest *request, char *user,
*** exim-4.43/src/auths/spa.c	    Tue Oct  5 09:32:08 2004
- --- spa.c Wed Dec 29 10:55:58 2004
***************
*** 133,139 ****
    return FAIL;
    }
  
! if (spa_base64_to_bits((char *)(&request), (const char *)(data)) < 0)
    {
    DEBUG(D_auth) debug_printf("auth_spa_server(): bad base64 data in "
    "request: %s\n", data);
- --- 135,141 ----
    return FAIL;
    }
  
! if (spa_base64_to_bits((char *)(&request), sizeof(request), (const char *)(data)) < 0)
    {
    DEBUG(D_auth) debug_printf("auth_spa_server(): bad base64 data in "
    "request: %s\n", data);
***************
*** 153,159 ****
    }
  
  /* dump client response */
! if (spa_base64_to_bits((char *)(&response), (const char *)(data)) < 0)
    {
    DEBUG(D_auth) debug_printf("auth_spa_server(): bad base64 data in "
    "response: %s\n", data);
- --- 155,161 ----
    }
  
  /* dump client response */
! if (spa_base64_to_bits((char *)(&response), sizeof(response), (const char *)(data)) < 0)
    {
    DEBUG(D_auth) debug_printf("auth_spa_server(): bad base64 data in "
    "response: %s\n", data);
***************
*** 319,325 ****
         /* convert the challenge into the challenge struct */
         DSPA("\n\n%s authenticator: challenge (%s)\n\n",
                 ablock->name, buffer + 4);
!        spa_base64_to_bits ((char *)(&challenge), (const char *)(buffer + 4));
  
         spa_build_auth_response (&challenge, &response,
                 CS username, CS password);
- --- 324,330 ----
         /* convert the challenge into the challenge struct */
         DSPA("\n\n%s authenticator: challenge (%s)\n\n",
                 ablock->name, buffer + 4);
!        spa_base64_to_bits ((char *)(&challenge), sizeof(challenge), (const char *)(buffer + 4));
  
         spa_build_auth_response (&challenge, &response,
                 CS username, CS password);
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iQEVAwUBQdqtFZdm4IT7D0PYAQLJmggAkP/M32D3FsbnqBZGxMIRsEFOufoBrw4I
oX3arosSvCdS/3cb39YEs2rOQjfJUeHvaxmmu6AN+3X01OZCfsmY7JL6RamowQlV
IBvLipMLQ8qEuUGhwRiNXYE1jxJm6rmbQLJHWukgEtmXO5GjGWe+jjCKR0jjNw/u
m75TbZCDmtz0nVB+/0yam9teSAbIoIEER9xtpaM8vjRLCptXOzwifOVUOZQzIwxr
vC/UqcCSoa1CAAaAHPbNisemPfUa6d+WBd9/W74L7v5AcZ6Tk1wbVqoXuFV3c8yP
TiUqxWTudhVbvC5KIHXoV/PhqVExWTJM4ggUZ23y5tZ0mrDDJkFqGw==
=vdDU
-----END PGP SIGNATURE-----
 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

Copyright 2014, SecurityGlobal.net LLC