php-general Digest 24 Sep 2013 22:58:33 -0000 Issue 8376
Topics (messages 322171 through 322175):
Re: Apache
322171 by: Domain nikha.org
322172 by: Domain nikha.org
322173 by: Ashley Sheridan
322174 by: Domain nikha.org
322175 by: Ashley Sheridan
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
Ashley Sheridan am Montag, 23. September 2013 - 21:35:
> No, no, no! That is not a good stand-in for fundamental security
> principles!
>
> This is a better method for ensuring an image is really an image:
>
> <?php
> if(isset($_FILES['file']))
> {
> list($width, $height) = getimagesize($_FILES['file']['tmp_name']);
> if($width && $height)
> {
> $source = imagecreatefromjpeg($_FILES['file']['tmp_name']);
> $dest = imagecreatetruecolor($width, $height);
>
> imagecopyresampled($dest, $source,
> 0, 0, 0, 0,
> $width, $height, $width, $height);
> imagejpeg($dest, basename($_FILES['file']['tmp_name']));
> }
> else
> echo "{$_FILES['file']['name']} is not a jpeg";
> }
> ?>
> <form enctype="multipart/form-data" method="post">
> <input type="file" name="file"/>
> <input type="submit" name="submit" value="submit"/>
> </form>
>
> Obviously it's only rough, and checks only for jpeg images, but
that's
> easy to alter. I've just tested this with a regular jpeg, the same
jpeg
> with PHP code concatenated onto the end (which still appears to be a
> valid image to viewing/editing software) and a pure PHP file with a
.jpg
> extension. In the case of the first 2, a new jpeg is generated with
the
> same image and without the code. The third example just echoes out an
> error.
>
Dear Ashley, nice, but useless for this problem!
First, because users may upload other things than images! PDF's, audio
files, videos etc! And on behalf images: GD you are using handles only
jpeg, gif and png. There are about hunderd other image types on the way,
users can upload! How to detect them, if the extension is missleading?
And even if we succeed: As your script demonstrates very well, malicious
code does not affect the rendering of the image. The hacker says: Hi,
this is a nice picture, play it, and then, please do this--follows his
code, that can be a desaster for the whole system.
Yes, your script seems to purge the image file, simply because GD does
not copy the malware code. But why are you sure about that? You cannot
see that code, OK, but may be it was executed in the plain GD
environement? What you are doing is dangerous, because you force the
execution of things that should be never executed!
"no no no" forget it. After all we cannot exclude that users come in
with malware. But we MUST exclude, it is executed on the web server.
That is the Apache chainsaw massacre as Steward whould say. And probably
it can be avoided by purging the filenames (not the files!).
Nevertheless, the standard configuration of the Apache servers is
basically unacceptable. It must execute user requests and never ever
user files! Period.
Have nice days,
Niklaus
--- End Message ---
--- Begin Message ---
Tamara Temple am Montag, 23. September 2013 - 22:38:
>
> On Sep 23, 2013, at 1:36 PM, Domain nikha.org <m...@nikha.org> wrote:
>
> > Better solutions?
>
> One I have used, and continue to use in Apache environments, is place
uploads only in a place where they cannot be executed by turning off
such options and handlers in that directory. This is *in addition* to
untainting files and names of uploaded files.
Good idea. I will do this right now
Niklaus
--- End Message ---
--- Begin Message ---
"Domain nikha.org" <m...@nikha.org> wrote:
>Ashley Sheridan am Montag, 23. September 2013 - 21:35:
>
>> No, no, no! That is not a good stand-in for fundamental security
>> principles!
>>
>> This is a better method for ensuring an image is really an image:
>>
>> <?php
>> if(isset($_FILES['file']))
>> {
>> list($width, $height) = getimagesize($_FILES['file']['tmp_name']);
>> if($width && $height)
>> {
>> $source = imagecreatefromjpeg($_FILES['file']['tmp_name']);
>> $dest = imagecreatetruecolor($width, $height);
>>
>> imagecopyresampled($dest, $source,
>> 0, 0, 0, 0,
>> $width, $height, $width, $height);
>> imagejpeg($dest, basename($_FILES['file']['tmp_name']));
>> }
>> else
>> echo "{$_FILES['file']['name']} is not a jpeg";
>> }
>> ?>
>> <form enctype="multipart/form-data" method="post">
>> <input type="file" name="file"/>
>> <input type="submit" name="submit" value="submit"/>
>> </form>
>>
>> Obviously it's only rough, and checks only for jpeg images, but
>that's
>> easy to alter. I've just tested this with a regular jpeg, the same
>jpeg
>> with PHP code concatenated onto the end (which still appears to be a
>> valid image to viewing/editing software) and a pure PHP file with a
>.jpg
>> extension. In the case of the first 2, a new jpeg is generated with
>the
>> same image and without the code. The third example just echoes out an
>> error.
>>
>
>Dear Ashley, nice, but useless for this problem!
>
The problem was to do with an image upload, so no, not useless.
>First, because users may upload other things than images! PDF's, audio
>files, videos etc!
In an earlier email I detailed some methods for validating other types, such as
DomDocument for HTML, XML, svg, etc, or fpdf for PDF.
And on behalf images: GD you are using handles only
>jpeg, gif and png. There are about hunderd other image types on the
>way,
At the moment those are the 3 raster formats you can use on the web, so those
are the ones that pose an issue. If you're using anything else, it's not for
web and doesn't need to be in a publicly accessible location.
>users can upload! How to detect them, if the extension is missleading?
The extension comes from the user. Never trust the user, ever.
>
>And even if we succeed: As your script demonstrates very well,
>malicious
>code does not affect the rendering of the image.
My script does effectively strip out malicious code though, even if it can't
easily be seen.
The hacker says: Hi,
>this is a nice picture, play it, and then, please do this--follows his
>code, that can be a desaster for the whole system.
Social engineering is a whole different issue.
>
>Yes, your script seems to purge the image file, simply because GD does
>not copy the malware code. But why are you sure about that? You cannot
>see that code, OK, but may be it was executed in the plain GD
>environement?
GD isn't a PHP parser, and PHP doesn't execute the image before GD touches it.
Infact, Apache isn't even involved between GD and the image at that point, so
it won't suffer from this bad config.
What you are doing is dangerous, because you force the
>execution of things that should be never executed!
Erm, no, the image isn't being executed.
>
>"no no no" forget it. After all we cannot exclude that users come in
>with malware.
If you think it's fine that a user be able to upload malware, then you're going
to have a very bad time.
But we MUST exclude, it is executed on the web server.
This is important too, but in this profession belt and braces is best I
believe.
>That is the Apache chainsaw massacre as Steward whould say. And
>probably
>it can be avoided by purging the filenames (not the files!).
>
>Nevertheless, the standard configuration of the Apache servers is
>basically unacceptable. It must execute user requests and never ever
>user files! Period.
>
>Have nice days,
>Niklaus
>
>--
>PHP General Mailing List (http://www.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php
Thanks,
Ash
--- End Message ---
--- Begin Message ---
Ashley Sheridan am Dienstag, 24. September 2013 - 18:22:
> In an earlier email I detailed some methods for validating other types, such
as DomDocument for HTML, XML, svg, etc, or fpdf for PDF.
>
Fine, gratulations!
> And on behalf images: GD you are using handles only
> >jpeg, gif and png. There are about hunderd other image types on the
> >way,
>
> At the moment those are the 3 raster formats you can use on the web, so those
are the ones that pose an issue. If you're using anything else, it's not for web
and doesn't need to be in a publicly accessible location.
>
Why that???!!! Why should users only upload files, that are used "for web", and
what does this mean, "for web"? Users may store personal files on your host,
because they use your website as a "cloud", as it is said today. Not "for web",
but for personal use on everey computer connected to the internet! That is
absolutly legitime and the ONLY reason to offer file uploading I can imagine! I
allow it only for authenticated, subscribed users.
Nevertheless those trusted users may upload (unintenionally!) infected files.
And again: No virus was ever written "for web", but to harm computersystems,
clients and servers. They are just distributed via web.
Whould be great we could block them, and I appreciate your efforts to do this.
But sorry, your script shows me, that this cannot be done this way! Perhaps, if
you are right and GD processing really is harmless (I'm in doubt), we have a
clean jpeg (or gif or png). And then? What's about the rest?
Keep in mind, that PHP is a scripting framework to create websites, certainly
not a tool for virus detection! And we have a big problem with the Apache web
server, not because Apache serves possibly infected files, but because all kind
of files are NOT served, but passed to the script interpreter! That's awfull
enough, and opens a new exploit!
>
> The hacker says: Hi,
> >this is a nice picture, play it, and then, please do this--follows his
> >code, that can be a desaster for the whole system.
>
> Social engineering is a whole different issue.
>
yes, what I tried to describe is criminal.
Niklaus
--- End Message ---
--- Begin Message ---
"Domain nikha.org" <m...@nikha.org> wrote:
>Ashley Sheridan am Dienstag, 24. September 2013 - 18:22:
>
>> In an earlier email I detailed some methods for validating other
>types, such
>as DomDocument for HTML, XML, svg, etc, or fpdf for PDF.
>>
>Fine, gratulations!
>
>> And on behalf images: GD you are using handles only
>> >jpeg, gif and png. There are about hunderd other image types on the
>> >way,
>>
>> At the moment those are the 3 raster formats you can use on the web,
>so those
>are the ones that pose an issue. If you're using anything else, it's
>not for web
>and doesn't need to be in a publicly accessible location.
>>
>Why that???!!! Why should users only upload files, that are used "for
>web", and
>what does this mean, "for web"? Users may store personal files on your
>host,
>because they use your website as a "cloud", as it is said today. Not
>"for web",
Ok, imagine this scenario. A user uploads a .tif. this isn't a web format, so
we treat it as a binary file, uploading to a non web accessible area of the
site. Tell me again where the exploit is please.
>but for personal use on everey computer connected to the internet! That
>is
>absolutly legitime and the ONLY reason to offer file uploading I can
>imagine! I
>allow it only for authenticated, subscribed users.
>
>Nevertheless those trusted users may upload (unintenionally!) infected
>files.
>And again: No virus was ever written "for web",
Not exactly true, but beyond the scope of this discussion I think
but to harm
>computersystems,
>clients and servers. They are just distributed via web.
>
>Whould be great we could block them, and I appreciate your efforts to
>do this.
>But sorry, your script shows me, that this cannot be done this way!
Tell me how you would get a jpg past that example and I'll look into it, as I
explained that was an example not a full solution. We don't tend to just write
full code for people here.
>Perhaps, if
>you are right and GD processing really is harmless (I'm in doubt),
Evidence? Either give some or stop saying GD isn't secure. The PHP community
needs less hyperbole and more facts.
we
>have a
>clean jpeg (or gif or png). And then? What's about the rest?
>
>Keep in mind, that PHP is a scripting framework to create websites,
>certainly
>not a tool for virus detection! And we have a big problem with the
>Apache web
>server, not because Apache serves possibly infected files, but because
>all kind
>of files are NOT served, but passed to the script interpreter!
that's a bad Apache setup, which I'm not saying isn't a problem, but your
original "solution" doesn't even cover validation.
That's
>awfull
>enough, and opens a new exploit!
>
>>
>> The hacker says: Hi,
>> >this is a nice picture, play it, and then, please do this--follows
>his
>> >code, that can be a desaster for the whole system.
>>
>> Social engineering is a whole different issue.
>>
>yes, what I tried to describe is criminal.
>Niklaus
Thanks,
Ash
--- End Message ---
