Re: PHP File Upload Security Hole - Still No Fix?

Zeev Suraski <zeev@zend.com> wrote: > In the particular place you pointed out, the lack of binary safety: > a. Probably has no implications at all. It looked to me like it meant that you can't pass binary data via CGI variables. If that's the case, then it *does* have implications, and *is* a bug *if and only if it is not documented*. > Correct me if I'm wrong, but my assumption is that you grep'd for FIXME, > rather than read the code. Reading through code doesn't sound like > something you would do. I wasn't looking for bugs, I was trying to work out how things worked. At the time, I was completely mystified as to why your patch only altered rfc1867.c and I was looking at how the whole POST-parsing thing worked. > Huh? Why? It's a low level implementation thing, something that's closed > in the level of source-level comments. Is it? I may be wrong about it affecting CGI variables, which are quite obviously a world-visible issue. Am I? > Because at the time I was wrong Phew! Finally. It appears I have to say the same thing umpteen times before anyone admits that it was right the first time. > Undoubtfully, this would cause many people a great deal of pain and lost > hours of work. You have to balance it against the potential pain and lost hours caused by register_globals still being there, people still using it in ignorance, and getting hurt by it. You may decide that the best way to fix it is to leave it on by default, but to put a very prominent notice telling people to turn it off if they can. I don't think that that is the best way to go, but if you think it is then I'm not going to argue with you about it. > What, start cluttering the language syntax with new constructs? Of course > I ignored that. Why the hell would we want to do that? Not new contructs - new construct, singular. In a particularly fundamental area. I don't particularly care about this issue, it was just a passing comment. If you don't like it, fine. Cheers Jon