3 ms·
You have it all backwards. A MIME type cannot be "spoofed" because a MIME type is a processing instruction, not a certification. If you receive an entity that i
by zAy0LfpBZLC8mAC 9y ago
You have it all backwards. A MIME type cannot be "spoofed" because a MIME type is a processing instruction, not a certification. If you receive an entity that is labeled as "image/jpeg", that means that you are instructed to treat it as a JPEG image. That is to say, you should only hand it to a JPEG decoder. As with any processing of untrusted input, that JPEG decoder should obviously not have any vulnerabilities, and it should reject any syntactically invalid input. If someone takes a video file and sends it to you labeled as "image/jpeg", there is no spoofing going on, you simply received a syntactically invalid JPEG image which you consequently should reject.
Unfortunately, browsers, in particular IE, had this habit of ignoring the relevant standards and do what has become known as "content sniffing": They ignore the declared MIME type and instead try to guess the correct decoder based on the content. That was (well, still is, for backwards compatibility reasons) a huge vulnerability in browsers. If browsers simply followed the relevant standards, there would be absolutely no problem with serving an uploaded "image/jpeg" entity without any verification, as no browser should do anything with it other than notice that it's an invalid JPEG image. That you have to care about this at all is because you have to work around vulnerabilities in browsers, not because anything is being "spoofed".
- dvt 9y agoA MIME type can be spoofed because spoofing doesn't only apply to certifications (e.g. IP spoofing, caller ID spoofing[1], etc.). Spoofing merely means "tricking" or "lying" -- and this can introduce all kinds of complications. There are literally dozens of bugs (in all browsers, not just IE) that exist due to the fact that MIME types can often be misleading[2][3][4]. [1] https://en.wikipedia.org/wiki/Caller_ID_spoofing https://en.wikipedia.org/wiki/Caller_ID_spoofing [2] https://www.mozilla.org/en-US/security/advisories/mfsa2005-16/ https://www.mozilla.org/en-US/security/advisories/mfsa2005-1... [3] https://blog.mozilla.org/security/2016/08/26/mitigating-mime-confusion-attacks-in-firefox/ https://blog.mozilla.org/security/2016/08/26/mitigating-mime... [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1295945 https://bugzilla.mozilla.org/show_bug.cgi?id=1295945
- zAy0LfpBZLC8mAC 9y agoBut the thing is that there is no tricking or lying. There is simply a syntactically invalid entity. And idiotic software that does completely irresponsible things when confronted with such syntactically invalid entities, such as feeding syntactically invalid JPEG images to the javascript interpreter. MIME types also can not be misleading. MIME types are the authoritative declaration of what something is. If it's not that, then there is nothing misleading, it's simply invalid. Framing this as "MIME spoofing" is about as sensible as calling a buffer overflow in some font renderer "machine code spoofing". If your font renderer under some circumstances takes pieces of the font description it is interpreting and feeds them to the CPU for execution, that is not "machine code spoofing", it's simply a buffer overflow vulnerability in your font renderer. And just as a font renderer shouldn't feed pieces of the font to the CPU for execution, a JPEG parser shouldn't feed pieces of the image to a javascript interpreter for execution.