[EMAIL PROTECTED] (Stefan Esser) writes: > 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.
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ linux-india-help mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/linux-india-help
