79487 2002-09-30 22:48 /107 rader/ Stefan Esser <s.esser@e-matters.de>
Importerad: 2002-09-30 22:48 av Brevbäraren
Extern mottagare: vulnwatch@vulnwatch.org
Extern mottagare: bugtraq@lists.securityfocus.com
Mottagare: Bugtraq (import) <1713>
Ärende: Advisory 03/2002: Fetchmail remote vulnerabilities
------------------------------------------------------------
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.
(79487) /Stefan Esser <s.esser@e-matters.de>/(Ombruten)