Everything

php

upload compromises

php.internals

skate

26 years ago

i know i probably shouldn't be posting this in here, but i'm not sure where else to do so. so please forgive me if this is the wrong place.

basically in PHP 5 is there going to be a php.ini directive to control uploads? so for instance an ISP can restrict uploading of certain files, or only allow others. This would obviously help greatly in protecting against upload compromises, and also against any other kind of upload attacks (DoS). I'm also wondering if there's a way to get uploading executables turned off on a default install. it seems that there is a lot of new users, or just users wanting to get started quickly that over look the upload issues. I see it quite a lot in both the PHP lists, and the security focus lists.

PHP has recently gotten a bad name for itself with this type of compromise and it's an all too common problem that despite the warnings, still crops up regularly. making a change like this could help to not only improve security, but also the bad publicity that PHP has recieved over this.

anyway, my 2 cents, sorry again if this is in the wrong place...

-skate-

Rasmus Lerdorf

23 years ago

There is a directive to turn off uploads altogether.  I don't see us going
beyond that.  How are we supposed to detect executables?  An executable is
extremely platform-dependant.  I suppose we could suck all the code from
the UNIX 'file' command into PHP and try to determine a filetype from the
magic byytes, but to what end?  What exactly are you trying to protect
against here?

The uploaded file is not going to get the execute bit set unless you
explicitly set it when you copy the file to its destination location in
your script.  The only way to upload a file and then execute it is to know
a little bit about the web server and upload specific file types the web
server is configured to execute.  For example, uploading a .php file to a
script that is dumb enough to copy this file to somewhere under the
document_root would result in the ability to upload arbitrary php code on
that server.  Or if the server is configured to parse PHP out of all .html
files, then simply uploading a .html file would do the same.

On the other hand, uploading a Windows .EXE to my server isn't going to do
a damn thing no matter how stupidly I treat it on my end.  Likewise if you
upload a FreeBSD binary, that isn't dangerous on my server.  But uploading
a .html or a .pl could potentially be.

My point is that we have no way of knowing what is dangerous and what
isn't.  This is something the application developer will have to determine
in his receiving script.

-Rasmus

On Mon, 31 Jul 2000, skate wrote:

skate

23 years ago

> There is a directive to turn off uploads altogether.  I don't see us going
> beyond that.  How are we supposed to detect executables?  An executable is
> extremely platform-dependant.  I suppose we could suck all the code from
> the UNIX 'file' command into PHP and try to determine a filetype from the
> magic byytes, but to what end?  What exactly are you trying to protect
> against here?

well, i was more thinking of, by default, only allowing say images,
documents and compressed files.

i can fully understand that determining an executable is a mean task, and
way out of the scope for what PHP needs to be. but PHP already has the in
built functionality to check a file type, same way as i would check a file
when i have an upload script.

> My point is that we have no way of knowing what is dangerous and what
> isn't.  This is something the application developer will have to determine
> in his receiving script.

i just think that if there's a default setting, it'll cure a lot of the
problems we get with un-educated users created wild upload scripts. most
things can be dangerous in one form or another, but would taking a few steps
like this really be more effort than it's worth?

i know it's a bit of kindergarten teaching for people that really should
know better, but it's evident just from the lists that it happens quite
often.

thanks for the response anyhow :)

Hartmut Holzgraefe

23 years ago

skate wrote:

> well, i was more thinking of, by default, only allowing say images,
> documents and compressed files.
> [...]
> i can fully understand that determining an executable is a mean task, and
> way out of the scope for what PHP needs to be.

there are more image and document formats around than there are
executable file formats i guess ...

> but PHP already has the in
> built functionality to check a file type, same way as i would check a file
> when i have an upload script.

it is not really builtin, at least not enabled by default, and last time i
looked at it was even labled EXPERIMENTAL AFAIR (and i have to know ;)

> i just think that if there's a default setting, it'll cure a lot of the
> problems we get with un-educated users created wild upload scripts. most
> things can be dangerous in one form or another, but would taking a few steps
> like this really be more effort than it's worth?

i see your point, but checking the file type is only half of it as e.g.
M$Word documents may contain VBA macro viruses. so to really make sure
that no unwanted stuff gets uploaded you also need to apply virus checking
and stuff like that ...

--
Hartmut Holzgraefe  <hartmut@php.net>

Rasmus Lerdorf

23 years ago

On Thu, 31 Jul 2003, skate wrote:

> > There is a directive to turn off uploads altogether.  I don't see us going
> > beyond that.  How are we supposed to detect executables?  An executable is
> > extremely platform-dependant.  I suppose we could suck all the code from
> > the UNIX 'file' command into PHP and try to determine a filetype from the
> > magic byytes, but to what end?  What exactly are you trying to protect
> > against here?
>
> well, i was more thinking of, by default, only allowing say images,
> documents and compressed files.

What is a document?  Like I said, if the server is configured to parse PHP
tags out of .html files, which is rather common, then even uploading a
.html file is unsafe.  A straight .txt file could potentially be unsafe
while an executable is completely safe because there is unlikely to be a
server configuration that would enable this executable to actually be
executed.

Are you worried about client-side security when you talk about blocking
executables from being uploaded?  As in uploading an executable that is
then later downloaded by someone else and run?  Because surely, uploading
an executable is unlikely to be a problem on the server.

We could put in a mime-type filter, but that would act on the
client-provided mime-type which is rather unreliable.  Perhaps couple that
with mime-magic checking and I guess it could be useful as an optional ini
directive.

-Rasmus

skate

23 years ago

sorry, unfortunatly i haven't got a full solution, just a suggestion. i
don't know how difficult any of this would be to implement, but i feel that
it could benefit the community by adding a little extra security.

i do fully understand that it's not gonna be 100% fool proof, or security
proof. very little is when you have any kind of user input. but every little
bit does help.

thanks for entertaining the idea with me tho :)

Ilia A.

23 years ago

On July 31, 2003 12:41 pm, skate wrote:

> sorry, unfortunatly i haven't got a full solution, just a suggestion. i
> don't know how difficult any of this would be to implement, but i feel that
> it could benefit the community by adding a little extra security.
>
> i do fully understand that it's not gonna be 100% fool proof, or security
> proof. very little is when you have any kind of user input. but every
> little bit does help.

It would not offer any real security. Mime detection is generally based on the
1st few bytes of the file and can be easily fooled. This imperfect system
will result of numerous frivolous reports about certain files bypassing this
'security measure' and so on. If you want such a protection enable the
mime-magic extension or better yet get a command line virus scanner and use
that to filter your attachments.

Ilia

Hartmut Holzgraefe

23 years ago

Rasmus Lerdorf wrote:

> I suppose we could suck all the code from the UNIX 'file' command into PHP

we already have ;)

someone at HP already did that for apache and i wrapped it up in ext/mime_magic

> The only way to upload a file and then execute it is to know
> a little bit about the web server and upload specific file types the web
> server is configured to execute.

maybe the request was also about client security?
(just guessing, hard to tell with no links to the mentioned
"bad publicity" in the original message ...)

like maybe windows EXE files getting uploaded to galeries?

sure, the application storing and providing the uploaded files *should*
check that stuff itself, but most probably wont ... :(

what about some mechanism similar to your input filtering stuff that
operates on uploads so that it becomes possible to enforce sitewide
upload policies even in shared hosting environments using some sort
of hooks?

PS to "skate" <root@fatcuban.com>:
funny that you are worried about php file uploads but not
about using the root account for communication ;)

--
Hartmut Holzgraefe  <hartmut@php.net>

Evan Nemerson

23 years ago

[PHP] Possible My Website was hacked... with PHP... please tell me what this
is???
http://marc.theaimsgroup.com/?t=105963160300003&r=1&w=2


P.S. to Hartmut Holzgraefe <hartmut@php.net>:
even funnier that he's using a root account for communication through
Microsoft Outlook Express 6.00.2720.3000, and is worried about php file
uploads



On Thursday 31 July 2003 08:20 am, Hartmut Holzgraefe wrote:

Phil Driscoll

23 years ago

If ISPs want to prevent stupid scripts copying uploaded files under
document_root they can set ownership and permissions on document_root so that
the web server doesn't have permission to write files there. That should fix
all problems associated with uploading php, perl and other such files which
might be otherwise executed by the web server.

--
Phil Driscoll