Re: Re: [Fwd: (SRADV00001) Arbitrary file disclosure through PHP file upload]

RC>> Uh, any program which allows user input *must be checked* for the validity RC>> of that input, and the same goes for returned output based on that input. True. But! PHP gives you no good means to check if that variable $uploaded_file is from valid user upload or not. *That's* the problem. The only way now to check if the filename is prefixed by your temp upload directory, which means you should remember that, update it on all your scripts every time it changes and generally requires a lot of PITA work. RC>> Repeat after me: RC>> A PUBLIC WEBSERVER IS ALREADY 0WN3D BY THE NET. Wrong. I won't go into detailed explanation, but note that "every file readable by httpd user is publicly accessible to the web" is just wrong. Think about it, if you still disagree, I can explain it to you privately. RC>> And you sure as hell don't allow your webserver user access to RC>> anything important, regardless of how hard your webserver /etc/passwd is important to you? How about list of local network hosts? How about your webserver configs? How about your webserver-protected files (like, private user directories)? How about various passwords in user scripts? I remember the (righteuos) wave of rage against Microsoft when it was discovered that you can steal any ASP file source. Now you telling me it's small change? RC>> This is not worthy of bugtraq. Yes it is. We have real problem here, and we need to think what to do with it - or telling "PHP is not secure here, you need to go additional mile for it" or doing changes. Just putting your head in the sand while incantating "variables mucst be checked" won't do you any good. Security problems is not where you get on defensive, is where you work to fix them. RC>> Heck, the underlying issue has been bludgeoned to death in the RC>> PHP manual notes for a *while* now. Webserver users can read RC>> anything the webserver user has access to. No amount of patching That's not going about PHP script is able to read something. It's going about script user is able to trick script into reading something that it shouldn't, and PHP developer having no way of preventing this (at least using procedures recommended by PHP manual), and PHP manual procedures having no way to prevent it short of going into long and painful way of path checking every time. RC>> This is like complaining that Buffer Overflows are the fault of RC>> Richie, because C allowed it.... Buffer overflows is a fault of C giving memory management to user hands. Try to buffer-overflow Perl or PHP? RC>> I've been insulated from this for a while now, by virtue of sane RC>> coding. The files which are passed through my upload code are RC>> _always_ checked for proper type, syntax, length, and structure, RC>> and nothing is ever destroyed by the public webuser without at RC>> least username and password checks (if they're already a valid RC>> server *user*, duh, they already have access to things like RC>> /etc/password). Wrong again. zend.com has some 30K users, noone of them has access to /etc/password and noone ever will (at least if I won't do something stupid, that is :). RC>> What next, a "security hole" where a PHP hosting site has RC>> allowed their users access to /etc/passwd, and users can run RC>> fread()? This hole allows _script user_, not PHP developer, to get any file. Please read bug report before going into flames. -- Stanislav Malyshev stas@zend.com http://www.zend.com/ +972-3-6139665 ext.106