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

At 12:42 07-09-00, Jon Ribbens wrote:

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*.

Large parts of PHP are not documented. There are plenty of 'documentation bugs' such as this, and it'll probably remain that way too. Documentation is a lengthy, never-ending process. We're doing pretty well, in comparison to other opensource projects (as well as many commercial packages). Again, in this particular case (unlike security issues), the fact that millions of sites use PHP and not a single person ever complained about it means something. Perhaps it's not a big an issue as you make it. Again, before you say "you mentioned it first" again, I mentioned it in a very specific context - security (and performance).

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?

If they contain binary data, which generally never happens unless you're dealing with files. We'll get around to making this whole infrastructure binary safe sometime, but that would mostly be for performance reasons.

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.

I said I was wrong numerous times before (when I said my patch didn't solve the security issue), I'm not sure why you only figured it out now. I have no problem to admit when I'm wrong. I didn't particularly care for your way of saying things (especially when, like I said, you didn't reveal anything new to me, as you may have thought you did), and I still don't (it's interesting to know how old you are).

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.

The balance clearly leans towards removing it - i.e., the pain would weight much, much more. It would break just about any script in existence. Mind you, the security implication of having register_globals on is not nearly as high as you think it is. It's there, though, if you combine it with bad coding practices.

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.

That's what I intended to do.

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.

Whatever. Adding constructs is totally unnecessary for this purpose. Zeev -- Zeev Suraski <zeev@zend.com> http://www.zend.com/