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

A security problem? I think not. <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. Here: a "potentially dangerous" piece of PHP code: mail("$user_submitted_email", "$user_subject", "$mail_body"); Combine it with "president@whitehouse.gov" "Hi" and a bomb threat, and oh lookie, you have a "potential security issue". Here's another one: Allow somebody to delete files on the server drive based on a hidden form variable, a cookie, _WHATEVER_, and don't check that variable 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.... 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. > The way that PHP handles file uploads makes it simple to trick PHP > applications into working on arbitrary files local to the server rather than > files uploaded by the user. This will generally lead to a remote attacker > being able to read any file on the server that can be read by the user the > web server is running as, typically 'nobody'. Hello, welcome to user level security. If you don't want a webserver user to read a file, that file must be unreadable 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. Repeat after me: A PUBLIC WEBSERVER IS ALREADY 0WN3D BY THE NET. That's also why you don't rely on public webservers for high security situations. Yes, I've worked in banking at times, so I have a pretty good idea about how this works on a billion-dollars-per-hour level. If you must make a compromise, you do it *intelligently*, you don't just toss up code and hope you'll have "security" without doing your own severe validity checking. As in, you only allow access to certain files by certain users, you control all user access on the lowest *tolerable* level, you don't store anything sensitive on disk (you encrypt it heavily and tunnel it out to a more secure server which has no 'net access.). And you sure as hell don't allow your webserver user access to anything important, regardless of how hard your webserver software tries to keep 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.) > 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. Heck, the underlying issue has been bludgeoned to death in the PHP manual notes for a *while* now. Webserver users can read anything the webserver user has access to. No amount of patching is able to change this, or, indeed, should change it (PHP would run poorly if it couldn't read the files you've coded) http://www.php.net/manual/security.php http://www.php.net/manual/security.apache.php > [Fix] > Unfortunately, I believe this style of problem to be impossible to fix with > the default behaviour/configuration of PHP, I'll be demonstrating this with > several adviories in the next few weeks. I have a better idea. Why don't you turn off user input, entirely. This will keep the users from doing bad things, which, apparently, is a *new idea*. Sheesh. This is like complaining that Buffer Overflows are the fault of Richie, because C allowed it.... I've been insulated from this for a while now, by virtue of sane coding. The files which are passed through my upload code are _always_ checked for proper type, syntax, length, and structure, and nothing is ever destroyed by the public webuser without at least username and password checks (if they're already a valid server *user*, duh, they already have access to things like /etc/password). What next, a "security hole" where a PHP hosting site has allowed their users access to /etc/passwd, and users can run fread()? A "hole" where somebody who made their credit cards readable to a public webserver program discovers that (gasp!) anybody can read them? A "hole" in every other webserver program, cgi, whatever, where it's discovered that allowing unlimited file sizes can crash a server? 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. -Boppers -- Brought to you from iBop the iMac, a MacOS, Win95, Win98, LinuxPPC machine, which is currently in MacOS land. Your bopping may vary.