PHP blamed for security problems

[Tim Tyler]

Re: PHP blamed for security problems

R. Rajesh Jeba Anbiah <ng4rrjanbiah@r ediffmail.com> wrote or quoted:
[color=blue]
> 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.[/color]

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/ tim@tt1lock.org Remove lock to reply.

[Tim Tyler]

Re: PHP blamed for security problems

Tim Van Wassenhove <euki@pi.be> wrote or quoted:[color=blue]
> On 2004-03-16, Tim Tyler <tim@tt1lock.or g> wrote:[/color]
[color=blue][color=green]
> > 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.[/color]
>
> 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?[/color]

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/ tim@tt1lock.org Remove lock to reply.

[Tim Tyler]

Re: PHP blamed for security problems

MyOdd <spambucket@myo ddweb.com> wrote or quoted:
[color=blue]
> Maybe php could prevent the usage of include(...) from a $_GET/$_POST but
> how can that really be enforced...[/color]

By not running code taken from remote machines, perhaps?
[color=blue]
> 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.[/color]

Better to eliminate the risks at source - rather than scan every script
in the universe.
--
__________
|im |yler http://timtyler.org/ tim@tt1lock.org Remove lock to reply.

[Tim Van Wassenhove]

Re: PHP blamed for security problems

On 2004-03-18, Tim Tyler <tim@tt1lock.or g> wrote:[color=blue]
> Tim Van Wassenhove <euki@pi.be> wrote or quoted:[color=green]
>> On 2004-03-16, Tim Tyler <tim@tt1lock.or g> wrote:[/color]
>[color=green][color=darkred]
>> > 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.[/color]
>>
>> 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?[/color]
>
> 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.[/color]

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

[Tim Tyler]

Re: PHP blamed for security problems

Tim Van Wassenhove <euki@pi.be> wrote or quoted:[color=blue]
> On 2004-03-18, Tim Tyler <tim@tt1lock.or g> wrote:[color=green]
> > Tim Van Wassenhove <euki@pi.be> wrote or quoted:[color=darkred]
> >> On 2004-03-16, Tim Tyler <tim@tt1lock.or g> wrote:[/color][/color][/color]
[color=blue][color=green][color=darkred]
> >> > 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?[/color]
> >
> > 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.[/color]
>
> Imho the one to blame for should be the sysadmin for not using shadow
> passwords. [...][/color]

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/ tim@tt1lock.org Remove lock to reply.

[Tim Van Wassenhove]

Re: PHP blamed for security problems

On 2004-03-18, Tim Tyler <tim@tt1lock.or g> wrote:[color=blue]
> Tim Van Wassenhove <euki@pi.be> wrote or quoted:[color=green]
>> On 2004-03-18, Tim Tyler <tim@tt1lock.or g> wrote:[color=darkred]
>> > Tim Van Wassenhove <euki@pi.be> wrote or quoted:
>> >> On 2004-03-16, Tim Tyler <tim@tt1lock.or g> wrote:[/color][/color]
>[color=green][color=darkred]
>> >> > 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.[/color]
>>
>> Imho the one to blame for should be the sysadmin for not using shadow
>> passwords. [...][/color]
>
> 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.[/color]

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

[Tim Tyler]

Re: PHP blamed for security problems

Tim Tyler <tim@tt1lock.or g> wrote or quoted:[color=blue]
> Tim Van Wassenhove <euki@pi.be> wrote or quoted:[color=green]
> > On 2004-03-18, Tim Tyler <tim@tt1lock.or g> wrote:[color=darkred]
> > > Tim Van Wassenhove <euki@pi.be> wrote or quoted:
> > >> On 2004-03-16, Tim Tyler <tim@tt1lock.or g> wrote:[/color][/color][/color]
[color=blue][color=green][color=darkred]
> > >> > 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.[/color]
> >
> > Imho the one to blame for should be the sysadmin for not using shadow
> > passwords. [...][/color]
>
> 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.[/color]

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/ tim@tt1lock.org Remove lock to reply.

[R. Rajesh Jeba Anbiah]

Re: PHP blamed for security problems

Tim Tyler <tim@tt1lock.or g> wrote in message news:<HuroHw.HC o@bath.ac.uk>.. .[color=blue]
> R. Rajesh Jeba Anbiah <ng4rrjanbiah@r ediffmail.com> wrote or quoted:
>[color=green]
> > 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.[/color]
>
> 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.[/color]

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

[MyOdd]

Re: PHP blamed for security problems

[color=blue]
> MyOdd <spambucket@myo ddweb.com> wrote or quoted:
>[color=green]
> > Maybe php could prevent the usage of include(...) from a $_GET/$_POST[/color][/color]
but[color=blue][color=green]
> > how can that really be enforced...[/color]
>
> By not running code taken from remote machines, perhaps?[/color]

That would be a very good start IMHO.
[color=blue][color=green]
> > I have been wanting to write an app for some times that go thru php[/color][/color]
scripts[color=blue][color=green]
> > and flags possible security risks. I don't know if i really have the[/color][/color]
time[color=blue][color=green]
> > to.[/color]
>
> Better to eliminate the risks at source - rather than scan every script
> in the universe.[/color]

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.

[Tim Tyler]

Re: PHP blamed for security problems

R. Rajesh Jeba Anbiah <ng4rrjanbiah@r ediffmail.com> wrote or quoted:[color=blue]
> Tim Tyler <tim@tt1lock.or g> wrote in message news:<HuroHw.HC o@bath.ac.uk>.. .[color=green]
> > R. Rajesh Jeba Anbiah <ng4rrjanbiah@r ediffmail.com> wrote or quoted:[/color][/color]
[color=blue][color=green][color=darkred]
> > > 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.[/color]
> >
> > 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.[/color]
>
> 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.[/color]

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/ tim@tt1lock.org Remove lock to reply.

[Tim Tyler]

Re: PHP blamed for security problems

Tim Van Wassenhove <euki@pi.be> wrote or quoted:
[color=blue]
> 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..[/color]

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/ tim@tt1lock.org Remove lock to reply.

[Tim Van Wassenhove]

Re: PHP blamed for security problems

On 2004-03-19, Tim Tyler <tim@tt1lock.or g> wrote:[color=blue]
> Tim Van Wassenhove <euki@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.[/color]

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 ;)
[color=blue]
> At the very least you could publicly expose the source code of
> practically everything to the attackers.[/color]

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

--

http://home.mysth.be/~timvw

[Tim Tyler]

Re: PHP blamed for security problems

Tim Van Wassenhove <euki@pi.be> wrote or quoted:[color=blue]
> On 2004-03-19, Tim Tyler <tim@tt1lock.or g> wrote:[/color]
[color=blue][color=green]
> > 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.[/color]
>
> 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.[/color]

The webserver usually has to do some writing - to log files, and so
forth. It needs to be able to write files.
[color=blue][color=green]
> > At the very least you could publicly expose the source code of
> > practically everything to the attackers.[/color]
>
> Security through obscurity doesn't work anyway. So what is the problem?[/color]

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/ tim@tt1lock.org Remove lock to reply.

[Tim Van Wassenhove]

Re: PHP blamed for security problems

On 2004-03-19, Tim Tyler <tim@tt1lock.or g> wrote:[color=blue]
> Tim Van Wassenhove <euki@pi.be> wrote or quoted:[color=green]
>> On 2004-03-19, Tim Tyler <tim@tt1lock.or g> wrote:[/color]
>[color=green][color=darkred]
>> > 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.[/color]
>>
>> 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.[/color]
>
> The webserver usually has to do some writing - to log files, and so
> forth. It ow would this be devestating?[/color]
Sample code that runs on a box with safe_mode=on would be nice.
[color=blue][color=green][color=darkred]
>> > At the very least you could publicly expose the source code of
>> > practically everything to the attackers.[/color][/color]
> Security through obscurity is a technical phrase from cryptography.[/color]

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

[thumb_42@yahoo.com]

Re: PHP blamed for security problems

Tim Tyler <tim@tt1lock.or g> wrote:
[color=blue]
> In this case, PHP is at fault.[/color]

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)
[color=blue]
>
> 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.[/color]

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.
[color=blue]
>
> 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 ;-)[/color]


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