Security Advisory 03/2002

Advisory 03/2002
Fetchmail remote vulnerabilities

Release Date: 2002/09/29
Author: Stefan Esser
Application: Fetchmail <= 6.0.0
Severity: Several vulnerabilities within Fetchmail could allow remote compromise.
Risk: Critical
Last Modified:   2002/09/29

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 the new or patched version as soon as possible.