Secure testing team - Nov 2006 - proftpd, low impact DoS bug

Dear all

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5815

This impacts for sure 1.3.0-12 in testing/sid (I''m going to upload -13
for that), and
I''m evaluating if it can be of interest for current stable. In that
case, stable team will receive pointers for an up-to-date package.

Cheers.

-- 
Francesco P. Lovergine
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20061120/2e5d45e3/attachment.pgp

Sigh

http://bugs.proftpd.org/show_bug.cgi?id=2858

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...


-- 
Francesco P. Lovergine
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20061128/2fa73dad/attachment.pgp

On Tue, Nov 28, 2006 at 01:27:06PM +0100, Francesco P. Lovergine
wrote:
> Sigh
> 
> http://bugs.proftpd.org/show_bug.cgi?id=2858
> 
> 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...
> 
> 
I''m asking for confirmation to proftpd folk, anyway the 1.3.0 patch
does not
apply to 1.2.10 sreplace() implementation, which is in some way more
limited. Just in case, the safest thing to do would be using the 1.3.0
implementation of sreplace() in 1.2.10 for sarge (and removing the other patch
applied
some days ago for security.d.o) 

Pointers:

1.3.0a vs 1.3.0 patch:
http://proftp.cvs.sourceforge.net/proftp/proftpd/src/support.c?r1=1.79&r2=1.80&sortby=date

1.3.0a version of support.c
http://proftp.cvs.sourceforge.net/proftp/proftpd/src/support.c?revision=1.80&view=markup&sortby=date

1.2.10 version of support.c:
http://proftp.cvs.sourceforge.net/proftp/proftpd/src/support.c?revision=1.69&view=markup&sortby=date

-- 
Francesco P. Lovergine
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20061128/3e5b5c75/attachment.pgp

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?

Cheers,
        Moritz

CC proftpd secteam...

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?
> 
> Cheers,
>         Moritz
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).

A 1.2.10 fixed version for sarge is in preparation with complete fixes,
but it lacks the very last one (as sid version as well). I would upload sarge
version after fixing also the last issue.

AFAIK the most complete status is shown in Secunia, but we need
a couple of new mitre ref, could you please obtain them ASAP?

Could please anyone of proftpd team update us if required about
current status? Thanks

-- 
Francesco P. Lovergine
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20061129/02defa36/attachment.pgp

Hi,

On Tue, 28 Nov 2006, Moritz Muehlenhoff wrote:
> We have two different issues here:
AIUI, we have three different issues.
> 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.
This is the CommandBufferSize issue, I think. This was fixed by -13 and 
the DSA. I don''t know why this was called CVE-2006-5815. The proftpd 
people don''t think it is severe [1].
>
> The sreplace() issue.
This is the original CVE-2006-5815, but no info was available for weeks. 
Existance was announced on Nov 6, disclosure of info was on Nov 27. [1]

Then there is a third issue in mod_tls, in tls_x509_name_oneline(). 
Disclosure was on Nov 28. [2] I assumed that mod_tls was not enabled by 
default, so I set the severity to medium in the tracker. If mod_tls is on 
by default, it is of course ''high''.

Cheers,
Stefan


[1] http://bugs.proftpd.org/show_bug.cgi?id=2858
[2] http://seclists.org/bugtraq/2006/Nov/0549.html

On Wed, Nov 29, 2006 at 09:53:10AM +0100, Francesco P. Lovergine
wrote:
> 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).
TJ addressed this last night:

http://bugs.proftpd.org/show_bug.cgi?id=2860

john
-- 
John Morrissey           _o            /\         ----  __o
jwm@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/b77ced1a/attachment.pgp

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@proftpd.org>
To: "Steven M. Christey" <coley@linus.mitre.org>
Cc: vendor-sec@lst.de, security@proftpd.org, cve@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@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