|
From: Jonathan S. <gel...@ge...> - 2002-03-02 20:46:44
|
On Sat, 2 Mar 2002, Olivier Dragon wrote:
> On Sat, Mar 02, 2002 at 05:04:31PM +0000, Sam Smith wrote:
> > On Sat, 2 Mar 2002, Olivier Dragon wrote:
> > > WTH??? The page's like 200... MB!!! I've got cable and after 2min I only
> > > had 10MB downloaded... I just gave up!
> > >
> > > What's wrong with it? Is is an NMS wwwboard or a MSA one?
> >
> > The page's like 200... MB!!! I've got cable and after 2min I only
> > had 10MB downloaded... I just gave up!
>
> Haha... funny. I mean technically, why is it so big and what's wrong
> with it...
>
OK, I've worked out what the exploit does - it operates entirely through
the followup parameter. You construct a request (possibly using something
like LWP) that has a followup parameter that has 1 ... <number in
data.txt> and then a very large number of <number in data.txt + 1>
repeated, all comma separated. Thus the threading mechanism will dumbly
rewrite the wwwboard.html so that it it becomes gigantic and will rewrite
a load of the individual messages as having these spurious followups.
The second part of this is already dealt with in the code by the
foreach my $fn (@followup_num) {
error('followup_data') if $fn !~ /^\d+$/ || $fcheck{$fn};
$fcheck{$fn}++;
}
@followup_num = keys %fcheck;
bit.
The first part however is a little bit more difficult because you would
have to read every message to check whether this was a pukka followup to
that, so what I have done is put in a $max_followups configuration
(guarded by $emulate_matts_code) that limits the number of messages a
followup can be a followup to be - this will still allow an attacker to
create *some* spurious followups but will mitigate the potential effect of
such an attempt. I have updated the README accordingly.
/J\
--
Jonathan Stowe |
<http://www.gellyfish.com> | This space for rent
|
|