Onderwerp: Re[2]: Hijacking Apache 2 via mod_perl

Dear Ben Laurie,

--Thursday, January 22, 2004, 6:53:01 PM, you wrote to linux_4ever@yahoo.com:

BL> This is not a leak - mod_perl is a module that is compiled into Apache,
BL> and hence has access to all its resources (including memory). If you
BL> want to run untrusted Perl, then don't use mod_perl.

You're right: mod_perl is inside apache memory space and can access any
descriptor, so it's impossible to blame apache descriptor is leaked. But
you're wrong. mod_perl has access to memory, not perl script. At least,
it's possible to store descriptors table and implement check for
descriptor in every perl file/socket function inside mod_perl (and
mod_php and mod_something) and only allow access to std descriptors and
to descriptors open inside same script. The choice is between speed and
security.

--
~/ZARAZA
Êîãäà ïòè÷êà ïîãèáàåò îò îáæîðñòâà, åå íàíèçûâàþò íà âåðòåë. (Ëåì)

>At least, it's possible to store descriptors table and
>implement check for descriptor in every perl file/socket
>function inside mod_perl (and mod_php and mod_something) and
>only allow access to std descriptors and to descriptors open
>inside same script. The choice is between speed and security.

Right. To me, that sounds ideal. In these days of 3 GHz machines,
I don't mind a little extra checking if it makes things more
secure.

-Steve Grubb

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

>At least, it's possible to store descriptors table and
>implement check for descriptor in every perl file/socket
>function inside mod_perl (and mod_php and mod_something) and
>only allow access to std descriptors and to descriptors open
>inside same script. The choice is between speed and security.

Right. To me, that sounds ideal. In these days of 3 GHz machines,
I don't mind a little extra checking if it makes things more
secure.

-Steve Grubb

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

>Then one just writes a perl extension in C. Who's responsible
>then?

But don't you need root to add extentions?

>Who's responsible if you just write a C module which hijacks the
>descriptors?

Again, you need an admin to update apache's config.

>Where do you draw the line?

I would think apache should have a safe and defined interface
between itself and modules. I cannot possibly think of any file
descriptor besides 0, 1, &2 that a module would need. The logs
should be stderr, the module should open a descriptor itself, or
apache have an API just for that purpose.

Xinetd, stunnel, and sshd can all run completely untrusted
applications without leaking their listening descriptor. Why
can't apache? Its not just mod_perl, mod_php leaks the https
descriptor, too.

-Steve Grubb

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

>Then one just writes a perl extension in C. Who's responsible
>then?

But don't you need root to add extentions?

>Who's responsible if you just write a C module which hijacks the
>descriptors?

Again, you need an admin to update apache's config.

>Where do you draw the line?

I would think apache should have a safe and defined interface
between itself and modules. I cannot possibly think of any file
descriptor besides 0, 1, &2 that a module would need. The logs
should be stderr, the module should open a descriptor itself, or
apache have an API just for that purpose.

Xinetd, stunnel, and sshd can all run completely untrusted
applications without leaking their listening descriptor. Why
can't apache? Its not just mod_perl, mod_php leaks the https
descriptor, too.

-Steve Grubb

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

* 3APA3A <3APA3A@SECURITY.NNOV.RU> wrote:

> You're right: mod_perl is inside apache memory space and can access any
> descriptor, so it's impossible to blame apache descriptor is leaked. But
> you're wrong. mod_perl has access to memory, not perl script. At least,
> it's possible to store descriptors table and implement check for
> descriptor in every perl file/socket function inside mod_perl (and
> mod_php and mod_something) and only allow access to std descriptors and
> to descriptors open inside same script. The choice is between speed and
> security.

Then one just writes a perl extension in C. Who's responsible then?
Who's responsible if you just write a C module which hijacks the
descriptors? Where do you draw the line?

nd

* 3APA3A <3APA3A@SECURITY.NNOV.RU> wrote:

> You're right: mod_perl is inside apache memory space and can access any
> descriptor, so it's impossible to blame apache descriptor is leaked. But
> you're wrong. mod_perl has access to memory, not perl script. At least,
> it's possible to store descriptors table and implement check for
> descriptor in every perl file/socket function inside mod_perl (and
> mod_php and mod_something) and only allow access to std descriptors and
> to descriptors open inside same script. The choice is between speed and
> security.

Then one just writes a perl extension in C. Who's responsible then?
Who's responsible if you just write a C module which hijacks the
descriptors? Where do you draw the line?

nd

Steve G wrote:

>>Then one just writes a perl extension in C. Who's responsible
>>then?
> But don't you need root to add extentions?

>>Who's responsible if you just write a C module which hijacks the
>>descriptors?
> Again, you need an admin to update apache's config.

you need an admin to update the config file if you're trying to use the
LoadModule directive. but if mod_perl's already running (and if
..htaccess files aren't locked down enough), you can use the SetHandler
to load up any (malicous) modules you might need. afaik, loading a
module once in mod_perl will make it available to every child process.
if i've been reading this thread right (and there's a good chance i
haven't) then this would give EvilModule.pm access to the leaked fd's.

(i haven't tested this for httpd2/mod_perl2, but i know it holds true
for httpd1.3.x/mod_perl, and the new docs don't indicate any changes).

-jon
--
jon@divisionbyzero.com || www.divisionbyzero.com
gpg key: www.divisionbyzero.com/pubkey.asc
think i have a virus? www.divisionbyzero.com/pgp.html
"You are in a twisty little maze of Sendmail rules, all confusing."

Steve G wrote:

>>Then one just writes a perl extension in C. Who's responsible
>>then?
> But don't you need root to add extentions?

>>Who's responsible if you just write a C module which hijacks the
>>descriptors?
> Again, you need an admin to update apache's config.

you need an admin to update the config file if you're trying to use the
LoadModule directive. but if mod_perl's already running (and if
..htaccess files aren't locked down enough), you can use the SetHandler
to load up any (malicous) modules you might need. afaik, loading a
module once in mod_perl will make it available to every child process.
if i've been reading this thread right (and there's a good chance i
haven't) then this would give EvilModule.pm access to the leaked fd's.

(i haven't tested this for httpd2/mod_perl2, but i know it holds true
for httpd1.3.x/mod_perl, and the new docs don't indicate any changes).

-jon
--
jon@divisionbyzero.com || www.divisionbyzero.com
gpg key: www.divisionbyzero.com/pubkey.asc
think i have a virus? www.divisionbyzero.com/pgp.html
"You are in a twisty little maze of Sendmail rules, all confusing."

On Thu, 22 Jan 2004, Steve G wrote:
> Xinetd, stunnel, and sshd can all run completely untrusted
> applications without leaking their listening descriptor. Why
> can't apache? Its not just mod_perl, mod_php leaks the https
> descriptor, too.

Xinetd, stunnel, and sshd all run completely untrusted applications by
fork()ing, setuid()ing, removing privileged access, and exec()ing an
entirely new chunk of code. You therefore have a clearly-defined barrier
between the privileged system (sshd) and the program it runs (bash, for
example).

The purpose of mod_perl is to run perl code without having to exec a whole
whacking great perl interpreter every time someone accesses a page.
Therefore, the perl is brought inside the apache process-space, and all
that nasty slow fork() and exec() is got rid of.

A consequence of this is security. The apache process MUST be able to get
hold of those priveleged resources again in time for the next request it
has to handle, otherwise it would have to die have have a new apache
process take its place, which would rather defeat the purpose of bringing
perl in-process in the first place. Therefore, if the apache code is able
to regain priveleges, the perl code can too.

If you want to run untrusted code, don't bring it inside a process that
has privileged access.

Matthew

--
[About NP-completeness] These are the problems that make efficient use of
the Fairy Godmother. -- Computer Science Lecturer

On Thu, 22 Jan 2004, Steve G wrote:
> Xinetd, stunnel, and sshd can all run completely untrusted
> applications without leaking their listening descriptor. Why
> can't apache? Its not just mod_perl, mod_php leaks the https
> descriptor, too.

Xinetd, stunnel, and sshd all run completely untrusted applications by
fork()ing, setuid()ing, removing privileged access, and exec()ing an
entirely new chunk of code. You therefore have a clearly-defined barrier
between the privileged system (sshd) and the program it runs (bash, for
example).

The purpose of mod_perl is to run perl code without having to exec a whole
whacking great perl interpreter every time someone accesses a page.
Therefore, the perl is brought inside the apache process-space, and all
that nasty slow fork() and exec() is got rid of.

A consequence of this is security. The apache process MUST be able to get
hold of those priveleged resources again in time for the next request it
has to handle, otherwise it would have to die have have a new apache
process take its place, which would rather defeat the purpose of bringing
perl in-process in the first place. Therefore, if the apache code is able
to regain priveleges, the perl code can too.

If you want to run untrusted code, don't bring it inside a process that
has privileged access.

Matthew

--
[About NP-completeness] These are the problems that make efficient use of
the Fairy Godmother. -- Computer Science Lecturer