On Mon, 2002-05-13 at 03:13, Zeev Suraski wrote: > Jason, > > He has a point in the sense that it's trivially easy to starve a PHP based > web server from within, safe mode enabled or not. What you describe as the > automated way in which the web server will overcome this attack is not > realistic - pretty quickly, the web server would hit the maximum number of > children allowed, or (if improperly configured) run out of memory.
Right, if we are talking a brute force and it is large enough, that could occur. However, you don't need php to brute force a webserver. I was arguing that the risk is a lot lower than ilia was making it out to be. > Fact is, safe mode doesn't even attempt to guard against this. Not that I > think it can be guarded against, even if we were trying to do it. And a > direct derived fact is that PHP is not safe to allow untrusted users to run > code. It has absolutely nothing to do with PHP, end everything to do with a shared hosting environment. > I personally don't think that this was the idea behind safe mode - the idea > behind safe mode was to guard against information leaking in between users, > not against some renegade user that wants to bring the web server > down. And, I've been advocating the removal of safe mode for years, > because even at that, it does a pretty bad job. Not because it's poorly > implemented, but because it's protection in the wrong level, that by > definition, is bound to fail. And, I think we all agree that a false sense > of security is worse than no security at all. I do not think that safe mode is the end all be all of protection mechanisms. I do think the security it provides can be pretty useful, and when added with other mechanisms, can greatly limit vulnerabilities. I for instance have used safe mode + open basedir + in house chroot customizations. All of these combined provide pretty good protection, and I would not be comfortable with any one of them being removed, unless an alternative can be found. Just to be clear, I am not saying that safe mode is the way to go. I do not like it when someone argues to remove something just because it has a few bugs. Ilia never provided any better or alternative solutions, just attacked exaggeratively what is currently available. > Ilya illustrated what I was saying a while ago, about the inherent (woo, > this word again! :) vulnerability of safe mode, by design. When I said it, > I didn't invest any resources into proving that this inherent vulnerability > is actually exploitable, he did. I really don't see how he proved anything, besides a few bugs in safe mode > I believe that encouraging people to use > CGI (and fast CGI as a performance solution) is probably the only way to > go. And I agree with Stig that PHP 5.0 would be the right point in time to > do that. I noticed that FastCGI supports suexec wrapping, which could work very well if you modify suexec to suid, and chroot. There would then be a php interpreter running as the user, locked in a sandbox, with no shutdown, startup penalty -Jason > Zeev > > At 08:54 13/05/2002, Jason Greene wrote: > >On Mon, 2002-05-13 at 00:41, Ilia A. wrote: > > > > disable_functions = sleep > > > > > > Ah but you forgot usleep, and flock() and socket_set_limit etc... > > > Soon enough you'll disable every function. > > > >Not likely, and I wouldn't disable every single function. You complained > >about the ability, I provided you with the way that YOU can disable it. > >You have to ask yourself why your user would need to be able to call > >sleep > > > > > And when you do, I'll still be able to deadlock a PHP process by making it > > > excute a query on a locked SQL table, thus end up waiting forever for the > > > lock to be > >e>leased. So, you'll need to disable all database functions from > > > your PHP. > > > > > > >Now you are really starting to stretch it. I am sure the ratio of > >customers that have db backends are much smaller than general webhosting > >customers > > > >In all of these scenarios, the webserver itself would just spawn another > >process, and the os would page the other one because it is not in use, > >and then eventually the webserver would log the problem. > > > >If you factor that in with a shared environment with multiple webservers > >and a load balance, your risk is pretty low. Even if someone did do > >something like that to kill all of your webservers, you would easily be > >able to find out who did it, and fix the abuser. > > > > > > > > > > > > The argument you make to remove safe mode because it is not > > perfect > > > > > > > > is unfounded. By the same argument you could say we shouldn't use > > > > > > > > locks on our doors, because hey "they can be picked". > > > > > > > > > > > > > > Safe mode is not only imperfect it does not even work properly. In > > > > > > > the last day and a half I've showed 5 bugs that allow it be > > bypassed, > > > > > > > simply take a look at the latest safe_mode bugs. > > > > > > > > > > > > Five, I only saw one. Regardless they can and should be fixed. > > > > > > > > > > Check again: > > > > > > > > > > Bug report #17168-69 > > > > > Bug report #17155-57 > > > > > > > > All of those regarding safe mode are fixed now. > > > > > > Really, you don't say... bug reports #17168-69 are still open at the > > time of > > > this message being written. And when they are closed, don't worry I'll > > have a > > > few more posted tommorow for your enjoyment... > > > > > > > It depends on why the lock is broken, you have been suggesting this > > > > whole time that safe mode is a DESIGN flaw. However, your reasoning is > > > > only BUILD flaws. I have yet to hear a single reason as to why the > > > > concept of extra uid, checks of files is a bad thing. > > > > > > It is not PHPs job as a scripting/programming language to do security. > > > security should/must be done at the OS and web server level. Checking > > uid is > > > STUPID, the simplest example, is that if you upload a php script and it > > > creates a file you can no longer read or write to that file even though > > you > > > have file permissions to do so. > > > File system permissions exist for a reason, use them. > > > >how are you planning on protecting your passwd file then? > > > > > If you have sensetive data, like credit card information and you are > > not using > > > a dedicated server to store that data then do be surprised to find your > > data > > > in someone elses hands. In a shared enviroment especially where > > > programming/scripting languages are avaliable it is merely a matter of > > time > > > before someone takes advantage of some security hole/oversight and > > grabs the > > > hold of your data. > > > > > >So then you are agreeing : ) > > > > > > There are problems here and you can be a bit more constructive, and send > > > > patches, offer new security techniques, report bugs. Exaggerating and > > > > cursing safe mode does nothing but waste time. > > > > > > > I am clearly demonstrating the problem and if you actually payed attention > > > instead of trying to pretend this problem did not exist, > > > >I am not, I am merely disagreeing that safe mode should be removed. I > >mean god man, if you hate safe mode so much turn it off. There are > >options you know, but just because you don't like it does not mean that > >everyone should not be able to use it. > > > > reporting bugs about > > > it. I'd gladly offer a patch that will get rid off safe_mode for the > > core php > > > tree if developers are willing to add it to the CVS :) > > > >Or you could try something more useful, like fixing a bug in safe mode, > >adding a new security feature, etc. etc. However, I suppose it is too > >difficult to come up with a constructive solution. > > > Safe mode wasteful and pointless this is no exageratio,n it makes > > development > > > in the "safe" enviroment pointlessly difficult and offers no real safety. > > > > > > Ilia > >Hmm, but you just said that a shared webhosting enviroment, by nature, > >has no real safety. > > > >Pointlesly difficult..... > >then safe mode must be doing something.... > > > > > > > > > > > >-- > >PHP Development Mailing List <http://www.php.net/> > >To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
