The "Multipart MIME Responses” bit is really interesting. So if I understand correctly:
1) a server under control of an attacker can send a multipart response with multiple HTML parts
2) we ignore all parts except the *last* one (which is probably the right thing to do)
3) malware detection proxies/filters might ignore all parts except the *first* one
(There is no mention of specific software that does #3 so that part is a bit vague but I could see how an attacker could abuse that.)
I don’t know if this is a common technique that is used in the wild. If it is then we might want to consider changing our logic for multipart and render the *first* part received. That would close this loophole.
Not sure if that would break any existing legit apps that might depend on the current multipart behaviour though.
> I don’t know if this is a common technique that is used in the wild.
This is a particular example of a technique that is used in the wild.
It is a consequence of Postel's Law. I call it a "Postel Bug".
Software that accepts "out-of-spec" inputs in order to interoperate
necessarily does so on an ad hoc basis. So, two different
implementations can treat malformed inputs differently. This is exactly
what is happening with the malware detection software and your software.
On 7/3/13 11:44 AM, Stefan Arentz wrote:
> The "Multipart MIME Responses” bit is really interesting. So if I understand correctly:
> 1) a server under control of an attacker can send a multipart response with multiple HTML parts
> 2) we ignore all parts except the *last* one (which is probably the right thing to do)
This is not the case. If a multipart response is sent, we will render
all the parts one after another.
For example, you can send a multipart in which the first part is HTML
page that says "wait for the next part", the second a .doc that will get
handed off to a helper app, and the third is an HTML page that says "all
> This is no an out-of-spec input. It's a quite specified input.
Not sure I want to get into the weeds on this one, but I have put
"out-of-spec" in quotes because I think "specifications" are mythical
What is claimed in this case by the referenced web page is that Firefox
and Opera treat multipart/mixed differently. So either Firefox is
"out-of-spec" wrt the input, or Opera is, or both are, or the
"specification" is ambiguous. In any case, a general defense is
On 7/5/13 6:19 AM, Gervase Markham wrote:
> On 03/07/13 17:41, Boris Zbarsky wrote:
>> This is not the case. If a multipart response is sent, we will render
>> all the parts one after another.
> I know this is true if the MIME type is multipart/x-mixed-replace, but
> there are other multipart MIME types. Is it true for them also?
We have identical handling, at first glance, for
multipart/x-mixed-replace, multipart/mixed, and multipart/byteranges.
At least when loaded in a browsing context.