there was some discussion on PLUG recently on fetchmail. and i think the discussion had to do with multidrop mode (although the actual implementation might not have used multidrop, if the different users on the inside server each had individual email addresses on the outside server).
if you're using fetchmail with multidrop, the following advisory is for you. tiger -----Forwarded Message----- > From: Stefan Esser <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: Advisory 03/2002: Fetchmail remote vulnerabilities > Date: 29 Sep 2002 11:44:50 +0200 > > 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 [[EMAIL PROTECTED]] > > 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. _ Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph To leave: send "unsubscribe" in the body to [EMAIL PROTECTED] Fully Searchable Archives With Friendly Web Interface at http://marc.free.net.ph To subscribe to the Linux Newbies' List: send "subscribe" in the body to [EMAIL PROTECTED]
