[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 19 Aug 2010 15:50:34 -0400 (EDT)
From: "Steven M. Christey" <coley@...us.mitre.org>
To: oss-security <oss-security@...ts.openwall.com>
cc: "Steven M. Christey" <coley@...us.mitre.org>
Subject: Re: CVE-2008-id Request -- ssmtp -- standardise() --
Buffer overflow
On Mon, 26 Jul 2010, Jan Lieskovsky wrote:
> Brendan Boerner reported:
> [1] https://bugs.launchpad.net/ubuntu/+source/ssmtp/+bug/282424
>
> a deficiency in the way ssmtp removed trailing '\n' sequence
> by processing lines beginning with a leading dot. A local user,
> could send a specially-crafted e-mail message via ssmtp send-only
> sendmail emulator, leading to ssmtp executable denial of service (exit with:
> ssmtp: standardise() -- Buffer overflow). Different vulnerability
> than CVE-2008-3962.
CVE-2008-7258 was assigned to this, but is it really a vulnerability? It
seems like the attacker can only DoS himself. Thoughts?
from one of our CVE analysts:
The product's first relevant behavior is to call "fgets(buf,
sizeof(buf), stdin)" -- this is a safe call and cannot overflow a
buffer. There is a "char buf[(BUF_SZ + 1)]" declaration, and BUF_SZ is
2048. The product then (in the standardise function) assigns sl to the
strlen value of buf. It then performs the test "if((sl + 2) > BUF_SZ"
and calls "exit(1)" if this test succeeds. If sl is 2047 or more, the
test succeeds. If sl is 2046 or less, the test fails. In the 2046 case,
the buffer has 2046 characters obtained from stdin, followed by a '\0'
character. In this 2046 case, the product then calls memmove to move
2047 characters forward by one in the buffer. In other words, characters at
positions 0 through 2046 (inclusive) are moved to positions 1 through
2047. This is OK because the valid positions in the buffer are 0 through
2048. There are arguably two problems in the code. The first is that the
fgets perhaps should not read more than 2046 characters, because the
standardise function does not want to see more than 2046. This is only a
usability problem. The role of the sSMTP product is to read a single
e-mail message from stdin and then exit. The product does not maintain
state, listen for connections, use setuid privileges, etc. The
mishandling of messages with certain long lines only means that the
sender of such a message can DoS himself. The issue does not cross
privilege boundaries. Also note that the product cleanly detects the
long line and calls exit(1) -- the product does not crash. The other
problem in the code is that the standardise function apparently can
handle 2047 characters but chooses to reject anything larger than 2046.
Again, this is solely a usability problem.
- Steve
> References:
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=582236
> [3] https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2008-3962
> [4] http://patch-tracker.debian.org/package/ssmtp/2.62-3
> [5]
> http://lists.fedoraproject.org/pipermail/package-announce/2010-May/041012.html
> [6]
> http://lists.fedoraproject.org/pipermail/package-announce/2010-May/041009.html
> [7]
> http://lists.fedoraproject.org/pipermail/package-announce/2010-May/041119.html
>
> Debian Linux distribution patch:
> [8]
> http://patch-tracker.debian.org/patch/series/view/ssmtp/2.62-3/345780-standardise-bufsize
>
> Public PoC (from https://bugzilla.redhat.com/show_bug.cgi?id=582236#c0):
> [9] ( 0. Install & configure ssmtp, of course )
> 1. (echo -n . ; for i in {1..2050} ; do echo -n $i ; done) | mail
> root
>
> Couldn't find CVE-2008-XXXX ssmtp identifier for this
> (http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ssmtp).
>
> Steve, could you allocate one?
>
> Thanks && Regards, Jan.
> --
> Jan iankko Lieskovsky / Red Hat Security Response Team
>
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
