php-general Digest 24 Sep 2013 10:38:18 -0000 Issue 8375
php-general Digest 24 Sep 2013 10:38:18 - Issue 8375 Topics (messages 322160 through 322170): Re: No MIME-Type in imap_fetch_overview() 322160 by: Negin Nickparsa 322161 by: Negin Nickparsa 322166 by: Aziz Saleh 322168 by: Domain nikha.org 322169 by: Domain nikha.org Re: Apache 322162 by: Domain nikha.org 322165 by: Ashley Sheridan 322167 by: Tamara Temple 322170 by: Arno Kuhl Re: filesize() fails on file and works on it's copy (same permissions, same directory) 322163 by: MichaÅ Kochanowicz 322164 by: MichaÅ Kochanowicz 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 -- ---BeginMessage--- I have read your mail twice and still I could not get what you want exactly. can't get the structure of the email either although you elaborate it in details. you have said something about human rights that I couldn't understand why? but if you want to get the type of files fetch the structure and then you can use disposition string, find the attachment and then return the array. Sincerely Negin Nickparsa On Wed, Sep 18, 2013 at 3:27 PM, Domain nikha.org m...@nikha.org wrote: Hello all, im posting this here, because the bug report system of php.net is not right place for my problem. It's not a bug, but a wish - an I found there no wishlist option at all. I'm running my own webmail-client, written in PHP. It is stable, fast and pretty, showing the full power of the PHP imap section. Of course it presents paginated content lists for every mailbox the user may open. These lists tell him some usefull things about every mail actually listed: Sender, date, subject, size and (eventually) flags. All these things are nicely delivered by the function imap_fetch_overview() The same could be done by calling imap_headerinfo() for every single mail, but fetch_overview seems to be faster, because it does it at once for the whole batch. BUT NONE OF THEM returns any information about the MIME-Type of the mail! Since the user of my webmail client has the intrinsic, natural born an general human right to KNOW whether some mail in his mailbox has attachments or not, I'm forced to do very ugly things. My script calls additionally for every (!) actually listed mail imap_fetchbody($connect, $msg_no, 0) - where $connect holds the result of imap_open(). That gives me the mail header, the script reads the line starting with Content-Type: and returns its content. Evaluating this against mixed or alternative we have finaly what we want: This mail has attachments! Or is written in HTML, what is even more we wanted! Works fine, but is ugly. First fetch_overview parses all mail headers, then they are fetched again to be parsed for the MIME-Type. I could just omit fetch_overview and read the headers by my own means, that whould be faster, but then I loose the size information, that is NOT (and cannot) be part of the mail header! If I want to have both, size and MIME-Type, and I WANT to have both, respecting the intrinsic, natural born and general human rights of my user, im must call both, overview and fetchbody. My question is this: Is there a better solution? Or is there someone that knows someone among the PHP-Developpers to suggest them an improvement of the functions imap_fetch_overivew() and imap_headerinfo(). Please, Please, add the MIME-Type to your fantastic object collections! BTW: It's really easy. Read the Content-Type-Line! Sorry... Hope, somebody has an idea, my regards, Niklaus -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php ---End Message--- ---BeginMessage--- I have read your mail twice and still I could not get what you want exactly. can't get the structure of the email either although you elaborate it in details. you have said something about human rights that I couldn't understand why? but if you want to get the type of files fetch the structure and then you can use disposition string, find the attachment and then return the array. Sincerely Negin Nickparsa On Wed, Sep 18, 2013 at 3:27 PM, Domain nikha.org m...@nikha.org wrote: Hello all, im posting this here, because the bug report system of php.net is not right place for my problem. It's not a bug, but a wish - an I found there no wishlist option at all. I'm running my own webmail-client, written in PHP. It is stable, fast and pretty, showing the full power of the PHP imap section. Of course it presents paginated content lists for every mailbox the user may open. These lists tell him some usefull things about every mail actually listed:
php-general Digest 24 Sep 2013 22:58:33 -0000 Issue 8376
php-general Digest 24 Sep 2013 22:58:33 - 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
--
---BeginMessage---
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---
---BeginMessage---
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---
---BeginMessage---
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
RE: [PHP] Apache
On 23 Sep 2013, at 11:37, Domain nikha.org m...@nikha.org wrote: Tamara Temple am Montag, 23. September 2013 - 06:49: 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--- 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. 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache
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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache
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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
