Last modified: 2010-05-15 14:35:54 UTC
Currently, files that have a file extension that does not match their real mime type are rejected ONLY if the real type can be determined. You could upload a bunch of random bytes as a JPG. Note that the real mime type is determined by $wgMimeDetectorCommand, finfo_open or mime_content_tye, depending on setup. I suggest to change this behavior, see the patch attached. The patch does the following: IF the mime type can not be determined BUT the file extension is listed in mime.info ($wgMimeInfoFile), reject the file. IF the mime type can not be determined AND the file extension is NOT listed in mime.info, allow the file. The only possible problem I see is this: IF an "obscure" file type is allowed BUT that type is not recognized by the mime detection AND the file extension is listed in mime.info, such files will be rejected. The solution would be to remove that file type from mime.info (or change the method of mime detection).
Created attachment 946 [details] patch against head
FIXED in CVS HEAD
This bug is a regression in 1.5; it doesn't always seem to trigger, but it can reproduce it on my Linux test box with $wgMimeDetectorCommand = 'file -bi'. Applied fix to REL1_5 branch, will appear in 1.5.1.
Patch is bad -- has broken uploads of all filetypes other than built-in images. Reopening.
Created attachment 950 [details] Fix to the fix Additional patch to fix the breakage of unrecognized types. Adds a separate function MimeMagic::isRecognizableExtension() which just matches on extensions which are known to be recognizable from their content (currently, the list of types for getimagesize()). Extensions on that list will be rejected when detection comes back with 'unknown'; extensions not on that list can't be reliably detected from content so will be passed on as before.
