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

Stanislav Malyshev wrote: > 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. Ooh. Brilliant example. (no sarcasm intended). Yes, if you were coding for such a server, you'd definitely want to check these upload names as coming from the proper variable, set as you wanted. Use basename() to make sure it's a file, with no path. (Go Lars, Go!) > 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. It's a "weakest link" issue. Since there are weak links in every mechanism, using two chains insulates you from one chain (in this case, PHP) having a weakness. If there was a filesystem security issue next month, and your PHP code _only_ relied on the filesystem security, yes, that would be bad, too. > 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. ? Does not translate to my local idioms well. > I talk about web > applications. Believe me, you gotta have a bunch of users. Believe me, you > don't expose them. I have a bunch of users. :-) Yes, part of the task is using the language to insulate them, and yourself, from both incompetance and downright assault. PHP can be a very powerful language, and you can shoot yourself in the foot with it. > 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. > 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. This depends on the user base, obviously. If users wished to have the best security available, they would not keep their files on a web server. To insist that a public server can ever be as secure as a private one is inaccuarate. I have users who wish to access their accounts from any machine in the world. They are aware that this means that any machine in the world has the potential of accessing their files, if there are security problems. To deny this threat is sticking one's head in the sand, as well. :-) > RC>> Putting passwords in user scripts is *creating additional risk*. > RC>> Period. > Yes. And you still got to protect those dumbass users or find you a job as > a truck driver. Life sucks. Yes. I wasn't saying that there shouldn't be attempts made at protection, but users need to be aware that there is no such thing as 100% secure. They should try to make sure all attempts at security are made, by themselves, by PHP, etc. > 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? Yes, but any poorly written PHP app can do this. PHP has access to this file. This means that PHP coders must keep the security of their server in mind at _all_ times. To proclaim that PHP can read /etc/password based on user input is nothing new or different. Take a look at the following code: <?php //readfile.php fopen ("$user_supplied_variable", "r"); ?> If a user supplies "/etc/passwd", then /etc/passwd can be opened, if the PHP programmer allows their PHP code access to the file. This is a *feature*, not a bug. It's well known that the user's client (IE, NN, whatever) supplies variables when uploading. That means that these are user-supplied variables, and should be checked carefully. > 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. Yes. Using user supplied variables *never* provides security. The file upload will always use user supplied variables, in some way. PHP merely passes these variables. > 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 Please re-read: > RC>> We should be doing _both_. > because since 100% security is > impossible we should dump any attempts to provide user with help on this, And Again: > RC>> We should be doing _both_. > 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. Yes. This was a new "unknown". > 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? I noted "on the file level". This helps to remind people to use TWO chains. > 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. Right. One they are "in", using a valid account, on a valid login, you _must_ have adequate security in the form of validating the binaries, auditing your passwd account, etc. Two chains. :-) > So you say any server > connected to the internet makes all the files public? In a way, yes. There is much, much, much higher risk. > That's a goos stance > when you in the defence stand in the court, but otherwise useless. I say a server connected to the internet is less secure than a private one. One connected to the internet is at *much* higher risk, and should never be treated as if the files on it are entirely private. Im willing to testify to this in court, as will *any other security concious admin*. -Bop -- Brought to you from boop!, the dual boot Linux/Win95 Compaq Presario 1625 laptop, currently running RedHat 6.1. Your bopping may vary.