[Secure-testing-team] Re: proftpd, low impact DoS bug

[John Morrissey]

On Wed, Nov 29, 2006 at 09:53:10AM +0100, Francesco P. Lovergine wrote:
> On Tue, Nov 28, 2006 at 10:43:52PM +0100, Moritz Muehlenhoff wrote:
> > Francesco P. Lovergine wrote:
> > > we need to properly fix the issue, a wrong patch was around (basically
> > > the same 'fixed' by other vendors) so I'm preparing both a sid and
> > > sarge package...
> > 
> > We have two different issues here:
> > A denial of service vulnerability discovered by Ralf Engelschall. That's
> > what we've fixed so far. It's tracked as CVE-2006-5815 by several
> > distributions by now. Although it's not suitable for code injection,
> > it's still a DoS vulnerability.
> > 
> > The sreplace() issue. I'm seeing that mod_tls is referenced in the
> > debian/rules as EXTRAMODS, getting linked in the pam target. Does this
> > mean mod_tls support is enabled in the stock 1.2 package from Sarge?
> 
> AFAIK we have currently 3 different issues, indeed. The CVE-2006-5815 points
> apparently the CommandBuffer issue. John M. of proftpd team said me 
> the true issue is the sreplace() one which is not pointed by that
> report (as explained in the proftpd advisory), so probably at least 2 issues 
> lack Mitre numbering. Current sid -15 version fixes both CommandBuffer
> and sreplace(). The last new issue is due to memcpy() in mod_tls which
> is enabled by default in 1.2.10+ (but used only for ftps connections).
> At this time there is not an official patch (even if it's trivial at
> least pre-checking datalen in the code).
[snip]
> Could please anyone of proftpd team update us if required about
> current status? Thanks

Yes, there are three bugs. One is the CommandBufferSize underflow (which is
not exploitable AFAICT, see below), two is the sreplace() overflow, and the
third is a possible overflow in mod_tls, which is in ProFTPD's contrib/
directory and therefore third-party software.

Below is a copy of my reply to Steve Christey WRT the CVE numbering:


From: John Morrissey <jwm at proftpd.org>
To: "Steven M. Christey" <coley at linus.mitre.org>
Cc: vendor-sec at lst.de, security at proftpd.org, cve at mitre.org
Subject: Re: ProFTPD - one vuln or two?  One CVE or two... (or three?)
Date: Tue, 28 Nov 2006 20:07:58 -0500

Hi Steve--

On Tue, Nov 28, 2006 at 06:34:37PM -0500, Steven M. Christey wrote:
> If these are two separate bugs, then we have a case where CVE-2006-5815's
> description is being used to combine two distinct issues, but some
> downstream vendors might have only addressed one of them.
[snip]
> The ProFTP bug report confirms sreplace and vd_proftpd.pm:
> 
>   http://bugs.proftpd.org/show_bug.cgi?id=2858
> 
> I'll anchor CVE-2006-5815 on this particular vector.

Yes, that is correct.

Frankly, I'm not sure where anybody got the idea that CVE-2006-5815 was the
CommandBufferSize issue. Even we didn't have any information on the location
or nature of the vulnerability until days after this rumor started to
circulate. Looking back, the first mention we found of it was:

http://www.frsirt.com/english/advisories/2006/4451

so perhaps someone at FrSIRT jumped the gun, looking for something,
anything, in recent commits to the ProFTPD source that could have been
related. I'm sure everyone involved is very busy, but I wish we could have
saved many people grief by quenching this rumor early via improved
communication. Unfortunately, I've no idea how we could have responded
differently, since we were completely in the dark.

> 1) CVE-2006-5815 is for sreplace/vd_proftpd.pm
> 
> 2) We need a new CVE for mod_tls

You should probably list this as a vulnerability in mod_tls, not ProFTPD.
Mr. Legerov seems to have missed mod_tls' presence in ProFTPD's contrib/
directory, in which a README clearly states that it "contains third-party
scripts, binaries and ProFTPD modules. Such found here are completely
unsupported by the ProFTPD team[...]"

> 3) We might need a new CVE for the CommandBufferSize issue, assuming it is
> triggerable (ProFTP - we include DoSesin CVE, assuming it's not in a
> thread that just restarts automatically).

The variable that this underflow overwrites is either (a) overwritten by
assignment before its next use or (b) goes unused for the remainder of the
function. In my eyes, this renders it a non-issue.

john

-- 
John Morrissey           _o            /\         ----  __o
jwm at proftpd.org       _-< \_          /  \       ----  <  \,
www.proftpd.org/   __(_)/_(_)________/    \_______(_) /_(_)__
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20061129/b16007a5/attachment.pgp