Menu
▾
▴
nms-cgi-devel
|
From: Nick C. <ni...@cl...> - 2001-11-16 17:46:13
|
Here are the problems I can see in the current nms-cgi guestbook.pl script. 1) Allows the upload of arbitrary HTML, $allow_html does nothing. 2) Makes changes in response to a GET request. 3) Truncates and rewrites the file, so someone viewing the guestbook might see a short or empty guestbook during an update. Is anyone working on these ? Shall I have a go ? -- Nick |
|
From: iain t. <ic...@eh...> - 2001-11-16 17:53:32
|
* Nick Cleaton (ni...@cl...) [16 Nov 2001 17:56]: > Here are the problems I can see in the current nms-cgi guestbook.pl > script. > 1) Allows the upload of arbitrary HTML, $allow_html does nothing. True. > 2) Makes changes in response to a GET request. Is that really a problem? > 3) Truncates and rewrites the file, so someone viewing the > guestbook might see a short or empty guestbook during > an update. True. Are you thinking a 'write to new file and mv it' thing? > Is anyone working on these ? > Shall I have a go ? Go for it? cheers, -- iain. <http://eh.org/~koschei/> |
|
From: Joseph F. R. <rya...@os...> - 2001-11-16 19:12:00
|
I was trudging through search.pl today, when I noticed that we weren't
using File::Find. I am pretty sure that File::Find has been part of the
core since 5.004, so why not use it? At any rate, I changed this:
----------------------
my @files = ('*.txt','*.html','*.dat', '*.src');
my @search_files = get_files(@files);
sub get_files {
my @files = @_;
chdir($basedir) or die "Can't chdir to $basedir: $!\n";
my @found;
foreach (@files) {
$_ .= '/*' if -d "./$_" && !/\*/;
}
push @found, grep {-f $_ } glob($_) foreach @files;
return @found;
}
---------------------
To this:
---------------------
use vars qw($typelist);
use File::Find;
my @files = ('txt','html','dat', 'src');
$typelist ='\.'.join('|\.',@files);
my @search_files = find(\&wanted, $basedir);
sub wanted
{
return if(/^\./);
return unless(/$typelist/);
stat $File::Find::name;
return if -d _;
return unless (-w _);
}
----------------
|
|
From: Dave C. <da...@da...> - 2001-11-16 19:30:34
|
On Fri, Nov 16, 2001 at 02:09:39PM -0500, Joseph F. Ryan (rya...@os...) wrote:
> I was trudging through search.pl today, when I noticed that we weren't
> using File::Find. I am pretty sure that File::Find has been part of the
> core since 5.004, so why not use it? At any rate, I changed this:
>
> ----------------------
> my @files = ('*.txt','*.html','*.dat', '*.src');
> my @search_files = get_files(@files);
> sub get_files {
> my @files = @_;
> chdir($basedir) or die "Can't chdir to $basedir: $!\n";
> my @found;
> foreach (@files) {
> $_ .= '/*' if -d "./$_" && !/\*/;
> }
> push @found, grep {-f $_ } glob($_) foreach @files;
> return @found;
> }
> ---------------------
>
> To this:
>
> ---------------------
> use vars qw($typelist);
> use File::Find;
> my @files = ('txt','html','dat', 'src');
> $typelist ='\.'.join('|\.',@files);
> my @search_files = find(\&wanted, $basedir);
> sub wanted
> {
> return if(/^\./);
> return unless(/$typelist/);
> stat $File::Find::name;
> return if -d _;
> return unless (-w _);
> }
> ----------------
You're right. There's no good reason for not using File::Find. But in
this case doesn't it change the behaviour of the script?
There are a couple of differences that I can see:
1/ The old version only searched the direcotries it was given, the new one
searches subdirectories too.
2/ In the old version, you could tell it to search files using wildcards
like 'doc*.txt', can you still do that in your version?
Feel free to implement your change, but please use the $emulate_matts_code
flag that we discussed a couple of days ago. When that flag is true then
we must emulate Matt's code _exactly_.
Dave...
--
.sig missing...
|
|
From: Jonathan S. <gel...@ge...> - 2001-11-16 21:43:08
|
On Fri, 16 Nov 2001, Dave Cross wrote:
> On Fri, Nov 16, 2001 at 02:09:39PM -0500, Joseph F. Ryan (rya...@os...) wrote:
> > I was trudging through search.pl today, when I noticed that we weren't
> > using File::Find
>
<snip>
> Feel free to implement your change, but please use the $emulate_matts_code
> flag that we discussed a couple of days ago. When that flag is true then
> we must emulate Matt's code _exactly_.
>
This is one that I prepared earlier - and which I believe is being used by
the chemistry department of some university :
#!/usr/bin/perl -w
use strict;
use CGI qw(:standard);
use File::Find;
my $basedir = '/usr/local/apache/htdocs';
my $baseurl = 'http://localhost';
my $title = "Foo Foo Search";
my $title_url = 'http://localhost/';
my $search_url = 'http://localhost/search.html';
my $search = param('search');
my @pages;
find(\&getfiles,$basedir);
print header,start_html($title);
print "<UL>\n";
foreach (@pages)
{
print li,a({-href => $_->[0]}, $_->[1]),br,
"Size: $_->[2]",br,
"Last Modified : $_->[3]\n";
}
print "</UL>\n",end_html;
sub getfiles {
if ( /\.html?$/ && -T )
{
open(THIS,$_) || return;
my $text = do { local $/; <THIS> };
close(THIS);
if ( defined $search and $text =~ /$search/is )
{
my ($title) = $text =~ m#<title>(.*)</title>#is ;
$title ||= $_;
my $path = $File::Find::name;
$path =~ s/$basedir/$baseurl/;
push @pages,[$path,$title,-s, scalar localtime((stat)[9]) ];
}
}
}
No this isn't Matt compliant but it could be a start.
/J\
--
Jonathan Stowe |
<http://www.gellyfish.com> | This space for rent
|
|
|
From: Joseph F. R. <rya...@os...> - 2001-11-17 07:14:03
|
>You're right. There's no good reason for not using File::Find. But in
>this case doesn't it change the behaviour of the script?
>
>There are a couple of differences that I can see:
>
>1/ The old version only searched the direcotries it was given, the new one
> searches subdirectories too.
>
>2/ In the old version, you could tell it to search files using wildcards
> like 'doc*.txt', can you still do that in your version?
>
>Feel free to implement your change, but please use the $emulate_matts_code
>flag that we discussed a couple of days ago. When that flag is true then
>we must emulate Matt's code _exactly_.
Ah, complete oversight on my part. Thank you for pointing it out; took a
bit to get it up to par, but it should be alright now:
-----------------------------------------------
use vars qw($typelist @blocked);
my $basedir = '/indigo';
my @files = ('robot*' ,'pod','ftp*.html','txt','jpg');
my @directories = ('/indigo/lib/Pod');
@blocked = @directories;
my @filetypes = grep($_!~/[^a-z]/,@files);
my @wildcards = grep(/[^a-z]/,@files);
$typelist =
((@filetypes>0)?'(\.'.join(')|(\.',@filetypes).')':'').((@wildcards>0)?((@filetypes>0)?'|':'').join('|',map{s#\*(\.)#'.*?'.($1?'\.':'')#ge;$_='('.$_.')'}@wildcards):'');
my @search_files = find(\&wanted, $basedir);
sub wanted
{
return if(/^\./);
return unless (m/$typelist/i);
my @stats = stat $File::Find::name;
return if -d _;
return unless -r _;
foreach my $blocked (@blocked) {
return if ($File::Find::dir eq $blocked)
}
}
----------------------------------
That large amount of junk at the beginning constructs a regex to be used by
wanted. It works like this: First, every item in @files that does not have
a wildcard is extracted. Those will be treated as file extentions, and
translated into (\.ext). Next, every item in @files is extracted, and
treated as a pseudo regex. * are transliterated to .*?, and . are
translated to \. So robot* is translated into (robot.*?), and ftp*.html is
translated into (ftp.*?\.html). Each of "mini-regexes" are then joined by a
pipe, and used in the wanted function to match the desired filetypes. The
rest of the wanted sub is pretty standard; it filters out .htaccess etc
files,directories, and non-readables. Finally, the wanted sub filters out
any file in a directory that is listed in @directories (@blocked is set
equal to @directories so that wanted can use it; there is no way to pass
arguments to wanted (that I know of ...)). I know that is opposite of how
Matt's script works; however, it makes much more sense. Why should you have
to set every directory in your website to be searched just to filter out 1
directory? The good news is that the fix is easy if we still want to
emulate Matt; the last if statement in wanted simply needs to be changed to
unless to obtain his functionality.
|
|
From: Jonathan S. <gel...@ge...> - 2001-11-17 10:36:09
|
On Sat, 17 Nov 2001, Joseph F. Ryan wrote:
>
> $typelist =
> ((@filetypes>0)?'(\.'.join(')|(\.',@filetypes).')':'').((@wildcards>0)?((@filetypes>0)?'|':'').join('|',map{s#\*(\.)#'.*?'.($1?'\.':'')#ge;$_='('.$_.')'}@wildcards):'');
>
Gah! This is cute but probably a little JAPH like and opaque for some code
that is going to reach the eyes of people learning programming - this is
the kind of thing that is either going to cause people to think "I'm never
going to be able to learn that stuff" or confirm what people say about
Perl being a "Write Only Language".
Mind you I am having difficulty expressing this as a bunch of discreet
statements ;-}
Something like this perhaps :
my @files = ('robot*' ,'pod','ftp*.html','txt','jpg');
foreach my $file (@files)
{
$file =~ s/\./\\./g;
if ( $file !~ /[^a-z]/i )
{
$file = "(\\.$file)";
}
else
{
$file =~ s/\*/.*%/g;
$file =~ s/\?/.?/g;
$file =~ s/%/?/g;
$file = "($file)";
}
push @file_patterns, $file;
}
$typelist = join '|', @file_patterns;
print $typelist;
This should probably be tucked away in a subroutine somewhere.
/J\
--
Jonathan Stowe |
<http://www.gellyfish.com> | This space for rent
|
|
|
From: Joseph F. R. <rya...@os...> - 2001-11-18 07:26:47
|
At 10:36 AM 11/17/2001 +0000, Jonathan Stowe wrote:
>On Sat, 17 Nov 2001, Joseph F. Ryan wrote:
> >
> > $typelist =
> >
> ((@filetypes>0)?'(\.'.join(')|(\.',@filetypes).')':'').((@wildcards>0)?((@filetypes>0)?'|':'').join('|',map{s#\*(\.)#'.*?'.($1?'\.':'')#ge;$_='('.$_.')'}@wildcards):'');
> >
>
>Gah! This is cute but probably a little JAPH like and opaque for some code
>that is going to reach the eyes of people learning programming - this is
>the kind of thing that is either going to cause people to think "I'm never
>going to be able to learn that stuff" or confirm what people say about
>Perl being a "Write Only Language".
>
>Mind you I am having difficulty expressing this as a bunch of discreet
>statements ;-}
Hehe, sometimes I can't help myself. I am not sure how well yours works,
but the above will translate into below. Try this:
-----------------------
$typelist = '(\.';
$typelist .= join(')|(\.',@filetypes) if (@filetypes>0);
$typelist .= ')';
$typelist .= '|' if (@wildcards>0 && @filetypes>0);
foreach my $wildcard (@wildcards)
{
$wildcard =~ s/\*(\.)/'.*?'/g;
$wildcard .= '\.' if ($1);
$wildcard = '(' . $_ . ')';
}
$typelist .= join('|',@wildcards);
-------------------------
On a future not: I humbly apologize for making you sort through that; I was
just trying to be consise; figuring that the users wouldn't have to sort
through the black magic. I forgot that we were to also teach them. I
happen to write something insane like that again, you don't have to waste
time rewriting my code; just slap me in the face and make me sort through
my nonsense ;)
Joe Ryan
|
|
From: Jonathan S. <gel...@ge...> - 2001-11-16 21:36:06
|
On Sat, 17 Nov 2001, iain truskett wrote: > * Nick Cleaton (ni...@cl...) [16 Nov 2001 17:56]: > > > Here are the problems I can see in the current nms-cgi guestbook.pl > > script. > > > 1) Allows the upload of arbitrary HTML, $allow_html does nothing. > > True. > Fix straight away :) > > 2) Makes changes in response to a GET request. > > Is that really a problem? > Examine rfc2616 with reference to the term 'idempotent' ;-} I'll get the world famed HTTP pendant Alan Flavell in here to explain this if we have difficulty. I have a feeling that most of the scripts suffer from this problem unfortunately we do have to consider the compatibility with the legacy of the Existing Body Of Matts Scripts .... > > 3) Truncates and rewrites the file, so someone viewing the > > guestbook might see a short or empty guestbook during > > an update. > > True. Are you thinking a 'write to new file and mv it' thing? > I have a version of guestbook.pl that does this but is so vastly different from the version in CVS that I am holding off on it. > > Is anyone working on these ? > > > Shall I have a go ? > > Go for it? > Nick, how do you feel about sizing up the holes (and incompliancies) in all the scripts and documenting them - bearing in mind that we are going to have to support by default the existing behaviour (that is to say we can't lose the GET thing right now.) Once documented we can find willing slaves to implement the changes if necessary :) I would also like you to examine the 'spam pawn' potential in the FormMail.pl if you are up for the gig ... For the crowd - Nick is the one person who keeps me honest with respect to security matters at work I would trust him with my mothers servr ;-} /J\ |
|
From: iain t. <ic...@eh...> - 2001-11-18 05:59:56
|
* Jonathan Stowe (gel...@ge...) [16 Nov 2001 21:45]: > On Sat, 17 Nov 2001, iain truskett wrote: > > * Nick Cleaton (ni...@cl...) [16 Nov 2001 17:56]: [...] > > > 2) Makes changes in response to a GET request. > > > > Is that really a problem? > > Examine rfc2616 with reference to the term 'idempotent' ;-} Ah. Cool. Never knew about that. [...] > I have a feeling that most of the scripts suffer from this problem > unfortunately we do have to consider the compatibility with the legacy > of the Existing Body Of Matts Scripts .... Given the ease with which CGI.pm allows people to just access param() without worrying whether it's POSTed or GETed (maybe 'GOT') it's possible that quite a few scripts in the world have this problem. [snip about 'mv and rename' method of changing guestbook.html] > I have a version of guestbook.pl that does this but is so vastly different > from the version in CVS that I am holding off on it. Yes, well, mine uses Mason and a postgresql backend, so is very inappropriate. Does Apache pay any attention to any form of file locking? (Probably safe to say that even if IIS does, it would be a bugger locking the file.) cheers, -- iain. <http://eh.org/~koschei/> |
|
From: Jonathan S. <gel...@ge...> - 2001-11-18 18:34:29
|
On Sun, 18 Nov 2001, iain truskett wrote:
> * Jonathan Stowe (gel...@ge...) [16 Nov 2001 21:45]:
>
> > I have a feeling that most of the scripts suffer from this problem
> > unfortunately we do have to consider the compatibility with the legacy
> > of the Existing Body Of Matts Scripts ....
>
> Given the ease with which CGI.pm allows people to just access param()
> without worrying whether it's POSTed or GETed (maybe 'GOT') it's
> possible that quite a few scripts in the world have this problem.
>
Absolutely - I am probably as guilty of this as anyone but it is something
that should be considered - bear in mind that most of the work that we are
reviewing goes straight to $ENV{QUERY_STRING} without considering the
request method :)
> [snip about 'mv and rename' method of changing guestbook.html]
> > I have a version of guestbook.pl that does this but is so vastly different
> > from the version in CVS that I am holding off on it.
>
> Yes, well, mine uses Mason and a postgresql backend, so is very
> inappropriate.
>
Er, we'll save that for a later upgrade :)
> Does Apache pay any attention to any form of file locking? (Probably
> safe to say that even if IIS does, it would be a bugger locking the
> file.)
No. That is why the write to temporary file and mv is the only solution -
the web server doesnt respect a flock() on the requested files ...
/J\
--
Jonathan Stowe |
<http://www.gellyfish.com> | This space for rent
|
|
|
From: Nick C. <ni...@cl...> - 2001-11-19 13:43:47
|
On Fri, Nov 16, 2001 at 09:36:19PM +0000, Jonathan Stowe wrote: [SNIP] > > > 2) Makes changes in response to a GET request. > > > > Is that really a problem? > > > > Examine rfc2616 with reference to the term 'idempotent' ;-} > > I'll get the world famed HTTP pendant Alan Flavell in here to explain this > if we have difficulty. > > I have a feeling that most of the scripts suffer from this problem > unfortunately we do have to consider the compatibility with the legacy of > the Existing Body Of Matts Scripts .... There are security issues with allowing GET requests to do things rather than just display things, for example an attacker can use an IMG tag to cause a victim to submit an abusive guest book entry. A referer check helps here. How about allowing GET requests only in compatibility mode ? > Nick, how do you feel about sizing up the holes (and incompliancies) in > all the scripts and documenting them - bearing in mind that we are going > to have to support by default the existing behaviour (that is to say we > can't lose the GET thing right now.) Once documented we can find willing > slaves to implement the changes if necessary :) Yes, I'd like to have a go at that. > I would also like you to examine the 'spam pawn' potential in the > FormMail.pl if you are up for the gig ... Done, I think it's about as good as it's going to get given that we have to send the confirmation mail to a user supplied address. The only change that I would make is to include the HTTP client IP address in the mail somewhere, and maybe think about some rate limiting. -- Nick |
|
From: Nick C. <ni...@cl...> - 2001-11-20 08:38:22
|
On Fri, Nov 16, 2001 at 09:36:19PM +0000, Jonathan Stowe wrote:
>
> Nick, how do you feel about sizing up the holes (and incompliancies) in
> all the scripts and documenting them - bearing in mind that we are going
> to have to support by default the existing behaviour (that is to say we
> can't lose the GET thing right now.) Once documented we can find willing
> slaves to implement the changes if necessary :)
>
> I would also like you to examine the 'spam pawn' potential in the
> FormMail.pl if you are up for the gig ...
Here are the problems I can see. This is all from reading
the code, so some of these may be in error.
Highlights:
* I've changed my mind: guestbook and formmail are both
very handy if you're a spammer.
* Arbitrary command execution in search.pl if filenames
ending in "|" can be created.
* Loads of ways to display arbitrary HTML. This opens a
cross site scripting hole which makes it possible to
subvert other applications hosted on the same domain
as one of these scripts.
countdown
=========
User input passed unchecked to strftime. I was able to segfault
perl 5.00503 in libc under linux by passing negative numbers to
strftime, so some sort of sanity check is probably in order.
The line
> foreach (reverse 0 .. $#from_date)
allows an attacker to choose the number of goes around this loop.
No obvious impact.
ffa
===
locks the temporary file when adding a link, so different copies
of the script using different temporary file names will clash.
fails to seek to the end after flocking on update.
interpolates unchecked user input into output HTML.
interpolates unchecked user input into stored HTML.
formmail
========
Missing \Q \E around variables interpolated into patterns in
a couple of places.
A missing leading ^ renders the referer check ineffective.
check_required() accepts any recipient containing a substring
in @referers, so "localhost <vi...@vi...>" gets through,
allowing arbitrary spamming.
send_email() interpolates $Config{email} and $Config{realname}
into the header without checking for multiple lines, allowing
arbitrary To/Cc/Bcc headers and hence arbitrary spamming.
This could be quite attractive to spammers since many recipients
and other headers can be specified, and it's probably possible to
hide all the content that FormMail adds in the MIME preamble, so
the spammer gets full control of the content.
error() interpolates $Config{recipient} into the HTML, allowing
the display of arbitrary HTML.
guestbook
=========
Interpolates unchecked user input into displayed HTML in various
places.
Interpolates unchecked user input into stored HTML in various
places.
$allow_html fails to fully strip all HTML constructs
from the comments, e.g. "<img src='javascript:alert(1)' >"
With $allow_html turned on, we deliberately allow arbitrary
HTML, opening a cross site scripting hole. Need to have a
whitelist of harmless tags.
If $remote_mail is set, $username is interpolated into the input
of sendmail -t at the top of the message without sanity checking,
so the message structure and recipient list is under attacker
control. Nice for spamming.
imagecounter
============
The locking gets a bit funny if two copies of script are in
create() on the same counter at the same time.
rand_image
==========
Fails to seek to the end after flock when updating the
log file.
rand_link
=========
Missing leading "<" when opening $linkfile for read. No actual
problem since it's statically configured, but bad security style.
Doesn't seek to the end after flocking on log write, and opens
and closes the log file an extra time for no apparent reason.
rand_text
=========
Missing leading "<" when opening $randomfile for read. No actual
problem since it's statically configured, but bad security style.
search
======
Interpolates user input into pattern matches without \Q \E,
leading to a CPU-bound DoS.
Shell metacharacters in filenames could lead to arbitrary
command execution while FILE is opened.
Interpolates user input into output HTML with no checking.
ssi_rand_image
==============
Doesn't seek to the end after flock when updating the log.
textclock
=========
This script appears devoid of security issues. I feel strangely
cheated.
textcounter
===========
The locking gets a bit funny if two copies of script are in
create() on the same counter at the same time.
wwwboard
========
$allow_html fails to fully strip all HTML constructs
from the comments, e.g. "<img src='javascript:alert(1)' >"
With $allow_html turned on, we deliberately allow arbitrary
HTML, opening a cross site scripting hole. Need to have a
whitelist of harmless tags.
Interpolates unchecked user input into displayed HTML in various
places.
Interpolates unchecked user input into stored HTML in various
places.
Missing leading "<" on file opens.
passwd.txt can be fetched directly via HTTP for offline cracking
if stored within the doc root.
|
|
From: Joseph F. R. <rya...@os...> - 2001-11-20 15:40:22
|
Regarding search.pl: >* Arbitrary command execution in search.pl if filenames > ending in "|" can be created. 1.) I will add something to the wanted function to parse out filenames ending in |. [SNIP] >search >====== > >Interpolates user input into pattern matches without \Q \E, >leading to a CPU-bound DoS. 2.) I haven't gotten to this part of the script yet (been busy with midterms), but thanks for pointing it out. >Shell metacharacters in filenames could lead to arbitrary >command execution while FILE is opened. 3.) See 1. >Interpolates user input into output HTML with no checking. 4.) I'm going to fix that up completely, but you have an valid point [SNIP] Regarding countdown.pl: >countdown >========= > >User input passed unchecked to strftime. I was able to segfault >perl 5.00503 in libc under linux by passing negative numbers to >strftime, so some sort of sanity check is probably in order. 1.) Woopsy. Will do. Thanks. >The line > > foreach (reverse 0 .. $#from_date) >allows an attacker to choose the number of goes around this loop. >No obvious impact. 2.) I'm not sure what you mean here :) |
|
From: Nick C. <ni...@cl...> - 2001-11-20 17:35:37
|
On Tue, Nov 20, 2001 at 10:38:04AM -0500, Joseph F. Ryan wrote: > Regarding search.pl: > >* Arbitrary command execution in search.pl if filenames > > ending in "|" can be created. > > 1.) I will add something to the wanted function to parse out filenames > ending in |. Good. I've put a "<" on the open. > >The line > > > foreach (reverse 0 .. $#from_date) > >allows an attacker to choose the number of goes around this loop. > >No obvious impact. > > 2.) I'm not sure what you mean here :) That loop is over several arrays of 6 elements: @now, @skip, @diff and @from_date. Since @from_date is the only one that's controlled by CGI inputs (and so may contain more or less than 6 elements) it seems to me that "$#from_date" is a foolish encoding of "5". "$#now" or "$#diff" would be nicer. It's a very minor point really. -- Nick |
|
From: Jonathan S. <gel...@ge...> - 2001-11-21 10:03:30
|
On Tue, 20 Nov 2001, Nick Cleaton wrote:
> On Tue, Nov 20, 2001 at 10:38:04AM -0500, Joseph F. Ryan wrote:
>
> > >The line
> > > > foreach (reverse 0 .. $#from_date)
> > >allows an attacker to choose the number of goes around this loop.
> > >No obvious impact.
> >
> > 2.) I'm not sure what you mean here :)
>
> That loop is over several arrays of 6 elements: @now, @skip, @diff
> and @from_date.
>
> Since @from_date is the only one that's controlled by CGI inputs
> (and so may contain more or less than 6 elements) it seems to me
> that "$#from_date" is a foolish encoding of "5". "$#now" or
> "$#diff" would be nicer.
>
> It's a very minor point really.
>
Not necessarily. With pre 5.005 perl ( and bear in mind that we are
targetting 5.00404 ) the list over which for() iterates is actually built
internally before the iteration starts, so if an attacker could somehow
get @from_date to have $some_very_large number of elements it could cause
the allocation of large amounts of memory. <checks>
[gellyfish@orpheus test]$ cat test.c
#include "EXTERN.h"
#include "perl.h"
main()
{
printf("%d\n",sizeof(SV));
}
[gellyfish@orpheus test]$ cc -I /usr/lib/perl5/5.6.1/i686-linux/CORE
test.c
[gellyfish@orpheus test]$ ./a.out
12
bearing in mind none of the memory used by those SVs is reclaimed by the
OS, on some OS this could DoS the box quite effectively.
Mind the one you really want to look out for is:
for ( a .. ZZZZZZZ )
{
...
}
I don't recommend trying it on a Linux machine you can't afford to reboot
;-}
/J\
--
Jonathan Stowe |
<http://www.gellyfish.com> | This space for rent
|
|
|
From: Dave C. <da...@da...> - 2001-11-16 19:09:29
|
On Fri, Nov 16, 2001 at 06:45:57PM +0000, Nick Cleaton (ni...@cl...) wrote: > > Here are the problems I can see in the current nms-cgi guestbook.pl > script. > > 1) Allows the upload of arbitrary HTML, $allow_html does nothing. > > 2) Makes changes in response to a GET request. > > 3) Truncates and rewrites the file, so someone viewing the > guestbook might see a short or empty guestbook during > an update. > > Is anyone working on these ? > > Shall I have a go ? Please do :) Dave... -- Don't dream it... be it |
Thanks for helping keep SourceForge clean.
X