https://bugzilla.wikimedia.org/show_bug.cgi?id=31930
John Mark Vandenberg <jay...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugzilla.wikimedia.
| |org/show_bug.cgi?id=24230
Summary|Mimetype of normal jpg |Image upload fail with
|misdetected as zip |error bad-zip due to being
| |misdetected as a broken zip
| |irrespective of mimetype
Alias| |bad-zip
--- Comment #2 from John Mark Vandenberg <jay...@gmail.com> ---
So these bugs are cause by the 'JAR detection' of bug 24230 / r82783
Retested on https://test.wikipedia.org/ , the attachment causes the following
error:
"The file is a corrupt or otherwise unreadable ZIP file. It cannot be properly
checked for security."
$ file A.jpg
A.jpg: JPEG image data, JFIF standard 1.02
The same is happening with a GIF on bug 54105
The error code for that error is 'zip-bad', and it is only raised in
includes/utils/ZipDirectoryReader.php, and ZipDirectoryReader is only used in
includes/upload/UploadBase.php, and only if $wgAllowJavaUploads is disabled,
which it is by default.
https://www.mediawiki.org/wiki/Manual:$wgAllowJavaUploads
(That variable should be renamed $wgCheckAllUploadsForJava , and it would be
really handy if someone documented the checks performed in a technical manner
like 'It looks for the byte sequence "50 4B 05 06"', so the average sysadmin
can know that they have found the source of the problem with a particular
upload.)
My concern is that if the ZIP file is unreadable, why does it need to be
checked for security? My guess is that this check assumes the presence of the
jifar bug, and other unidentified bugs in the JVMs ZIP reader, which combined
allow an unreadable ZIP to be loaded as a JAR. Paranoid much? ;-) There are
quite a few JAR reading bugs across all JVMs, so it doesnt hurt to be a bit
paranoid, but maybe the detector can be improved a little to determine that
some of these false positives are not actually going to be successfully
executed by any JVM.
There are also other image reading bugs in various browsers which allow
arbitrary execution of code; are we checking all images for those bugs? (I
couldnt see code for that in UploadBase) If we increase the number of file
types supported, the number of potential problems increases.
Another approach is to flag these bad-zip uploads (and other uploads which trip
bugs in some browsers) as not readily able to be used in an IMG/etc tag, place
them in a special maintenance category (and display a warning), and only serve
them as a MIME-encoded download from a host that is not *.wikimedia.org. That
way the uploads happen, and the problem becomes visible to the community, who
can track these uploads and improvements to the Java detector code are more
likely to occur. (the flag can be reset on re-upload after the algorithm has
been improved)
It would also be nice for this error, and other security checks like script
checks, to be a warning only based on a config variable. In wikis without
unrestricted uploaders, or an environment where all clients run a fully patched
SOE, checks like these are nice warnings, but shouldnt be unsolvable errors
(i.e. without turning off the security check).
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
