At 11:45 AM 6/7/00 +0300, Stas Bekman wrote:
>On Tue, 6 Jun 2000, ___cliff rayman___ wrote:
>
> > here is something posted to p5p today.
> > looks like a good place to start Stas's challenge.
>
> > Benjamin Elijah Griffin wrote:
> >
> > > In alt.hackers a while ago I saw this .sig:
> > >
> > > #!/usr/bin/perl
> > > $j=\$j;{$_=unpack(P25,pack(L,$j));/Just Another Perl
> Wannabe/?print:$j++&&redo}
> > >
> > > It occured to me after the xlockmore stuff in bugtraq recently that
> > > having a way to get a pointer in perl and roam around memory looking
> > > for stuff might pose a security problem for embeded perl, eg:
> > > a mod_perl script that roams around apache reading passwords stored
> > > still in memory.
> > >
> > > Is this something to worry about?
> > >
> > > Benjamin
>
>It talks about user being able to run arbitrary Perl code thru your CGI,
>look at this reply:
>
>From: Jan Dubois <[EMAIL PROTECTED]>
>I don't think so. You should never let people execute arbitrary code on
>your web server anyways. If you do, then the potential intruder can do
>much more nasty things than just snooping around in memory.
>-Jan
I think Jan is right to some degree. But he's also not necessarily thinking
outside the box which is exactly what a hacker will do.
That's what I hate about web security, it's easy to poo-poo something as
being a security hole, but that's precisely how security holes are
uncovered. By a hacker thinking outside the box of what the original
developer thought could be possible holes.
Here's one scenario I imagine that could make a combination of the code
snippet above plus a mod_perl server being hacked into more dangerous than
a standard CGI/Perl Apache Server:
A single mod_perl server can be up for hours collecting passwords and
authentication credentials. It is conceivable that this information may be
cached in the Perl memory by
modules and whatnot to make the script run faster by a programmer concerned
about performance.
It is in this scenario that being able to execute arbirtrary code is quite
dangerous. In one feel swoop, a hacker can snoop the entire history of what
has happened on that mod_perl server engine.
Whereas, to get the same data without snooping memory, they would have to
basically replace the script and the web server with hooks that records the
passwords and other confidential information as they are entered. This
could take hours and by that time, intrusion detection software may have
caught wind of the hacker and raised alerts.
In addition, the comment that snooping in memory is less nasty than other
things is not thinking outside the developer box. For a normal website like
ours which just serves content but does not contain proprietary
information, it would simply suck to have the website deleted. Snooping
memory is a "well, whatever" sort of problem. Probably ActiveState is similar.
But a bank may think differently. I am sure they would rather their website
was deleted than their precious customer data (and hence their reputation
for maintaining confidentiality) were to be impaired.
Anyway, this is not meant to be down on what Jan said in his quote as I
highly respect his work (and liked his Win32 info that he talked about at
PerlCon last year) but it shows precisely how an extremely clever developer
like Jan isn't necessarily thinking about the same things that a hacker
might think about.
One type thinks about how to create things, the other thinks about how to
destroy things. It's a different way of thinking altogether.
A person may think it is easier to destroy than create, but I assure them
that destroying things that have been lovingly protected by the developer
is a highly creative task in the computer world and not to be taken for
granted.
Later,
Gunther
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
Extropia - The Web Technology Company
http://www.extropia.com/
