Last modified: 2014-10-11 14:21:32 UTC
Created attachment 9279 [details] Problem file See attached image... It's impossible to upload
Well, it does trip signature checks in other zip tools: $ unzip -vb A.jpg Archive: A.jpg ??ڱuXâ??ps?E;*w=V?>??^??=Hڤ濇`F?Y]f?3?ہ?q???}ʢp???["?G?%?????#?:???(3????8???%>x~:?Xދ???-????!?{q????z??S3IH???ҘGh??A?"9?TH?U??g????&???_?x??????K'Q$-<q:?W?I9??R?h?)??b8?i?;?T??©\?OnK?N????l???U<ܬ???? ?'ڮ?.ā1?d???? caution: zipfile comment truncated warning [A.jpg]: zipfile claims to be last disk of a multi-part archive; attempting to process anyway, assuming all parts have been concatenated together in order. Expect "errors" and warnings...true multi-part support doesn't exist yet (coming soon). error [A.jpg]: missing 2744938539 bytes in zipfile (attempting to process anyway) error [A.jpg]: attempt to seek before beginning of zipfile (please check that you have transferred or created the zipfile in the appropriate BINARY mode and that you have compiled UnZip properly) but it's pretty clearly not a real zip file, as you get some pretty broken results trying to unzip it. :)
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).
