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

RC>> I agree that it's inconvenient to code all of your uploads for checking RC>> the actual data (rather than assuming a good file based on name), but RC>> if coding is done with some decent forethought of possible attacks (and RC>> just plain incompetance), it's not much of an issue compared to rebuilding RC>> a compromised server. In general case, you _can not_ check the data. You just don't know what it is. Easiest example: webmail with attach capability. Now go check those files. RC>> This is more about mindset than it is about today's current software RC>> practices. On a web-server level, sure, you can "request" files to not be RC>> readable, but on Unix systems, all security is file-level, _regardless_ RC>> of the application running on top of it. If a file is readable by "o" RC>> users, that file is readable by _anybody_. The applications which act as No. There are hierachical security structure, which allows additional protections over Unix filesystem mechanism. Basically, Unix filesystem mechanism sucks too badly to cover all needs. As would every other mechanism that can be put into the kernel. RC>> Not on a server designed for public use. Everything you could RC>> find in there is already well known (a few standard system users). Well, I don't talk about "my dog on the walk" webserver. I talk about web applications. Believe me, you gotta have a bunch of users. Believe me, you don't expose them. RC>> Private users? On a public server? Er.... there's no privacy in public, RC>> for a reason. The application-level security overlay is not a fool-proof RC>> means of protecting files. (Locks keep honest people honest, so hide RC>> the entire house, lock it up, and don't use a public street address...) Well, sounds nice. The only problem it has no touch to the Real Life (TM) as we know it. In Real Life (TM), you *got* to have private directories on public server, and *got* to protect them, or you users will fry you. They don't care for your theoretical reasoning, they just go to competitor otheriwse. RC>> Putting passwords in user scripts is *creating additional risk*. RC>> RC>> Period. Yes. And you still got to protect those dumbass users or find you a job as a truck driver. Life sucks. RC>> We should be doing _both_. Spreading FUD isn't helping (well, maybe it's RC>> helping folks to realize that you can't *buy* a secure, hackproof, server, It wasn't a FUD. You _can_ get an /etc/passwd with this hole. That's what the man said, no? OK, he was a little harsh on recommended means, and a little broad on effect - but essentially has was true, PHP file upload doesn't provide security. As I already said, we can or say: "PHP is out of service here, do it yourself" or make PHP to provide this service. You claim that we should do the first because since 100% security is impossible we should dump any attempts to provide user with help on this, since it won't help in 100% of cases anyway. I say that heloing at least in known cases is good enough, and with unknown one we'll deal when we get them. RC>> Script users, on the file level, have access to everything that RC>> httpd does, as that is the user they access the machine with. RC>> httpd has access to /etc/passwd. Whether coder or user, that RC>> file is available to them. Oh. Are you really not understanging there are additional level of protection except Unix filesystem levels or you are just kidding me? What makes that level sacred so you dump all others in front of it? After all, it is based on same password-protection as Apache-level, and in both cases one password can be sufficient to defy it. So you say any server connected to the internet makes all the files public? That's a goos stance when you in the defence stand in the court, but otherwise useless. -- Stanislav Malyshev stas@zend.com http://www.zend.com/ +972-3-6139665 ext.106