Re: [PHP-DEV] uhm.. *swallows*.. security thingy?

2001-12-12 Thread Teodor Cimpoesu

Hi Zeev!
On Tue, 11 Dec 2001, Zeev Suraski wrote:

 At 15:23 11/12/2001, Mathieu Kooiman wrote:
 On Tue, 2001-12-11 at 14:04, Zeev Suraski wrote:
  At 12:36 11/12/2001, Mathieu Kooiman wrote:
  On Tue, 2001-12-11 at 11:29, Zeev Suraski wrote:
Would the cwd of the PHP CGI be inside the user's dir?  Did you 
 test it in
a real CGI environment?
   
Zeev
  
  Err, PHP CGI would be in /usr/local/bin/php..
 
  Yeah, but that's not what I asked - I asked about the cwd (current 
 working
  directory :)
 
 
 There are situaties where you have like:
 
 /opt/guide/somesite.com/cgi-bin
 /opt/guide/somesite.com/htdocs
 /opt/guide/somesite.com/logs
 
 cgi-bin and htdocs (2 possible cwds) are under user control.
 
 Yes, I know :)  The big question is whether PHP, when executed by Apache 
 (as a CGI), starts up in one of these directories, or in Apache's 
 directory.  If it starts in one of these directories - then indeed we have 
 a problem, because it'll search this directory for the php.ini.  If it 
 starts in Apache's directory, then there's no problem.
 
[rant++]
I don't think it's a problem for a user to make a copy of the php binary
somewhere in any of those dirs, where the cwd at runtime is a writeable dir...

-- teodor

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] uhm.. *swallows*.. security thingy?

2001-12-12 Thread Zeev Suraski

At 11:20 12/12/2001, Teodor Cimpoesu wrote:
[rant++]
I don't think it's a problem for a user to make a copy of the php binary
somewhere in any of those dirs, where the cwd at runtime is a writeable dir...

Well, if he can run arbitrary files from his own directories, you're 
screwed anyway, much more than any PHP related security exploit :)  The 
directories from which the server agrees to run binaries are quite limited.

Zeev


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] uhm.. *swallows*.. security thingy?

2001-12-11 Thread Mathieu Kooiman

There's a problem with PHP cgi binaries:

CaPS_ (was a CVS, so..)
CaPS_ which reminds me
CaPS_ remember my ranting about php.ini derick?
CaPS_ (it opens ./php.ini, config_file_path/php.ini, checks PHPRC
environment)
CaPS_ in that order
CaPS_ I got some 'friends' who work at hosters
CaPS_ and they don't like that
CaPS_ cos, ./php.ini will enable users to override safe mode
CaPS_ made a lill patch for him so it wouldn't
CaPS_ but, isn't it an idea to add --restrictive-hosting or something
that'll ''activate'' that patch ?
CaPS_ (limit php.ini to be in config-file-path)
OpenSrc yes
OpenSrc no switch
OpenSrc just reverse it :)
CaPS_ que
CaPS_ ?
OpenSrc change the order
OpenSrc let the MAIN php.ini override values in PHPRC/php.ini
CaPS_ it doesn't sequentially parse them
CaPS_ but one
OpenSrc oh
OpenSrc then that need to be fixed :)
CaPS_ either ./php.ini, php.ini or PHPRC
OpenSrc write it to php-dev

It allows users to set their own options in a ./php.ini, as in
override user_dir, open_basedir and safe_mode.

My default php.ini has error_reporting set to E_ALL:

test.php:

?php
echo $test;
?

php.ini-ex:
error_reporting = E_ALL  ~E_NOTICE

caps@anaina:~/php-4.1.0$ ./php -q test.php
PHP Warning: undefined variable: test in /home/caps/php-4.1.0/test.php
on line 3

caps@anaina:~/php-4.1.0$ mv php.ini-ex php.ini
caps@anaina:~/php-4.1.0$ ./php -q test.php
caps@anaina:~/php-4.1.0$

This was reported and discussed (on IRC) first on Nov 15
(http://bugs.php.net/bug.php?id=14071), granted.. filed incorrectly.

I'd say this is quite serious when you're a hoster who only allows PHP
in CGI mode.

Wouter de Jong is the one who actually discovered this.

-- 
Mathieu 'CaPS_' Kooiman [EMAIL PROTECTED]
MAP Internet Services






-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] uhm.. *swallows*.. security thingy?

2001-12-11 Thread Zeev Suraski

Would the cwd of the PHP CGI be inside the user's dir?  Did you test it in 
a real CGI environment?

Zeev

At 12:23 11/12/2001, Mathieu Kooiman wrote:
There's a problem with PHP cgi binaries:

CaPS_ (was a CVS, so..)
CaPS_ which reminds me
CaPS_ remember my ranting about php.ini derick?
CaPS_ (it opens ./php.ini, config_file_path/php.ini, checks PHPRC
environment)
CaPS_ in that order
CaPS_ I got some 'friends' who work at hosters
CaPS_ and they don't like that
CaPS_ cos, ./php.ini will enable users to override safe mode
CaPS_ made a lill patch for him so it wouldn't
CaPS_ but, isn't it an idea to add --restrictive-hosting or something
that'll ''activate'' that patch ?
CaPS_ (limit php.ini to be in config-file-path)
OpenSrc yes
OpenSrc no switch
OpenSrc just reverse it :)
CaPS_ que
CaPS_ ?
OpenSrc change the order
OpenSrc let the MAIN php.ini override values in PHPRC/php.ini
CaPS_ it doesn't sequentially parse them
CaPS_ but one
OpenSrc oh
OpenSrc then that need to be fixed :)
CaPS_ either ./php.ini, php.ini or PHPRC
OpenSrc write it to php-dev

It allows users to set their own options in a ./php.ini, as in
override user_dir, open_basedir and safe_mode.

My default php.ini has error_reporting set to E_ALL:

test.php:

?php
echo $test;
?

php.ini-ex:
error_reporting = E_ALL  ~E_NOTICE

caps@anaina:~/php-4.1.0$ ./php -q test.php
PHP Warning: undefined variable: test in /home/caps/php-4.1.0/test.php
on line 3

caps@anaina:~/php-4.1.0$ mv php.ini-ex php.ini
caps@anaina:~/php-4.1.0$ ./php -q test.php
caps@anaina:~/php-4.1.0$

This was reported and discussed (on IRC) first on Nov 15
(http://bugs.php.net/bug.php?id=14071), granted.. filed incorrectly.

I'd say this is quite serious when you're a hoster who only allows PHP
in CGI mode.

Wouter de Jong is the one who actually discovered this.

--
Mathieu 'CaPS_' Kooiman [EMAIL PROTECTED]
MAP Internet Services






--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] uhm.. *swallows*.. security thingy?

2001-12-11 Thread Zeev Suraski

At 12:36 11/12/2001, Mathieu Kooiman wrote:
On Tue, 2001-12-11 at 11:29, Zeev Suraski wrote:
  Would the cwd of the PHP CGI be inside the user's dir?  Did you test it in
  a real CGI environment?
 
  Zeev

Err, PHP CGI would be in /usr/local/bin/php..

Yeah, but that's not what I asked - I asked about the cwd (current working 
directory :)

'Wouter' tells me he has tested it in a real CGI environment.

This is exploitable iff the cwd of PHP when running as a CGI is a directory 
under the user's control.

Zeev


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] uhm.. *swallows*.. security thingy?

2001-12-11 Thread Mathieu Kooiman

On Tue, 2001-12-11 at 14:04, Zeev Suraski wrote:
 At 12:36 11/12/2001, Mathieu Kooiman wrote:
 On Tue, 2001-12-11 at 11:29, Zeev Suraski wrote:
   Would the cwd of the PHP CGI be inside the user's dir?  Did you test it in
   a real CGI environment?
  
   Zeev
 
 Err, PHP CGI would be in /usr/local/bin/php..
 
 Yeah, but that's not what I asked - I asked about the cwd (current working 
 directory :)
 

There are situaties where you have like:

/opt/guide/somesite.com/cgi-bin
/opt/guide/somesite.com/htdocs
/opt/guide/somesite.com/logs

cgi-bin and htdocs (2 possible cwds) are under user control.

(if *that*'s what you meant)

 'Wouter' tells me he has tested it in a real CGI environment.
 
 This is exploitable iff the cwd of PHP when running as a CGI is a directory 
 under the user's control.
 
 Zeev



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] uhm.. *swallows*.. security thingy?

2001-12-11 Thread Zeev Suraski

At 15:23 11/12/2001, Mathieu Kooiman wrote:
On Tue, 2001-12-11 at 14:04, Zeev Suraski wrote:
  At 12:36 11/12/2001, Mathieu Kooiman wrote:
  On Tue, 2001-12-11 at 11:29, Zeev Suraski wrote:
Would the cwd of the PHP CGI be inside the user's dir?  Did you 
 test it in
a real CGI environment?
   
Zeev
  
  Err, PHP CGI would be in /usr/local/bin/php..
 
  Yeah, but that's not what I asked - I asked about the cwd (current working
  directory :)
 

There are situaties where you have like:

/opt/guide/somesite.com/cgi-bin
/opt/guide/somesite.com/htdocs
/opt/guide/somesite.com/logs

cgi-bin and htdocs (2 possible cwds) are under user control.

Yes, I know :)  The big question is whether PHP, when executed by Apache 
(as a CGI), starts up in one of these directories, or in Apache's 
directory.  If it starts in one of these directories - then indeed we have 
a problem, because it'll search this directory for the php.ini.  If it 
starts in Apache's directory, then there's no problem.

Zeev


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]