On Sun, August 26, 2007 2:31 pm, Mark Krenz wrote:
> First of all I don't want this to sound like a personal attack, its
> professional. I just encountered something that really aggrevates me
> about the state of PHP and I want to be heard by the developers.
First make sure you understand what safe_mode does, and doesn't do,
and just how lame it is at what it tried to do, and fails to do, and
simply cannot do.
Next, understand that it generates a zillion support problems for you,
webhosts, PHP-General, and Internals/Bugs/QA, from people who see
"safe_mode" and say "Oooooh! I want that. It's safe!" -- who are
100% wrong, because they haven't a clue what it actually does and how
it works, and then they complain when it does exactly what it was
designed to do.
Any developer in any Apache Module can open up giant gaping holes,
and, obviously, many of them do, even in popular PHP web apps. I
daresay particularly in popular PHP web apps, since PHP is so dead
easy to get started with and write something nominally useful in a
matter of hours of study rather than months.
I sincerely doubt that safe_mode has "saved" anything at all for you
in a long, long, long time however.
Perhaps there are several courses of action you could consider long-term:
1) Expand your use of suphp as much as practical
2) Ban webapps you know to be fundamentally insecure; those with a
long history of serious vulnerabilities
3) Actively seek out and push users to upgrade webapps with known
vulnerabilities. (It shouldn't be that hard to write a grep/find that
seeks out PhooBah 1.0.0 in any file named 'badforum/config.inc' and
run that in a cron every day for yourself)
> works. But I can't just turn that on for every user on my system
> because things like Mediawiki simple URLs don't work right and
> possibly
> other things won't work.
[flummoxed topic="off"]
How does MediaWiki manage to screw up simple URLs pages on suphp?...
[/flummoxed]
> Some developers will not take responsibility
> for their programs not working and I'm getting tired of telling my
> customers that there are brain dead developers out there writing
> popular
> software.
I understand and sympathise with you.
Perhaps a published list of "banned software" that you can direct
users to would be a useful addition to your control panel or FAQ or
even your terms of service agreement.
If you tell your prospective users up-front that PhooBah 1.0.0 is
BANNED due to serious security vulnerabilities, some, not all, but
some, of your woes go away.
> The PHP developers trying to shun the problems off to being an Apache
> problem or OS problem is irresponsible. If PHP is a module running in
> Apache. What can Apache do? Maybe I'm missing something here.
Apache could provide the sudo on a VirtualHost or even Directory
basis, for example...
At least, that's what *I* would imagine could be done.
> open_basedir is vulnerable to the work around and safe_mode is
> vulnerable to other problems that I've notified the developers about.
> But removing safe_mode will only make things more unsecure not less.
I seriously doubt that removing safe_mode will actually make anything
"less secure" for your server.
It is a false security blanket doing little of any real-world use.
> I
> know its a pain in the ass for people, but I think that until the PHP
> developers can come up with a 100% secure way to run PHP, they
> shouldn't
> be removing functionality like this.
I'm sure that when you re-read the above paragraph, you'll realize
just how silly it is... I'll stop here. :-) :-) :-)
> Otherwise I'm going to have to
> stay away from PHP 6. My security model for websites on Suso is
> partially based around safe_mode and other things like suexec and
> enforcing restrictive permissions on user's homedirectories and so on.
> But take safe mode away and users will be able to execute programs
> that
> can read other user's files. As simple as writing a program like
> this:
>
> $arg = "/home/otheruser/www/filewithdbpassword.inc";
>
> $output = "";
> exec("/bin/cat $arg", $output);
>
> print $output[0];
Yeah, but with safe_mode on, all I have to do is create a symlink and
if Apache is set up to follow symlinks, I can read that anyway. I've
done that just to recover my own db password rather than bothering my
webhost support staff with a request and waiting << 24 hours. (They
usually answer something that simple in < 1 hour, actually...)
PS I did it behind an .htaccess file and nuked it as soon as I had the
password, of course. I'm not a TOTAL idiot... :-)
For that matter, on every shared host I've ever used, guessing
somebody else's db password and cracking it with a brute-force attack
based on *my* database password seems like it would be pretty trivial.
I've had hosts where it was always db#########, so I had to do, what,
1 million db connections until I got it right? Spread that million db
connections out over a few weeks and call it done, no?
Another host was clearly taking 2 short words (short = one or two
syllables) from the dictionary, whose leading letters matched
something in the domain name or username. And, actually, they were
generally using something kind of funny/punny based in the names, it
seemed, though perhaps that was my twisted take on a too-small sample.
Still, how many words start with any given letter in /etc/shared/web2
or whatever it is? Well within the grasp of a week's worth on
indetectable cracking, I would imagine.
I've never TRIED this
> So what is the plan for increasing the security of PHP rather than
> decreasing it? I've been waiting since Apache 2.0 (7 years now) for
> PHP
> to take advantage of things Apache 2.0 offers in terms of being able
> to
> let modules run as the user, but I've seen nothing in this regard.
I would hope that PHP would have nothing in the way of that working as
designed by Apache 2.x It would be up to you to configure in
httpd.conf, as I understand it, no?
I'm not 100% clear on how Apache 2.0 does this, or even what Apache
2.0 offers in this regard, though, so perhaps I'm missing the boat on
this one.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
