Last modified: 2014-02-19 22:30:45 UTC
Original title: Refuse uploading files that contain huge data of other file types, especially if this data is encrypted * https://commons.wikimedia.org/wiki/Commons_talk:Criteria_for_speedy_deletion#password_protected_embedded_files * https://commons.wikimedia.org/wiki/Commons:Deletion_requests/Files_uploaded_by_Colorj123
Wondering at which exact state this refusal would take place. This request might be "UploadWizard" (or "Special:Upload") territory instead of "File management".
> Wondering at which exact state this refusal would take place. > This request might be "UploadWizard" (or "Special:Upload") territory instead > of > "File management". Probably the same stage we do other file type checks. (On the backend after the upload) ----- Given that these files have been deleted, could an example be attached to this bug so we can see what the file actually looks like? I'm given to understand these were valid JPEG's with extra junk in metadata segments? I'm not sure we would be able to strip that without worrying about damaging real metadata. If the images just had extra data embedded into the image data using stenography, it would be pretty difficult to detect in general.
Created attachment 12039 [details] sample: https://commons.wikimedia.org/w/index.php?title=File:Fresh_Relic_4531.JPG My computer just crashed (step by step human input devices stopped working) after viewing one of them so I really hope they do not contain evil code.
Created attachment 12040 [details] sample: https://commons.wikimedia.org/w/index.php?title=File:PencilCherryTable.JPG
(In reply to comment #3) > Created attachment 12039 [details] > sample: > https://commons.wikimedia.org/w/index.php?title=File:Fresh_Relic_4531.JPG > > My computer just crashed (step by step human input devices stopped working) > after viewing one of them so I really hope they do not contain evil code. This one seems to contain a password protected file. Opening it with 7z prompts for a password. The second one (12040) should contain something also, although 7z was unable to detect an archive there. As one can see, both images are displayed fast (while downloading) and then the browser keeps downloading data even if the image is already displayed. As I've read, it's extremely easy to add any file inside a jpeg and yet have an absolutely valid image that displays perfectly. It can be done by just concatenating the contents of a file to an existing jpeg image.
Hmm, if its just stuff concatenated at the end, it would probably be possible to detect (Look for the \xFF\xD9 marker, see if anything after it) [From a security paranoia, doing this would probably not be a bad idea. GIFAR and all] ----- Looking at these files, they are indeed just stuff stuffed at the end. For 1239: 00011d40 e6 93 34 a7 ad 25 0b 61 85 14 51 4c 0f ff d9 37 |..4..%.a..QL...7| 00011d50 7a bc af 27 1c 00 03 d8 f3 90 3d 40 84 9c 00 00 |z..'......=@....| Note the ff d9 denotes end of image (EOI). After that 37 7A BC AF 27 1C are the magic numbers for a 7z archive. For the second image (1240) we have: 0000dc80 dd cf a1 f5 a6 9e b4 87 a9 a1 6b a8 92 3f ff d9 |..........k..?..| 0000dc90 43 d6 cd 64 8a dc f7 24 57 18 a8 2f e3 dd 38 34 |C..d...$W../..84| Which doesn't have any magic numbers that I could see. However, it definitely doesn't appear to be JPEG data as we later on have ff sequences that aren't escaped. Maybe its the second part to some file split up over multiple jpegs or maybe encrypted, or something else.
