Circumventing Security Systems With Dubious HTTP Responses

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Circumventing Security Systems With Dubious HTTP Responses

Brian Smith-31
"Circumventing Security Systems With Dubious HTTP Responses":
http://noxxi.de/research/dubious-http.html

Does anybody see any action items here?
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Circumventing Security Systems With Dubious HTTP Responses

Stefan Arentz-5

On Jun 13, 2013, at 12:46 AM, Brian Smith <[hidden email]> wrote:

> "Circumventing Security Systems With Dubious HTTP Responses":
> http://noxxi.de/research/dubious-http.html
>
> Does anybody see any action items here?

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.

 S.

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Circumventing Security Systems With Dubious HTTP Responses

Trevor Jim-2
Stefan Arentz <[hidden email]> writes:

> 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.

I've written up some other examples here:

    http://trevorjim.com/postels-law-and-network-security/
    http://trevorjim.com/postels-law-and-security-again/
    http://trevorjim.com/postels-law-is-not-for-you/

-Trevor
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Circumventing Security Systems With Dubious HTTP Responses

Boris Zbarsky
In reply to this post by Brian Smith-31
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
done".

You can see this by going to
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=foo and noting that
the "please wait while your bugs are retrieved" part with the animated
dino is shown until the second part with the actual buglist comes in.

> 3) malware detection proxies/filters might ignore all parts except the *first* one

Those would be some pretty broken filters.  :(  Doesn't mean they don't
exist, of course.

> 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.

Websites depend on all the parts being rendered.  Or at least websites
certainly depend on the "hand off some parts to helper apps, then show
the last HTML part" behavior.

-Boris
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Circumventing Security Systems With Dubious HTTP Responses

Boris Zbarsky
In reply to this post by Stefan Arentz-5
On 7/3/13 12:24 PM, Trevor Jim wrote:
> Software that accepts "out-of-spec" inputs in order to interoperate

This is no an out-of-spec input.  It's a quite specified input.

-Boris
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Circumventing Security Systems With Dubious HTTP Responses

Stefan Arentz-5

On Jul 3, 2013, at 12:41 PM, Boris Zbarsky <[hidden email]> wrote:

> On 7/3/13 12:24 PM, Trevor Jim wrote:
>> Software that accepts "out-of-spec" inputs in order to interoperate
>
> This is no an out-of-spec input.  It's a quite specified input.

Thanks Boris. Makes sense.

 S.

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Circumventing Security Systems With Dubious HTTP Responses

Trevor Jim-2
In reply to this post by Boris Zbarsky
Boris Zbarsky <[hidden email]> writes:

> 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
creatures.

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
difficult.


-Trevor
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Circumventing Security Systems With Dubious HTTP Responses

Gervase Markham
In reply to this post by Brian Smith-31
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?

> You can see this by going to
> https://bugzilla.mozilla.org/buglist.cgi?quicksearch=foo and noting that
> the "please wait while your bugs are retrieved" part with the animated
> dino is shown until the second part with the actual buglist comes in.

Bugzilla uses multipart/x-mixed-replace. This was a Netscape proprietary
extension, but it now supported by all browsers except IE.

Gerv

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Circumventing Security Systems With Dubious HTTP Responses

Boris Zbarsky
In reply to this post by Brian Smith-31
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.

-Boris
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security