Mailing List Archive

Hi all,

On Thu, 23 Dec 2004 12:56:57 -0700, Chris Schwerdt
<Chris.Schwerdt@psi-cu-software.com> wrote:
> With the www user running PHP it is possible for scripts to have
> read-access to all vhosts and files.

the config file is owned by root, it's read by the first apache
process, which takes care of config file and logging..it's not www,
nor world readable.


> I believe it to be a much larger
> security risk as a hole in any vhost allows for the compromise of many
> users. Also, local users have access to other users PHP scripts, which
> usually contain DB passwords and other private information. I HIGHLY
> recommend using suPHP in any sort of virtual hosting environment.
>

1) We have few (3 vhosts) which are public, and known, knowing about
them is not a problem.
2) users are informed that they should use ACLs for web content
(giving access to www only instead of world)
3) users are warned that password should allways be kept cripted, and
they are responsible for correctly setting the permissions of their
files, and that they share a common machine, having world readable
permissions is BAD.

Also, the problems of a break in on a user acount, are much higher:
access to all files and mail, possibility of installing loggers,
personification, etc.. not only world readable file with sensitive
information (which is the users fault).


> Safe mode is widely viewed as a hack and causes many PHP scripts to
> become non-functional.
>

widely viewed has a hack? by whom? and most importantly why?

Safe mode isn't 100% safe, obviously, and it just sets a more
restrictive environment for the programmer.
It might brake some scripts, yes, since we are reducing the funcionality of php
in some ways that we consider might be problematic.
The users should take care to make shure their scripts/code does what
they want without using funcionality that we are removing. I know
that, and I assume totally that possible breakage.

OTOH, suphp has escalated priveleges during its execution, and if
anything goes wrong in that timespan.. BANG -> "bow before me, for I
am root".
look at this:
http://www.securityfocus.com/archive/1/372673
http://www.google.pt/search?q=cache:qT4J5NZLLMkJ:lists.marsching.biz/pipermail/suphp/2004-August/000814.html+suphp+exploit&hl=pt-PT&client=firefox
http://www.securityfocus.com/bid/11020

the setuid bit is widely viewed has a hack and the big security
problem in the UNIX architecture.
suexec is also a hack, a necessary one, apache guys advise against its
use, and say that they cannot warrantie its safe.

All suids are a problem because of that, nobody can assure that's
bug-free and not exploitable.

ALL SUID ARE IN ESSENCE ESCALATION OF PRIVELEGES.

A few AIX local root exploit came out these last weeks, in which only
setting a environment variable in a given way would give you root. too
many things influence the behavior of one aplication. one should run
then with the minimum necessary priveleges..

thank you for your advice, but I think suphp is a wrong aproach.

> > -----Original Message-----
> > From: Miguel Filipe [mailto:miguel.filipe@gmail.com]
> > Sent: Thursday, December 23, 2004 12:49 PM
> > To: gentoo-server@lists.gentoo.org; Michael Stewart;
> > gentoo-security@lists.gentoo.org
> > Subject: Re: [gentoo-server] about php security.. big
> > apache+php deploy
> >
> > Hi there,
> > About using php has a cgi, i've considered that but:
> >
> > The www user is pretty locked down, much more than a regular
> > user, that can ssh, ftp, use mail etc...
> > using cgi will allow intruders to break into a student
> > acount, were they can do more damage that whith the www user.
> >
> > Also, its harder to audit and monitor 6000 possible user
> > acount break ins, than a www breakin.
> >
> > we also don't use vhosts, we use user_dir and were trying to
> > see if we can use that with:
> > open_basedir
> > upload_tmp_dir
> > safe_mode_exec_dir
> > tell me more *dir variables that may be handy. :)
> >
> > Best Regards,
> >
> > On Wed, 22 Dec 2004 09:28:57 -0800, Michael Stewart
> > <vericgar@gentoo.org> wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Miguel Filipe wrote:
> > > | Hi there,
> > > |
> > > | To put things simple, I'm a bit worried with php, here's why:
> > > |
> > > | I don't know SHIT about securing php instalations...
> > > | I've read about hardened-php, and I wondered if someone
> > uses it, and
> > > | how reliable and intrusive they are ( false positives interest me
> > > | especially).
> > > | Also I would like to receive input from mod_security users...from
> > > | what I understood, if that's enabled, then in a php forum
> > I cannot
> > > | write/quote SQL code in my posts... (sql injection prevention..)
> > > |
> > > | The problem is a big server, 6000 acounts with
> > > | apache+suexec+user_dir+php, on a solaris machine.
> > > | I plan to try changing config options and security settings so it
> > > | becomes a bit more hardened.
> > > |
> > > |
> > > | Any advices are welcome.
> > > |
> > > | ps: don't "advice" me to close the server, deny
> > funcionality, etc,
> > > | these won't do... the server exists, has the acounts and I got to
> > > | live with it...
> > > |
> > >
> > > PHP can be difficult to secure in a multi-user environment. There's
> > > safe_mode, but that can be too restrictive at times and
> > IIRC has some
> > > ways around it.
> > >
> > > If you were doing vhosts instead of user_dirs (i.e.
> > > username.example.com instead of example.com/~username) you
> > could use
> > > open_basedir to keep them from opening or creating any file outside
> > > their $HOME. Though with 6000 users that could get tedious to
> > > maintain, though that could be scripted as well. If you do go this
> > > route, make sure to set a tmpdir that is under the open_basedir so
> > > that they can still make use of file uploads.
> > >
> > > You can also setup PHP in CGI mode, though that has some caveats as
> > > well (have to put the path to PHP as the first line of the script,
> > > though I think there's a way around this as well), but once
> > you get it
> > > working, the php script can run under suexec and so as the user
> > > instead of as the webserver. Though there is a performance hit when
> > > you do it that way as well. But with 6000 users, I don't
> > think you are
> > > worried to much about web-scripting performance.
> > >
> > > - --
> > > Michael Stewart
> > vericgar@gentoo.org
> > > Gentoo Developer
> > http://dev.gentoo.org/~vericgar
> > >
> > > GnuPG Key ID 0x08614788 available on http://pgp.mit.edu
> > > - --
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1.2.6 (GNU/Linux)
> > >
> > > iD8DBQFBya7Y3v7BtghhR4gRAnQgAJ4uXfhgV0ON1KljZjxY1vRtIHYVhwCffSq0
> > > 54lxLOqbxcQgV1LocQpQguY=
> > > =vTyw
> > > -----END PGP SIGNATURE-----
> > >
> >
> >
> > --
> > Miguel Sousa Filipe
> >
>


--
Miguel Sousa Filipe

--
gentoo-security@gentoo.org mailing list

Hi,
To make it short, I agree with you that
php in mod_php means that any php has access to www readable..
and that means mysql passwords, sensitive information readable by www.

but suphp will only passes the problem from www user to the actual user....
safe_mode can minorize the problem (since is't not 100% safe).

and a owned user acount looks to me more problematic than a locked
down www acount.

also, there's monitoring www:
ps -u www, lsof -u www, audit logs of www user...
and monitoring 6000 acounts... hell.. pure hell...

thanks,

On Thu, 23 Dec 2004 16:51:16 -0700, Chris Schwerdt
<Chris.Schwerdt@psi-cu-software.com> wrote:
> Responses inline....
>
> > -----Original Message-----
> > From: Miguel Filipe [mailto:miguel.filipe@gmail.com]
> > Sent: Thursday, December 23, 2004 2:45 PM
> > To: Chris Schwerdt; gentoo-security@lists.gentoo.org;
> > gentoo-server@lists.gentoo.org
> > Subject: Re: [gentoo-server] about php security.. big
> > apache+php deploy
> >
> > Hi all,
> >
> > On Thu, 23 Dec 2004 12:56:57 -0700, Chris Schwerdt
> > <Chris.Schwerdt@psi-cu-software.com> wrote:
> > > With the www user running PHP it is possible for scripts to have
> > > read-access to all vhosts and files.
> >
> > the config file is owned by root, it's read by the first
> > apache process, which takes care of config file and
> > logging..it's not www, nor world readable.
> >
>
> I wasn't just talking about the httpd.conf. PHP runs scripts as the WWW
> user. Therefore it has access to anything that the httpd process has
> access to.

correct.

>
> >
> > > I believe it to be a much larger
> > > security risk as a hole in any vhost allows for the
> > compromise of many
> > > users. Also, local users have access to other users PHP scripts,
> > > which usually contain DB passwords and other private
> > information. I
> > > HIGHLY recommend using suPHP in any sort of virtual hosting
> > environment.
> > >
> >
> > 1) We have few (3 vhosts) which are public, and known,
> > knowing about them is not a problem.
> > 2) users are informed that they should use ACLs for web
> > content (giving access to www only instead of world)
> > 3) users are warned that password should allways be kept
> > cripted, and they are responsible for correctly setting the
> > permissions of their files, and that they share a common
> > machine, having world readable permissions is BAD.
> >
> > Also, the problems of a break in on a user acount, are much higher:
> > access to all files and mail, possibility of installing
> > loggers, personification, etc.. not only world readable file
> > with sensitive information (which is the users fault).
> >
>
> Any bypass of safe mode will allow that user account to view any file
> that www can read. Again, it doesn't matter if files in user accounts
> public_html/ are not world readable because they are readable by the www
> user. Scripts execute as www, hence they have read access to those
> files.

the same way that suphp
php scripts with flaws, will compromise the users acount instead of www.

>
> Also, the mysql_connect() function requires a plain text password, as do
> many other PHP functions. This is where plaintext passwords will be
> found (I wasn't talking about user account passwords).
>
> >
> > > Safe mode is widely viewed as a hack and causes many PHP scripts to
> > > become non-functional.
> > >
> >
> > widely viewed has a hack? by whom? and most importantly why?
>
> Zeev Suraski (co-creator of PHP) seems to agree that safe mode is
> limited in its security and is not a secure solution for keeping users
> separated from each other.
> http://groups-beta.google.com/group/php.dev/msg/f47b4b7e1d912a8d
> http://groups-beta.google.com/group/php.dev/msg/06e6a8a9fb32454c
> http://groups-beta.google.com/group/mailing.www.php-dev/msg/ac0576a9a902
> 627e
>
> >
> > Safe mode isn't 100% safe, obviously, and it just sets a more
> > restrictive environment for the programmer.
> > It might brake some scripts, yes, since we are reducing the
> > funcionality of php in some ways that we consider might be
> > problematic.
> > The users should take care to make shure their scripts/code
> > does what they want without using funcionality that we are
> > removing. I know that, and I assume totally that possible breakage.
> >
> > OTOH, suphp has escalated priveleges during its execution,
> > and if anything goes wrong in that timespan.. BANG -> "bow
> > before me, for I am root".
> > look at this:
> > http://www.securityfocus.com/archive/1/372673
> > http://www.google.pt/search?q=cache:qT4J5NZLLMkJ:lists.marschi
> > ng.biz/pipermail/suphp/2004-August/000814.html+suphp+exploit&h
> > l=pt-PT&client=firefox
> > http://www.securityfocus.com/bid/11020
> >
> > the setuid bit is widely viewed has a hack and the big
> > security problem in the UNIX architecture.
> > suexec is also a hack, a necessary one, apache guys advise
> > against its use, and say that they cannot warrantie its safe.
> >
> > All suids are a problem because of that, nobody can assure
> > that's bug-free and not exploitable.
> >
> > ALL SUID ARE IN ESSENCE ESCALATION OF PRIVELEGES.
> >
> > A few AIX local root exploit came out these last weeks, in
> > which only setting a environment variable in a given way
> > would give you root. too many things influence the behavior
> > of one aplication. one should run then with the minimum
> > necessary priveleges..
> >
> > thank you for your advice, but I think suphp is a wrong aproach.
>
> I'm not in disagreement with you in the fact that suPHP is also a "hack"
> and a compromise in a suid root script is a horrible situation. But I
> believe by using suPHP (or suExec) you will limit the scope that an
> attacker will have (as long as the suid script is sane). Also, the
> first article you cite is a problem with using suPHP and mod_php at the
> same time, not suPHP alone. I believe suPHP is a much better solution
> than "safe" mode. Many large shared hosting environments use PHP as a
> CGI (LunarPages, DreamHost, etc.). Anyway, I'm just trying to help you
> out, not start a war.
>


--
Miguel Sousa Filipe

--
gentoo-security@gentoo.org mailing list