Your message dated Wed, 25 Jun 2008 15:07:52 +0300
with message-id <[EMAIL PROTECTED]>
and subject line Re: Bug#487718: libdevel-stacktrace-perl: Security 
vulnerability in RT 3.0 and up
has caused the Debian Bug report #487718,
regarding libdevel-stacktrace-perl: Security vulnerability in RT 3.0 and up
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
487718: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487718
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: libdevel-stacktrace-perl
Version: 1.11-1
Severity: important
Tags: security etch
X-Debbugs-Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]

Quoting 
<http://lists.bestpractical.com/pipermail/rt-announce/2008-June/000158.html>:

> All versions of RT from 3.0.0 to 3.6.6 (including some, but not all RT
> 3.7 development releases) are vulnerable to a potential remote denial
> of service attack which could exhaust virtual memory or consume all
> available CPU resources.  After a detailed analysis, we believe that
> an attacker would need to be a 'Privileged' RT user in order to
> perform an attack.

> We recommend that you install version 1.19 or newer of the Perl module
> Devel::StackTrace from CPAN, which will close the vulnerability.  Two
> methods for doing this are:

[...]

> Installing this newer version of the module is a complete fix, and
> will close the vulnerability.  However, we suggest that you upgrade to
> RT 3.6.7, released last Monday, which provides additional safeguards
> against this type of attack.

The fix can be seen here:

 
http://search.cpan.org/diff?from=Devel-StackTrace-1.18&to=Devel-StackTrace-1.19#lib/Devel/StackTrace.pm

and a fixed version is two days away from entering lenny.

Etch has libdevel-stacktrace-perl 1.11-1, which most probably has the
same bug too, so reporting at that version.

The RT packages concerned are request-tracker3.4 (Etch only) and
request-tracker3.6 (both Etch and lenny/sid). Cc'ing the maintainer
addresses.

I don't understand the issue fully yet, particularly the 'exhaust virtual
memory or consume all available CPU resources' part. I'll get back to
this, but it may take a while. Help would be welcome.

The big question is whether this needs an Etch update. I'm leaving the
severity at 'important' for now, as the security impact seems to be
quite low.

Cc'ing the security team as a heads-up.
-- 
Niko Tyni   [EMAIL PROTECTED]



--- End Message ---
--- Begin Message ---
Version: 1.1901-1

On Tue, Jun 24, 2008 at 08:58:21AM +0200, Thijs Kinkhorst wrote:
> On Mon, June 23, 2008 21:29, Niko Tyni wrote:
> >> All versions of RT from 3.0.0 to 3.6.6 (including some, but not all RT
> >> 3.7 development releases) are vulnerable to a potential remote denial
> >> of service attack which could exhaust virtual memory or consume all
> >> available CPU resources.  After a detailed analysis, we believe that an
> >> attacker would need to be a 'Privileged' RT user in order to perform an
> >> attack.
> 
> > The big question is whether this needs an Etch update. I'm leaving the
> > severity at 'important' for now, as the security impact seems to be
> > quite low.
> 
> I agree - I wouldn't update this for Etch. You need to be a privileged
> user already and denial of service isn't the worst class of problems. It
> seems unlikely that privileged users would find it desirable to DoS their
> RT, and if they would really want that, there's nothing stopping them now
> e.g. by automatically making many requests or filing extreme number of
> tickets.

OK, let's consider this case closed. The fix is in
libdevel-stacktrace-perl 1.1901-1 in unstable, so closing the bug too.

Thanks,
-- 
Niko Tyni   [EMAIL PROTECTED]


--- End Message ---

Reply via email to