This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Fwd: plz update fetchmail in cygwin distribution up to 6.1.x


provodnikov,

Please post instead of sending private email.

Note that I would have release a Cygwin fetchmail 6.1.0 already but I
haven't received any responses to the following:

    http://cygwin.com/ml/cygwin/2002-09/msg00999.html
    http://lists.ccil.org/pipermail/fetchmail-friends/2002-September/002577.html

I will release Cygwin fetchmail 6.1.0 at my earliest convenience using
the aclocal/autoconf workaround mentioned above.  Does anyone know of a
better approach?

Thanks,
Jason
--- Begin Message ---
because of:

                           e-matters GmbH
                          www.e-matters.de

                      -= Security  Advisory =-



     Advisory: Fetchmail remote vulnerabilities
 Release Date: 2002/09/29
Last Modified: 2002/09/29
       Author: Stefan Esser [s.esser@e-matters.de]

  Application: Fetchmail <= 6.0.0
     Severity: Several vulnerabilities within Fetchmail could
               allow remote compromise.
         Risk: Critical
Vendor Status: Vendor released version 6.1.0
    Reference: http://security.e-matters.de/advisories/032002.html



Overview:

   We have discovered several bufferoverflows and a broken boundary
check
   within Fetchmail. If Fetchmail is running in multidrop mode these
flaws
   can be used by remote attackers to crash it or to execute arbitrary
   code with the permissions of the user running fetchmail. Depending
on
   the configuration this allows a remote root compromise.


Details:

   While auditing Fetchmail we found several places within the header
   parsing function readheaders() where user supplied email addresses
   are copied into stack or heap buffers without proper size checking.
   nxtaddr() limits the length of such addresses to BUFSIZ bytes. This
   constant is defined within the stdio.h header file and is usually
   defined as 1024. However systems running glibc like linux define it
   as 8192. The destination buffers are around 1 kb in size which
means
   they will overflow with about 7 kb on linux. Luckily those
overflows
   are not exploitable because of the fact that 7kb are not enough to
   overwrite important control structures. I do not believe that there
   exists any system that defines BUFSIZ higher than 8192 but f.e. a
   value of 9000 would be enough to exploit one of the bugs...
  
   Unfourtunately there are two more bugs which are related to the
   header parsing code and that can be exploited remotely if Fetchmail
   is used in multidrop mode. The first one is a broken boundary check
   within getmxrecord() that can be used to crash Fetchmail remotely.
   To accomplish this an attacker must be able to send a big specially
   crafted dns packet to the victim. This is very simple if you are
   able to forge the answers of the used dns server but an attacker
   can also force Fetchmail to ask for the mx record of a domain he
   has control over. It will be trickier but is should be possible to
   create a legal dns packet that will pass through bind and will
crash.
   If Fetchmail receives such a packet it will calculate the end of
the
   packet wrong and will crash when it tries to read data from above
   the top of the Stack.
  
   The last bug is the most dangerous one, because successfully
   exploited it allows to execute arbitrary code on the victim's
system.
   This bug is within the way Fetchmail parses "Received:" headers
   within the parse_received() function. Within this function parts
   of the "Received:" headerline gets copied into a heap buffer
   without any size check. A specially crafted "Received:" header
   will overflow the heap with an arbitrary number of bytes. If you
   overflow the buffer with enough bytes you can change some pointers
   that get free()d/realloc()ated later or you can change the malloc()
   control data on the heap directly.
  
   Finally it is important to mention that an attacker does not need
   to spoof dns records, or control the mailserver to exploit the last
   bug. It is usually enough to deliver a mail that contains such a
   specially crafted "Received:" header line to the mailserver.
  

Proof of Concept:

   e-matters is not going to release an exploit for this vulnerability
to
   the public.
  

Vendor Response:

   22. September 2002 - A patch that fixes this vulnerabilites was
mailed
                        to the vendor.
                       
                        Vendor released a new version (6.1.0) and
asked me
                        to delay announcing this vulnerability for one
week.


Recommendation:

   If you are running Fetchmail in multidrop mode you should upgrade
to a new
   or patched version as soon as possible.
  
  
GPG-Key:

   http://security.e-matters.de/gpg_key.asc
   
   pub  1024D/75E7AAD6 2002-02-26 e-matters GmbH - Securityteam
   Key fingerprint = 43DD 843C FAB9 832A E5AB  CAEB 81F2 8110 75E7
AAD6


Copyright 2002 Stefan Esser. All rights reserved.

--- End Message ---
--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]