Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ