RE:Vulnerability awareness

[___cliff rayman___ <cl...@genwax.com>]

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
> ------
> hoping this is the apporpriate place to ask

--
___cliff rayman___www.genwax.com___cliff@genwax.com___

Re: Vulnerability awareness

[Gunther Birznieks <gu...@extropia.com>]

At 07:56 AM 6/7/00 -0400, Eric Strovink wrote:
>Gunther Birznieks wrote:
>
><snip>
>
> > >From: Jan Dubois <ja...@activestate.com>
> > >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.
>
><snip>
>
>This reminds me of a discussion that has been conducted here before.  One 
>could as
>well ask, "Isn't embperl [or any other embedded code implementation] a 
>security
>risk?"  One camp says of course not, you should protect yourself against 
>tainted
>user data, etc., plus whatever other ways exist to trick the server into 
>executing
>a foreign Perl fragment, and it's your fault if you don't, so there's no risk.
>Another camp says yes, if your server is *able* to execute embedded code 
>of some
>kind, then by enabling this capability you've added to the risk by 
>definition --
>and by the way, you can't claim to have thought of *all* the ways that someone
>might trick you into running a code frag, because you're probably not thinking
>about it as hard as they are.

Well, yes and no. At the end of the day, as the server admin you are 
choosing which directories and filetypes are enabled for embperl so it is 
protected in the same way as a cgi script from being run on the server.  If 
embperl then runs in the same model as mod_perl, then it would have the 
same vulnerabilities as I outlined in the part of the mail that was snipped.

The caching of data in a mod_perl server is the particular security 
vulnerability that there is a potential of exploiting. But not too many 
people would think that way, and the mod_perl program would have to be 
caching quite a bit of data on the server which usually is not recommended 
for individual apache program size anyway even if it might improve 
performance when there is enough RAM.

Later,
    Gunther



__________________________________________________
Gunther Birznieks (gunther.birznieks@extropia.com)
Extropia - The Web Technology Company
http://www.extropia.com/

Re: Vulnerability awareness

[Eric Strovink <st...@acm.org>]

Gunther Birznieks wrote:

<snip>

> >From: Jan Dubois <ja...@activestate.com>
> >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.

<snip>

This reminds me of a discussion that has been conducted here before.  One could as
well ask, "Isn't embperl [or any other embedded code implementation] a security
risk?"  One camp says of course not, you should protect yourself against tainted
user data, etc., plus whatever other ways exist to trick the server into executing
a foreign Perl fragment, and it's your fault if you don't, so there's no risk.
Another camp says yes, if your server is *able* to execute embedded code of some
kind, then by enabling this capability you've added to the risk by definition --
and by the way, you can't claim to have thought of *all* the ways that someone
might trick you into running a code frag, because you're probably not thinking
about it as hard as they are.

RE:Vulnerability awareness

[Gunther Birznieks <gu...@extropia.com>]

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 <ja...@activestate.com>
>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 (gunther.birznieks@extropia.com)
Extropia - The Web Technology Company
http://www.extropia.com/

RE:Vulnerability awareness

[Stas Bekman <sb...@stason.org>]

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 <ja...@activestate.com> 
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




_____________________________________________________________________
Stas Bekman              JAm_pH     --   Just Another mod_perl Hacker
http://stason.org/       mod_perl Guide  http://perl.apache.org/guide 
mailto:stas@stason.org   http://perl.org     http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org