Ensure image MIME type matches extension

[Viper007Bond]

Take a bitmap (BMP) and rename it to .png. WordPress will say it's an image/png everywhere you look. This can cause issues if you're trying to manipulate it (thumbnail it, etc.).

We should either fix the extension or reject it.

Potential solution

Above patch fixes the extension. Tested and seems to work great.

This patch requires GD and should therefore be wrapped in if ( function_exists('getimagesize') ) {. The patch is just a preliminary one though, so I won't bother updating it yet.

I took a "png" renamed it to "gif" (with patch). Uploaded. File was changed to the correct format, but in the editor it still says "File type: image/gif". Perhaps override the file type as well?

This is a potential security problem. Recommending 2.9.2 release fix.

Patch improvements, likely needs porting to wp_handle_sideload() too

Replying to ShaneF:

This is a potential security problem. Recommending 2.9.2 release fix.

I can't think of a way to validate other extensions though, i.e. say a EXE uploaded as an AVI.

Don't we have an array already in there that is offering mime-types per extension? I think it's adviseable to use the same datasource here therein the patch as well instead offering duplicate data.

Replying to hakre:

Don't we have an array already in there that is offering mime-types per extension? I think it's adviseable to use the same datasource here therein the patch as well instead offering duplicate data.

That array (in get_allowed_mime_types()) is a list of allowed MIMEs that's filterable. It also has multiple extensions to one common MIME. Yes, I guess I could array_flip() it and then pop off the first extension, however I didn't think this was reliable enough due to the filter.

Replying to Viper007Bond:

That array (in get_allowed_mime_types()) is a list of allowed MIMEs that's filterable. It also has multiple extensions to one common MIME. Yes, I guess I could array_flip() it and then pop off the first extension, however I didn't think this was reliable enough due to the filter.

Actually, I take that back, it could work now that I think of it.

Well I did not say that it is fitting per-se, but worth to take a look into it. I mean why duplicate data here? But no idea if it is available in the location you would like to use it. We might need to introduce another filter here (or isn't there already one?!). Might make sense in the one or other way.

Now I remember why I just made a new array -- it's the list of image types that the function can identify. No point in using the other array.

Minor code improvements

(In [14400]) Ensure image MIME type matches extension for images. props Viper007Bond, fixes #11946.

Should be moved to a helper function and added to the other upload functions (sideload and the bits one).

Bumping the need for a patch up the importance radar

Introduce new helper function and use it in all 3 upload functions

11946.4.patch introduces wp_check_filetype_and_ext() which does what wp_check_filetype() does, but then goes on to attempt to validate the type and extension. If it determines that the extension doesn't match what the type truly is, then it'll return proper_filename as a part of it's returned array.

I've modified the standard upload function, the sideload function, and the bits function to make use of this new function.

I have only tested this using the standard upload process, not sideload or bits.

(In [14649]) Introduce wp_check_filetype_and_ext() to handle mime/ext image comparisons and corrections for upload and sideload. props Viper007Bond, see #11946.

Viper007Bond and I have thoroughly tested this for sideloads and uploads. Weary about bits, so going to handle that no sooner than 3.1.

3.1 now on shedule. maybe optionally support ​fileinfo?

Just need to get the existing patch working for bits. Probably would be good for Joseph to take a look.

Patch is broken.

[14649]

Last bit is needed.

Added a fix for wp_upload_bits at ticket #21292