Re: CVE-2008-id Request -- ssmtp -- standardise() -- Buffer overflow

["Steven M. Christey" <coley () linus mitre org>]

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