Apache

[Domain nikha.org]

Hi Arno!
Seems to be the standard behaviour of Apache servers all over the
world!

I was testing this way:

First I renamed a real, proper GIF-file to "this.php.nice.gif", put it
in the root of my websites and called it with the browser. Result:
"Error 500 Internal Server Error". The logfile tells: "Premature end of
script headers: this.php.nice.gif".

Then I did infect the same GIF-file with some PHP-Code (<?php echo
"Hello, I'm evel"; ?>), renamed it to "this.php.evel.gif", put it in the
root, called it with the browser. The result was exactly the same: Error
500, Premature end of script headers.

That means, wether the file is infected or not, it IS passed to the PHP
interpreter only because it contains somewehere ".php" in his name!

Then I renamed a real PHP script to "test.php.gif". This finaly produced
the following response from my web hoster:

_QUOTE_
Files with Extra ".php." Extension
If you were directed to this page, you probably tried viewing a file
that contains .php. in its name, such as image.php.jpeg or image.php.
(note the extra dot at the end).
The site you were visiting uses the Apache Web server, which will
usually attempt to run such files as PHP scripts (instead of allowing
your browser to display them as images, or completely failing to run
them, as you'd probably expect).
Allowing those files to run as a PHP script is a security vulnerability,
as seen in exploits for WordPress and Joomla. Because of that, we block
requests to these files.
If you’re the owner of this site and you want to use a real image that
includes “.php.” as part of the name, please rename the file.
_END QUOTE_

Sounds reasonable. And means, you really must protect your uploadings.
A simple way:
$filename = str_replace('.php', '', $_FILES['userfile']['name']);
move_uploaded_file($_FILES['userfile']['tmp_name'],
'yourdirectory/'.$filename);

Hope, this helps,
Niklaus

Arno: If you can request that file using a web browser, and it gets

executed

as PHP on your server then there is an error in the Apache

configuration.

Easy test: create a file in a text editor containing some PHP (<?php
phpinfo(); ?> would be enough) and upload it to the www root of your

site

and name it test.pgif. Then hit http://www.yourdomain.com/test.pgif in

your

browser. If you see the PHP code or an error then you're fine. If you

see

PHP's info page then you need to change web host as quickly as

possible. I

don't care if they fix it - the fact their server was configured to do

this

by default is enough for me to never trust them again.
-Stuart
--
Thanks Stuart. I just tried it now, test.php.pgif displayed the info

while

test.xyz.pgif returned the content, confirming the problem. My

service

provider finally conceded the problem is on their side and are looking

for

an urgent fix, much too complicated to consider moving service

providers in

the short term.
As a side note, the sp said the issue is new and coincided with an

upgrade

to fastcgi recently, I wonder if the hacker was exploiting a known

issue

with that scenario?
Cheers
Arno

[Domain nikha.org]

GoDaddy's default plesk-generated configuration for FastCGI-served PHP

files only looked to see if the file contained ".php" somewhere on it's
path - i.e. it would happily execute 'malicilous.php.txt' as php code,
even something ridiculous like 'malware.phpnoreallyiwantthistorun'.
Yes, looks stupid.
But my service prodider wrote me this, I quote:
---QUOTE---
This is because Apache offers features like language negotiation based
on extensions, too -- the final extension doesn't always just specify
the handler; it can specify other things. Apache can automatically pick
a German-language script from these, for example:

file.php.de
file.php.en

Whether this is a good idea or not is debatable. It's possible to set
things up in a different way (using FilesMatch instead of AddHandler)
to
avoid this particular problem, but that breaks other things, so there's
no perfect solution.

More generally, the real problem is that scripts are looking at the
final extension of uploaded files to decide whether they're safe or
not,
which is dangerous. They're simply assuming that a ".gif" file can't
run
a PHP interpreter, for example... which is usually true, but certainly
not always: some people run all their files through PHP.
---END QUOTE---

The problem is the weak PHP upload mechanism!
As workaround my service provider tries to block suspicious filenames,
but the PHP developpers themself should work on this severe security
problem.

Niklaus

[Stuart Dallas]

Post by Domain nikha.org

GoDaddy's default plesk-generated configuration for FastCGI-served PHP

files only looked to see if the file contained ".php" somewhere on it's
path - i.e. it would happily execute 'malicilous.php.txt' as php code,
even something ridiculous like 'malware.phpnoreallyiwantthistorun'.
Yes, looks stupid.
---QUOTE---
This is because Apache offers features like language negotiation based
on extensions, too -- the final extension doesn't always just specify
the handler; it can specify other things. Apache can automatically pick
file.php.de
file.php.en
Whether this is a good idea or not is debatable. It's possible to set
things up in a different way (using FilesMatch instead of AddHandler)
to
avoid this particular problem, but that breaks other things, so there's
no perfect solution.
More generally, the real problem is that scripts are looking at the
final extension of uploaded files to decide whether they're safe or
not,
which is dangerous. They're simply assuming that a ".gif" file can't
run
a PHP interpreter, for example... which is usually true, but certainly
not always: some people run all their files through PHP.
---END QUOTE---

This is somewhat daft. Yes, Apache offers this feature, but you don't need to configure it to work will all extensions. I'd be curious to know what their issue is with using FilesMatch, since that provides a way to disable this behaviour. And, honestly, who would have a PHP file per language? I think it's perfectly reasonable to not allow that, because duplicating PHP code across many files is an incredible stupid way to support multiple languages.

"Some people run all their files through PHP" - true, but that doesn't mean they should, or that you, as a responsible web host, should be endorsing it.

Post by Domain nikha.org
The problem is the weak PHP upload mechanism!
As workaround my service provider tries to block suspicious filenames,
but the PHP developpers themself should work on this severe security
problem.

PHP developers should absolutely validate all content coming in from users in every possible way, but I would be highly dubious about trusting a host who gives the reason above for what I consider a lax and insecure Apache configuration. It's like saying they sliced your arm off with their chainsaw because it's made for cutting things, attempting to dodge all responsibility for having swung it in your direction!

-Stuart

[Arno Kuhl]

Post by Domain nikha.org

GoDaddy's default plesk-generated configuration for FastCGI-served PHP

files only looked to see if the file contained ".php" somewhere on
it's path - i.e. it would happily execute 'malicilous.php.txt' as php
code, even something ridiculous like 'malware.phpnoreallyiwantthistorun'.
Yes, looks stupid.
---QUOTE---
This is because Apache offers features like language negotiation based
on extensions, too -- the final extension doesn't always just specify
the handler; it can specify other things. Apache can automatically
file.php.de
file.php.en
Whether this is a good idea or not is debatable. It's possible to set
things up in a different way (using FilesMatch instead of AddHandler)
to avoid this particular problem, but that breaks other things, so
there's no perfect solution.
More generally, the real problem is that scripts are looking at the
final extension of uploaded files to decide whether they're safe or
not, which is dangerous. They're simply assuming that a ".gif" file
can't run a PHP interpreter, for example... which is usually true, but
certainly not always: some people run all their files through PHP.
---END QUOTE---

This is somewhat daft. Yes, Apache offers this feature, but you don't need
to configure it to work will all extensions. I'd be curious to know what
their issue is with using FilesMatch, since that provides a way to disable
this behaviour. And, honestly, who would have a PHP file per language? I
think it's perfectly reasonable to not allow that, because duplicating PHP
code across many files is an incredible stupid way to support multiple
languages.

"Some people run all their files through PHP" - true, but that doesn't mean
they should, or that you, as a responsible web host, should be endorsing it.

Post by Domain nikha.org
The problem is the weak PHP upload mechanism!
As workaround my service provider tries to block suspicious filenames,
but the PHP developpers themself should work on this severe security
problem.

PHP developers should absolutely validate all content coming in from users
in every possible way, but I would be highly dubious about trusting a host
who gives the reason above for what I consider a lax and insecure Apache
configuration. It's like saying they sliced your arm off with their chainsaw
because it's made for cutting things, attempting to dodge all responsibility
for having swung it in your direction!

-Stuart
--

It seems this is the standard apache configuration, but that's no excuse.
Googling returned many results where this was described as a major security
threat
e.g. "Beware of the default Apache 2 config for PHP"
http://ilia.ws/archives/226-Beware-of-the-default-Apache-2-config-for-PHP.ht
ml
On that site the solution was to change AddHandler to AddType.
My service provider is going the FilesMatch route.

Cheers
Arno

[Tim Streater]

Post by Domain nikha.org
The problem is the weak PHP upload mechanism!

I'd have said the problem is weak metadata provision - overloading the filename for other purposes.

[Domain nikha.org]

Post by Stuart Dallas
And, honestly, who would have a PHP file per language? I think it's

perfectly reasonable to not allow that, because duplicating PHP code
across many files is an incredible stupid way to support multiple
languages.
I agree!! Didn't even know, that this kind of faked language support
exists...

Post by Stuart Dallas
"Some people run all their files through PHP" - true, but that doesn't

mean they should, or that you, as a responsible web host, should be
endorsing it.

Post by Stuart Dallas
PHP developers should absolutely validate all content coming in from

users in every possible way, but I would be highly dubious about
trusting a host who gives the reason above for what I consider a lax and
insecure Apache configuration. It's like saying they sliced your arm off
with their chainsaw because it's made for cutting things, attempting to
dodge all responsibility for having swung it in your direction!
OK, in principle, I also agree. But this case is very easy to handle.
I'm simply running "str_replace()" against dangerous parts of uploaded
filenames, ".php" for instance. After that, Apache in every
configuration will just serve, and never execute user uploaded files.
Remains the risk on the clients side, I must concede. Better solutions?

Nice days,
Niklaus

[Ashley Sheridan]

Post by Stuart Dallas

Post by Stuart Dallas
And, honestly, who would have a PHP file per language? I think it's

perfectly reasonable to not allow that, because duplicating PHP code
across many files is an incredible stupid way to support multiple
languages.
I agree!! Didn't even know, that this kind of faked language support
exists...

Post by Stuart Dallas
"Some people run all their files through PHP" - true, but that doesn't

mean they should, or that you, as a responsible web host, should be
endorsing it.

Post by Stuart Dallas
PHP developers should absolutely validate all content coming in from

users in every possible way, but I would be highly dubious about
trusting a host who gives the reason above for what I consider a lax and
insecure Apache configuration. It's like saying they sliced your arm off
with their chainsaw because it's made for cutting things, attempting to
dodge all responsibility for having swung it in your direction!
OK, in principle, I also agree. But this case is very easy to handle.
I'm simply running "str_replace()" against dangerous parts of uploaded
filenames, ".php" for instance. After that, Apache in every
configuration will just serve, and never execute user uploaded files.
Remains the risk on the clients side, I must concede. Better solutions?
Nice days,
Niklaus

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.


Thanks,
Ash
http://www.ashleysheridan.co.uk

[Tamara Temple]

Post by Domain nikha.org
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.

[Domain nikha.org]

Post by Tim Streater

Post by Domain nikha.org
The problem is the weak PHP upload mechanism!

I'd have said the problem is weak metadata provision - overloading the

filename for other purposes.

Post by Tim Streater
--
Cheers -- Tim

You are right, but unfortunately filenames ARE metadata for Apache.
Would be better, if they were not, and just identifiers...

Niklaus

[Domain nikha.org]

Post by Ashley Sheridan
No, no, no! That is not a good stand-in for fundamental security
principles!
<?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

Post by Ashley Sheridan
easy to alter. I've just tested this with a regular jpeg, the same

jpeg

Post by Ashley Sheridan
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

Post by Ashley Sheridan
extension. In the case of the first 2, a new jpeg is generated with

the

Post by Ashley Sheridan
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

[Ashley Sheridan]

Post by Ashley Sheridan

Post by Ashley Sheridan
No, no, no! That is not a good stand-in for fundamental security
principles!
<?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

Post by Ashley Sheridan
easy to alter. I've just tested this with a regular jpeg, the same

jpeg

Post by Ashley Sheridan
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

Post by Ashley Sheridan
extension. In the case of the first 2, a new jpeg is generated with

the

Post by Ashley Sheridan
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.

Post by Ashley Sheridan
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

Post by Ashley Sheridan
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.

Post by Ashley Sheridan
users can upload! How to detect them, if the extension is missleading?

The extension comes from the user. Never trust the user, ever.

Post by Ashley Sheridan
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,

Post by Ashley Sheridan
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.

Post by Ashley Sheridan
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

Post by Ashley Sheridan
execution of things that should be never executed!

Erm, no, the image isn't being executed.

Post by Ashley Sheridan
"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.

Post by Ashley Sheridan
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

[Robert Stone]

________________________________
De: Ashley Sheridan <***@ashleysheridan.co.uk>
Para: ***@nikha.org; Domain nikha.org <***@nikha.org>
Cc: php-***@lists.php.net
Enviadas: Quarta-feira, 25 de Setembro de 2013 2:22
Assunto: Re: [PHP] Apache

Post by Ashley Sheridan

Post by Ashley Sheridan
No, no, no! That is not a good stand-in for fundamental security
principles!
<?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

Post by Ashley Sheridan
easy to alter. I've just tested this with a regular jpeg, the same

jpeg

Post by Ashley Sheridan
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

Post by Ashley Sheridan
extension. In the case of the first 2, a new jpeg is generated with

the

Post by Ashley Sheridan
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.

Post by Ashley Sheridan
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

Post by Ashley Sheridan
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.

Post by Ashley Sheridan
users can upload! How to detect them, if the extension is missleading?

The extension comes from the user. Never trust the user, ever.

Post by Ashley Sheridan
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,

Post by Ashley Sheridan
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.

Post by Ashley Sheridan
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

Post by Ashley Sheridan
execution of things that should be never executed!

Erm, no, the image isn't being executed.

Post by Ashley Sheridan
"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.

Post by Ashley Sheridan
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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


Sorry for this late post but I'm amazed nobody consulted the doco.

The php.net site has a whole section titled "Handling File Uploads".
Also check out finfo_open and finfo_file.
If your are a windoze user you need a dll.
If you want Apache to handle PUT requests you MUST tell it to run a script as it cannot write to web root.

HTH

Robert

[Domain nikha.org]

Post by Tamara Temple

Post by Domain nikha.org
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

[Domain nikha.org]

Post by Ashley Sheridan
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!

Post by Ashley Sheridan
And on behalf images: GD you are using handles only

Post by Domain nikha.org
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!

Post by Ashley Sheridan
The hacker says: Hi,

Post by Domain nikha.org
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

[Ashley Sheridan]

Post by Ashley Sheridan

Post by Ashley Sheridan
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!

Post by Ashley Sheridan
And on behalf images: GD you are using handles only

Post by Domain nikha.org
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.

Post by Ashley Sheridan
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

Post by Ashley Sheridan
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.

Post by Ashley Sheridan
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

Post by Ashley Sheridan
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

Post by Ashley Sheridan
awfull
enough, and opens a new exploit!

Post by Ashley Sheridan
The hacker says: Hi,

Post by Domain nikha.org
this is a nice picture, play it, and then, please do this--follows

his

Post by Ashley Sheridan

Post by Domain nikha.org
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