[PHP] No MIME-Type in imap_fetch_overview()
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
RE: [PHP] Apache
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 youre 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 Kuhl am Donnerstag, 19. September 2013 - 16:14:
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
--
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 - 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--- 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache
Stuart Dallas am Montag, 23. September 2013 - 12:58: 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... 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. 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Apache
Tim Streater am Montag, 23. September 2013 - 12:56: On 23 Sep 2013 at 11:37, Domain nikha.org m...@nikha.org wrote: The problem is the weak PHP upload mechanism! I'd have said the problem is weak metadata provision - overloading the filename for other purposes. -- Cheers -- Tim You are right, but unfortunately filenames ARE metadata for Apache. Would be better, if they were not, and just identifiers... Niklaus -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] No MIME-Type in imap_fetch_overview()
Negin Nickparsa am Montag, 23. September 2013 - 20:59: I have read your mail twice and still I could not get what you want exactly. Sorry for my bad english! What I want is, that the users of my webmail client can see at a glance, if mails in their mailboxes have attachments or not. (Thats a human right! But of course I was joking... It's simply nice to provide this information and should be done) 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. Yes, I could do even that! But this is worse! Imagine, you do this in the overview of the mailbox content! This can be hunderds of mails! My script paginates this stuff in blocks of 16 (or something) mail headers, but even then you have an huge overhead. Why? Because, first you must collect the sender and subject information. This is done by imap_fetch_overview(), parsing the mailheaders and grabing some server data, like arrival date, size and flags. Fine, but you still know nothing about attachments! You must do something more. OK? You whould run imap_fetchstructure(), but sorry, that's the wrong time and place. You will need this monster object only when the user _reads_ some specific mail. At the moment, we are not reading, but collecting mails to present them in the mailbox overview. My script modestly fetches the mailheaders again to read the Content-Type-line. That's quite fast, works fine, but is stupid, because this headers were fetched and parsed just before! I ask you, and all PHP developpers: Why the hell this function does not parse this line too? (a part of so much others of less importance) The same is true for imap_headerinfo(). And: of course this Content-Type-line provides by far not the complete MIME-structure as imap_fetchstructure() does, but, as said, we don't need this at the moment. The result is a script, that I self whould not describe as good practice because of it's duplicated parsing of the same string, but I found no other way yet. That's my problem, you see? Sincerely Niklaus -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] No MIME-Type in imap_fetch_overview()
Aziz Saleh am Montag, 23. September 2013 - 22:06: What Niklaus wishes for is a way to detect if an email message contains an attachment by just reading the headers (correct me if I am wrong). Yes, that's what I'm seeking :-) This isn't really a PHP issue. In any language you can't really figure out if an email has an attachment by just looking at the headers, you need to check the body. You can try to infer by using the content-type or the size, but that isn't 100% valid. That's like radio Eriwan: In principle you are right! BUT: I want not show the whole MIME-structure in the mailbox overview! That whould be absurd, and indeed could only be done by reading the body. Nevertheless we have in the primary header of any MIME compliant message the line Content-Type. (We have it also in the headers of the attached parts, but that is not intresting now) In this primary header (fetched by imap_fetchbody($mailbox, $msg_no, 0)) the leading part of the MIME-type description can have only two values: text or multipart. Right? I'm sure you will never find other values in the _primary_ header. That's the first decision for your script. text: no attachment, multipart: attachment. No matter the subtype-value after the slash, you have what I want! And ONLY by looking on the header. And this ist 100% valid, because it follows logically from the imap- and MIME-rfc's. About malformed messages violating the protocols we discuss next year, you agree? :-) You may evaluate the subtype after the slash. If the type is multipart, you will find mixed, alternative, related or digest, if the type is text, you will have plain or html as subtype. May be there are more subtypes on the way, but all these are optional for the primary job, a decent mailbox overview must do: tell the user, whether there are attachments or not. My own webmail client does this job pretty good, but it violates my own standard of good practice. Whether imap_fetch-overview() nor imap_headerinfo are reading the Content-Type-line while parsing much other header lines of minor importance. My script must refetch the mailheaders to do that! This is an ugly overhead I wish to avoid. BTW: the squirrelmail-staff, leading in the PHP-webmail-world, just ignores the whole imap-extension of PHP. Instead, they talk low level with the server. But this way is a little bit too hard for me... Therefore my pledge to all involved into the development of the fabulous PHP framework, section imap: Please ad the primary MIME-type to the objects returned by fetch_overview and headerinfo! It's so ridiculous simple: read the Content-Type-line in the primary mailheader as I must do afterwards, only because you do not! Niklaus -- 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
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
