On 21.03.2007, Rocky Zhou wrote:
> Today I found a problem, when I wrote a section of PHP code like
> this:
>
> > $fp = fopen("/etc/passwd","r");
> if($fp)
> {
> echo 'ok!';
> $result = fread($fp,
> 8192);
> return $result;
> echo $result;
> }
>
> else
> {
> echo 'no!';
> }
>
> ?>
>
> I found that it realy can read the passwd file!

That's terrible! PHP can open any file on filesystem! And it can even
read it!

> I'm not very familiar
> with PHP, so I don't know is there any configuration options to limit
> this behavior(in php.ini)? I think it isn't the apache problem, so it
> do no favor to modify httpd.conf, is it?

Have you looked at PHP's documentation? Especially part about
configuring PHP.

> I googled and get some infomation like 'open_basedir' parameter. But
> my LAMP sites have many virtual host, every host blongs to different
> user, his/her 'DocumentRoot' belongs to a system user like this:
> ls /www/users -l
> drwx--x--x 17 user_elnzpjps ftpd 4096 Mar 13 16:42 test11.com
> So I think it is not a good idea to make open_basedir to be 'www/
> users', because it's a problem when one user can read the files of
> another.
>
> So, what is the resolution?

PHPAdminValue and settings per vhost.

--
Secunia non olet.
Stanislaw Klekot

On Mar 21, 8:33 am, "Rocky Zhou" wrote:
> Today I found a problem, when I wrote a section of PHP code like
> this:
>
> > $fp = fopen("/etc/passwd","r");
> if($fp)
> {
> echo 'ok!';
> $result = fread($fp,
> 8192);
> return $result;
> echo $result;
>
> }
>
> else
> {
> echo 'no!';
>
> }
>
> ?>
>
> I found that it realy can read the passwd file!
[snip]

So? Of course it can read the passwd file. Everyone can read the
passwd file. That's how it is /supposed/ to work. You would have a
problem if processes could /not/ read the passwd file. Witness...
pitchl@phantom:~$ ls -l /etc/passwd
-rw-r--r-- 1 root root 722 2006-08-23 08:01 /etc/passwd

pitchl@phantom:~$ head -5 /etc/passwd
root:x:0:0::/root:/bin/bash
bin:x:1:1:bin:/bin:
daemon:x:2:2:daemon:/sbin:
adm:x:3:4:adm:/var/log:
lp:x:4:7:lp:/var/spool/lpd:

pitchl@phantom:~$

Now, can your PHP script /write/ to the passwd file? If so, then you /
do/ have a security problem. /etc/passwd should only be writable by
its owner, root.

I mean it is not only a '/etc/passwd' problem, you see, if a php
program can read /etc/passwd, it can read the whole file system too.
If there are many virtualhost, and every virtual host belongs to a
user, then one user can read the files of another user, this will lead
to problems, I think.

So I did this just like the advice.


DocumentRoot "/var/www/html/docs/html"
php_admin_value open_basedir /var/www/html/docs/html/

Options Indexes
AllowOverride None
Order allow,deny
Allow from all



Thank you.

On 3ÔÂ22ÈÕ, ÉÏÎç1ʱ37·Ö, "Lew Pitcher" wrote:
> On Mar 21, 8:33 am, "Rocky Zhou" wrote:
>
> > Today I found a problem, when I wrote a section of PHP code like
> > this:
>
> > > > $fp = fopen("/etc/passwd","r");
> > if($fp)
> > {
> > echo 'ok!';
> > $result = fread($fp,
> > 8192);
> > return $result;
> > echo $result;
>
> > }
>
> > else
> > {
> > echo 'no!';
>
> > }
>
> > ?>
>
> > I found that it realy can read the passwd file!
>
> [snip]
>
> So? Of course it can read the passwd file. Everyone can read the
> passwd file. That's how it is /supposed/ to work. You would have a
> problem if processes could /not/ read the passwd file. Witness...
> pitchl@phantom:~$ ls -l /etc/passwd
> -rw-r--r-- 1 root root 722 2006-08-23 08:01 /etc/passwd
>
> pitchl@phantom:~$ head -5 /etc/passwd
> root:x:0:0::/root:/bin/bash
> bin:x:1:1:bin:/bin:
> daemon:x:2:2:daemon:/sbin:
> adm:x:3:4:adm:/var/log:
> lp:x:4:7:lp:/var/spool/lpd:
>
> pitchl@phantom:~$
>
> Now, can your PHP script /write/ to the passwd file? If so, then you /
> do/ have a security problem. /etc/passwd should only be writable by
> its owner, root.

"Rocky Zhou" (07-03-21 19:36:35):

> I mean it is not only a '/etc/passwd' problem, you see, if a php
> program can read /etc/passwd, it can read the whole file system too.
> If there are many virtualhost, and every virtual host belongs to a
> user, then one user can read the files of another user, this will lead
> to problems, I think.

How surprising! PHP isn't particularly good at giving the user an idea
of the concept of secure code. It's not the responsibility of the
programming language. This is one reason, why you should try other
languages, and best, never return to PHP, if you're concerned about
security.

Your code is supposed to be secure and it is supposed to catch cases
where it would transmit /etc/passwd (or arbitrary files) over the wire.
If you don't understand that, you shouldn't be CGI-programming or
programming at all!


Regards,
E.S.


--
From the fact that this CGI program has been written in Haskell, it
follows naturally that this CGI program is perfectly secure.

On Thu, 22 Mar 2007 07:22:51 +0100, Ertugrul Soeylemez wrote:

>
> Your code is supposed to be secure and it is supposed to catch cases where
> it would transmit /etc/passwd (or arbitrary files) over the wire. If you
> don't understand that, you shouldn't be CGI-programming or programming at
> all!

fine, but isn't the OP pointing out a capability in PHP that can be
abused? Is your response analagous to "yes guns can kill, but if you
don't understand that you shouldn't use one". Not arguing here, just
clarify for me if you would.

On 22 Mar, 11:22, "mr.b" wrote:
>
> fine, but isn't the OP pointing out a capability in PHP that can be
> abused? Is your response analagous to "yes guns can kill, but if you
> don't understand that you shouldn't use one". Not arguing here, just
> clarify for me if you would.

1) exposing /etc/passwd is not an issue if shadow passwords are used
2) allowing PHP to read any file on the server is not an issue if the
system is dedicated (i.e. not shared)

It may be that the system is insecure - there is no evidence here that
PHP is behaving in any way to undermine security.

C.

On 2007-03-22, mr.b wrote:
> On Thu, 22 Mar 2007 07:22:51 +0100, Ertugrul Soeylemez wrote:
>
>>
>> Your code is supposed to be secure and it is supposed to catch cases where
>> it would transmit /etc/passwd (or arbitrary files) over the wire. If you
>> don't understand that, you shouldn't be CGI-programming or programming at
>> all!
>
> fine, but isn't the OP pointing out a capability in PHP that can be
> abused? Is your response analagous to "yes guns can kill, but if you
> don't understand that you shouldn't use one". Not arguing here, just
> clarify for me if you would.


huge{~}: ls -l /etc/passwd
-rw-r--r-- 1 root sys 818 Nov 23 09:01 /etc/passwd

Contemplate what the letter "r" means in the file mode.

--
Ignorance more frequently begets confidence than does knowledge: it is those
who know little, not those who know much, who so positively assert that this
or that problem will never be solved by science.
[email me at huge {at} huge (dot) org uk]

"Rocky Zhou" writes:

>I mean it is not only a '/etc/passwd' problem, you see, if a php
>program can read /etc/passwd, it can read the whole file system too.

No. /etc/passwd is purposely read only for everyone.

>If there are many virtualhost, and every virtual host belongs to a
>user, then one user can read the files of another user, this will lead
>to problems, I think.

Set up permissions properly.


>So I did this just like the advice.

>
> DocumentRoot "/var/www/html/docs/html"
> php_admin_value open_basedir /var/www/html/docs/html/
>
> Options Indexes
> AllowOverride None
> Order allow,deny
> Allow from all
>
>

>Thank you.

>On 3=D4=C222=C8=D5, =C9=CF=CE=E71=CA=B137=B7=D6, "Lew Pitcher" >mpatico.ca> wrote:
>> On Mar 21, 8:33 am, "Rocky Zhou" wrote:
>>
>> > Today I found a problem, when I wrote a section of PHP code like
>> > this:
>>
>> > >> > $fp =3D fopen("/etc/passwd","r");
>> > if($fp)
>> > {
>> > echo 'ok!';
>> > $result =3D fread($fp,
>> > 8192);
>> > return $result;
>> > echo $result;
>>
>> > }
>>
>> > else
>> > {
>> > echo 'no!';
>>
>> > }
>>
>> > ?>
>>
>> > I found that it realy can read the passwd file!
>>
>> [snip]
>>
>> So? Of course it can read the passwd file. Everyone can read the
>> passwd file. That's how it is /supposed/ to work. You would have a
>> problem if processes could /not/ read the passwd file. Witness...
>> pitchl@phantom:~$ ls -l /etc/passwd
>> -rw-r--r-- 1 root root 722 2006-08-23 08:01 /etc/passwd
>>
>> pitchl@phantom:~$ head -5 /etc/passwd
>> root:x:0:0::/root:/bin/bash
>> bin:x:1:1:bin:/bin:
>> daemon:x:2:2:daemon:/sbin:
>> adm:x:3:4:adm:/var/log:
>> lp:x:4:7:lp:/var/spool/lpd:
>>
>> pitchl@phantom:~$
>>
>> Now, can your PHP script /write/ to the passwd file? If so, then you /
>> do/ have a security problem. /etc/passwd should only be writable by
>> its owner, root.

On Thu, 22 Mar 2007 07:40:33 -0700, C. wrote:


thanks Huge and C. for the clarification

On 2007-03-22, C. wrote:
>
> 1) exposing /etc/passwd is not an issue if shadow passwords are used

Exposing /etc/passwd to the world *is* a security issue, as it gives
crackers account ids to attempt to crack, rather than making them guess
at both the id and password. If the users use strong passwords, this is
a relatively minor issue, but it still is one.

> 2) allowing PHP to read any file on the server is not an issue if the
> system is dedicated (i.e. not shared)

Allowing PHP to read and publish any readable file on the server can
also be an issue, as it could expose potential weaknesses in the web
server by publishing the config file(s).

> It may be that the system is insecure - there is no evidence here that
> PHP is behaving in any way to undermine security.

The real problem is, why would anyone writing a PHP or other web process
that takes user input trust said user input? If the programmer wants to
limit access to a particular directory, say, then he should write the
program to do so, *not* rely on the language to do it for him.

--keith

--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

Rocky Zhou wrote:
> Today I found a problem, when I wrote a section of PHP code like
> this:
>
> > $fp = fopen("/etc/passwd","r");
> if($fp)
> {
> echo 'ok!';
> $result = fread($fp,
> 8192);
> return $result;
> echo $result;
> }
>
> else
> {
> echo 'no!';
> }
>
> ?>
>
> I found that it realy can read the passwd file! I'm not very familiar
> with PHP, so I don't know is there any configuration options to limit
> this behavior(in php.ini)? I think it isn't the apache problem, so it
> do no favor to modify httpd.conf, is it?
>
> I googled and get some infomation like 'open_basedir' parameter. But
> my LAMP sites have many virtual host, every host blongs to different
> user, his/her 'DocumentRoot' belongs to a system user like this:
> ls /www/users -l
> drwx--x--x 17 user_elnzpjps ftpd 4096 Mar 13 16:42 test11.com
> So I think it is not a good idea to make open_basedir to be 'www/
> users', because it's a problem when one user can read the files of
> another.
>
> So, what is the resolution?
>
> Thank you.
>

Any user on the system can read /etc/passwd, that just lists user
accounts, including the one your PHP scripts run under. I'm not familiar
with the details of PHP/apache configuration, but it would seem to me
that setting up apache to run in a chroot jail would avoid this.

If someone does manage to use PHP to read /etc/passwd, all they can get
is usernames of local accounts. /etc/shadow, which contains actual
password hashes, should be unreadable to non-root accounts.

-Alex

Huge wrote:

> On 2007-03-22, mr.b wrote:
>> On Thu, 22 Mar 2007 07:22:51 +0100, Ertugrul Soeylemez wrote:
>>
>>>
>>> Your code is supposed to be secure and it is supposed to catch cases
>>> where it would transmit /etc/passwd (or arbitrary files) over the wire.
>>> If you don't understand that, you shouldn't be CGI-programming or
>>> programming at all!
>>
>> fine, but isn't the OP pointing out a capability in PHP that can be
>> abused? Is your response analagous to "yes guns can kill, but if you
>> don't understand that you shouldn't use one". Not arguing here, just
>> clarify for me if you would.
>
>
> huge{~}: ls -l /etc/passwd
> -rw-r--r-- 1 root sys 818 Nov 23 09:01 /etc/passwd
>
> Contemplate what the letter "r" means in the file mode.
>

really?
rotten?
right?
response?
no I know it's red.


--
Dancin in the ruins tonight
Tayo'y Mga Pinoy

Keith Keller writes:

>On 2007-03-22, C. wrote:
>>
>> 1) exposing /etc/passwd is not an issue if shadow passwords are used

>Exposing /etc/passwd to the world *is* a security issue, as it gives
>crackers account ids to attempt to crack, rather than making them guess
>at both the id and password. If the users use strong passwords, this is
>a relatively minor issue, but it still is one.

Fine. But why are you allowing your php script to both read and send out
info on any file in the system? That is a badly written php script. Fix it.


>> 2) allowing PHP to read any file on the server is not an issue if the
>> system is dedicated (i.e. not shared)

>Allowing PHP to read and publish any readable file on the server can
>also be an issue, as it could expose potential weaknesses in the web
>server by publishing the config file(s).

>> It may be that the system is insecure - there is no evidence here that
>> PHP is behaving in any way to undermine security.

>The real problem is, why would anyone writing a PHP or other web process
>that takes user input trust said user input? If the programmer wants to
>limit access to a particular directory, say, then he should write the
>program to do so, *not* rely on the language to do it for him.

Agreed.


>--keith

>--
>kkeller-usenet@wombat.san-francisco.ca.us
>(try just my userid to email me)
>AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
>see X- headers for PGP signature information

"Alex R." writes:

>Rocky Zhou wrote:
>> Today I found a problem, when I wrote a section of PHP code like
>> this:
>>
>> >> $fp = fopen("/etc/passwd","r");
>> if($fp)
>> {
>> echo 'ok!';
>> $result = fread($fp,
>> 8192);
>> return $result;
>> echo $result;
>> }
>>
>> else
>> {
>> echo 'no!';
>> }
>>
>> ?>
>>
>> I found that it realy can read the passwd file! I'm not very familiar
>> with PHP, so I don't know is there any configuration options to limit
>> this behavior(in php.ini)? I think it isn't the apache problem, so it
>> do no favor to modify httpd.conf, is it?
>>
>> I googled and get some infomation like 'open_basedir' parameter. But
>> my LAMP sites have many virtual host, every host blongs to different
>> user, his/her 'DocumentRoot' belongs to a system user like this:
>> ls /www/users -l
>> drwx--x--x 17 user_elnzpjps ftpd 4096 Mar 13 16:42 test11.com
>> So I think it is not a good idea to make open_basedir to be 'www/
>> users', because it's a problem when one user can read the files of
>> another.
>>
>> So, what is the resolution?
>>
>> Thank you.
>>

>Any user on the system can read /etc/passwd, that just lists user
>accounts, including the one your PHP scripts run under. I'm not familiar
>with the details of PHP/apache configuration, but it would seem to me
>that setting up apache to run in a chroot jail would avoid this.

>If someone does manage to use PHP to read /etc/passwd, all they can get
>is usernames of local accounts. /etc/shadow, which contains actual
>password hashes, should be unreadable to non-root accounts.

php is a program that YOU write, and does what YOU tell it to do. So why in
the world would you tell it to read and send out your /etc/passwd file?
This is like saying "Apache is insecure. If I put up a web page listing everyone's username and
password, then some cracker could read it and crack my system."
Don't do it!

>-Alex

On Mar 21, 7:37 pm, "Lew Pitcher" wrote:
> On Mar 21, 8:33 am, "Rocky Zhou" wrote:
>
> > Today I found a problem, when I wrote a section of PHP code like
> > this:
>
> > > > $fp = fopen("/etc/passwd","r");
> > if($fp)
> > {
> > echo 'ok!';
> > $result = fread($fp,
> > 8192);
> > return $result;
> > echo $result;
>
> > }
>
> > else
> > {
> > echo 'no!';
>
> > }
>
> > ?>
>
> > I found that it realy can read the passwd file!
>
> [snip]
>
> So? Of course it can read the passwd file. Everyone can read the
> passwd file. That's how it is /supposed/ to work. You would have a
> problem if processes could /not/ read the passwd file. Witness...
> pitchl@phantom:~$ ls -l /etc/passwd
> -rw-r--r-- 1 root root 722 2006-08-23 08:01 /etc/passwd
>
> pitchl@phantom:~$ head -5 /etc/passwd
> root:x:0:0::/root:/bin/bash
> bin:x:1:1:bin:/bin:
> daemon:x:2:2:daemon:/sbin:
> adm:x:3:4:adm:/var/log:
> lp:x:4:7:lp:/var/spool/lpd:
>
> pitchl@phantom:~$
>
> Now, can your PHP script /write/ to the passwd file? If so, then you /
> do/ have a security problem. /etc/passwd should only be writable by
> its owner, root.

-yes you are right,any user in the system can read /etc/passwd but
can't modify it,and they can't read /etc/shadow at all,this is the
default of linux permissions and iam afraid if anybody change this
default behavior this may cause some programs not to run,may it needs
to check for example where is the home directory for aparticular user
reside,so it's not php problem at all,it's related to the user that
php run with it's privileges,if you change php with any other
scripting language it will give you the same result.

On Mar 22, 8:22 am, Ertugrul Soeylemez wrote:
> "Rocky Zhou" (07-03-21 19:36:35):
>
> > I mean it is not only a '/etc/passwd' problem, you see, if a php
> > program can read /etc/passwd, it can read the whole file system too.
> > If there are many virtualhost, and every virtual host belongs to a
> > user, then one user can read the files of another user, this will lead
> > to problems, I think.
>
> How surprising! PHP isn't particularly good at giving the user an idea
> of the concept of secure code. It's not the responsibility of the
> programming language. This is one reason, why you should try other
> languages, and best, never return to PHP, if you're concerned about
> security.
>
> Your code is supposed to be secure and it is supposed to catch cases
> where it would transmit /etc/passwd (or arbitrary files) over the wire.
> If you don't understand that, you shouldn't be CGI-programming or
> programming at all!

-i don't agree with you when you told him to quit,if anybody fails,he
should try again.

> Regards,
> E.S.
>
> --
> From the fact that this CGI program has been written in Haskell, it
> follows naturally that this CGI program is perfectly secure.

"habibielwa7id" (07-03-23 05:34:19):

> > Your code is supposed to be secure and it is supposed to catch cases
> > where it would transmit /etc/passwd (or arbitrary files) over the
> > wire. If you don't understand that, you shouldn't be
> > CGI-programming or programming at all!
>
> -i don't agree with you when you told him to quit,if anybody fails,he
> should try again.

Failing doesn't mean not understanding. Only if he doesn't _understand_
that.


Regards,
Ertugrul Söylemez.


--
From the fact that this CGI program has been written in Haskell, it
follows naturally that this CGI program is perfectly secure.

"mr.b" (07-03-22 07:22:56):

> > Your code is supposed to be secure and it is supposed to catch cases
> > where it would transmit /etc/passwd (or arbitrary files) over the
> > wire. If you don't understand that, you shouldn't be CGI-programming
> > or programming at all!
>
> fine, but isn't the OP pointing out a capability in PHP that can be
> abused? Is your response analagous to "yes guns can kill, but if you
> don't understand that you shouldn't use one". Not arguing here, just
> clarify for me if you would.

This is not PHP-specific. Almost every programming language allows
reading arbitrary files (to which one has access). And yes, the analogy
is very good.


Regards,
Ertugrul Söylemez.


--
From the fact that this CGI program has been written in Haskell, it
follows naturally that this CGI program is perfectly secure.

On Mar 24, 4:17 am, Ertugrul Soeylemez
wrote:
> "habibielwa7id" (07-03-23 05:34:19):
>
> > > Your code is supposed to be secure and it is supposed to catch cases
> > > where it would transmit /etc/passwd (or arbitrary files) over the
> > > wire. If you don't understand that, you shouldn't be
> > > CGI-programming or programming at all!
>
> > -i don't agree with you when you told him to quit,if anybody fails,he
> > should try again.
>
> Failing doesn't mean not understanding. Only if he doesn't _understand_
> that.
>
> Regards,
> Ertugrul Söylemez.
>
> --
> From the fact that this CGI program has been written in Haskell, it
> follows naturally that this CGI program is perfectly secure.

never mind,may i didn't understand what you meant exactly,it's ok.