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

> A security problem? I think not. You have so amazingly missed the point I almost hope you're kidding about this. While you may be a secure programmer, while you may be aware of the security issues surrounding the code you write in PHP, _99% of all PHP coders aren't_. There will be a series of advisories along the lines of this one, they'll show weakness in several MAJOR PHP applications, coded by people who consider themselves security concious like yourself. I believe it is simply NOT POSSIBLE to code securly in PHP with register globals enabled. > <rant> > > _Almost_ any PHP program which provides file upload capability > > Uh, any program which allows user input *must be checked* for the validity > of that input, and the same goes for returned output based on that input. > > Duh. Its so amazing that you've decided stuff that everyone else should know, they don't, live with it. > somehow. Or even better: Store credit cards in a webservers database, > where a webserver user is allowed to read it based on *any* form of > authentication that can be forged, faked, stolen.... Are you attempting to say something here? Authentication is no simple matter, particularly in PHP, again, I guess you'll see how commonly its stuffed up in some of these advisories. > Security is not something that can be coded in, bought, or sold. It's > something you do, it's a mindset to carry around as you work. If you > code _without_ that mindset, you are creating your own security flaws, > more flaws than the entire PHP community could hope to insulate you > from. You would have to be mental to argue that turning of register globals does not make the PHP environment less conducive to security faults. > by that webserver user. Applying security through obscurity via "hiding" the > files from the webserver user doesn't guarantee that they won't be found. This > is _why_ shadow password files exist, this is _why_ you don't keep sensitive data > (as in, worth thousands of dollars or more) on a server with world wide > access from world wide users. PHP scripts MUST be readable by the webserver, they OFTEN contain DB authentication data, DB authentication data allows a lot more than access to a DB. > you from screwing up. (Kudos to Rasmus for the patch to shunt the files > from being *easily* grabbed by this function, but some of your files > will _always_ be readable by the webserver. Code for it.) If only all coders were like you, perhaps it wouldn't matter. > > In my opinion this is a significant security risk, in fact, > > I'll be posting quite a few security issues based around it in the coming > > weeks). > > Wait, you mean a _variable_ can do _varying things_? > > And poor checking of what's _in_ the variables can make those things break a > server? > > Duh. > > This is not worthy of bugtraq. A PHP script running on thousands of servers is vulnerable to a security issue its not worthy of bugtraq? > A "hole" where it's discovered that Webmin and Linuxconf can access /etc/passwd? > > A "hole" where not checking on the kind of file that you're expecting means > that the wrong kind of file goes through? (Oh, wait... heh.) > </rant> > > Code safely, folks. Check the validity of everything you pass from a secure space > into your web space, and vide versa. PHP is _much_ more powerful than ASP, Javascript, > or other languages which insulate you from doing powerful things (like building > a UI to edit /etc/password as root). > > Treat it with the respect that a server-modifying language deserves,, and you'll > be fine. If only that were the case. And for those admins that aren't cluefull enough to audit the code themselves should they just not use any PHP because some people screw it up? Honestly, move into the real world, you are not the typical example, you are unlikely ever to be. For those admins running prewritten code, they have every right to be scared.