Subject: p1: additional security considerations

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Apr 2013 16:02:22 +1000

Just wondering if we need to explicitly point out the security considerations around the following:

* Message routing -- it's somewhat common AIUI for intermediaries to only route on the Host header, for performance reasons; i.e., they do not reconstruct the effective request URI (as required by p1 5.5). I know there's a theoretical risk here, but is there a real-world risk that we should point out?

* Message delimitation - the consequences for getting message delimitation wrong (whether it's regarding multiple content-length headers, processing 1xx responses correctly, etc.) are now well-understood. Should we point it out explicitly in SC?

--
Mark Nottingham   http://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 23 Apr 2013 08:15:06 +0200

On Tue, Apr 23, 2013 at 04:02:22PM +1000, Mark Nottingham wrote:
> * Message routing -- it's somewhat common AIUI for intermediaries to only
> route on the Host header, for performance reasons; i.e., they do not
> reconstruct the effective request URI (as required by p1 5.5). I know there's
> a theoretical risk here, but is there a real-world risk that we should point
> out?

I see no particular risk since the Host header field is mandatory. Also in
practice, intermediaries which "route" requests tend to be very close to
the servers, at places where the security considerations are very specific
to the environment and explicitly covered in this intermediary's configuration.

Maybe we should point one thing though, which is not related to intermediaries
but all recipients in general : recipients of a request message which consider
the Host header field to decide about what content to serve must ensure of its
unicity before serving the request. Otherwise the risk is that an intermediary
could use a first instance to route the request and that a server would use the
last one for example.

> * Message delimitation - the consequences for getting message delimitation
> wrong (whether it's regarding multiple content-length headers, processing 1xx
> responses correctly, etc.) are now well-understood. Should we point it out
> explicitly in SC?

Yes I think that's important to add something about this, especially since
I discovered a few weeks ago a "security" product which was able to "fix"
badly chunked data ! It was quite scary to imagine that an improperly chunked
content which could possibly contain whatever is needed to embed different
contents could be converted to whatever this component considered valid by
skipping undesired data before chunk lengths and recomposing new valid ones!
It looks like some developers don't understand the security implications of
their choices.

Cheers,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Apr 2013 16:17:22 +1000

> to the environment and explicitly covered in this intermediary's configuration.

That's what I was wondering. What concerned me was that people deploy load balancers in front of proxies, and virus scanners, etc. I don't have a specific attack in mind, it just feels like there probably is one.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 23 Apr 2013 08:55:25 +0200

On Tue, Apr 23, 2013 at 04:17:22PM +1000, Mark Nottingham wrote:
> That's what I was wondering. What concerned me was that people deploy load
> balancers in front of proxies, and virus scanners, etc. I don't have a
> specific attack in mind, it just feels like there probably is one.

At least in my experience, when deploying a load balancer in front of a proxy
farm or anti-virus farm, parts of the URI are used more than the Host header
field. For example, you can have an LB which decides that requests for file
ending in ".mpg" do not pass through the virus scanner and go directly to the
proxy, but in return the content-type must absolutely match "video/mpeg"
otherwise they're blocked (it's just an example).

That's why I think that the security considerations are much more of a global
thing in such deployments than just a matter of correctly relying on the Host
header field.

Willy

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 24 Apr 2013 01:40:27 +1200

> * Message routing -- it's somewhat common AIUI for intermediaries to only route on the Host header, for performance reasons; i.e., they do not reconstruct the effective request URI (as required by…

CVE-2009-0801 has active naties out there in the wild. At least two than 
I'm personally aware of today. I know that CVE is centered around 
interceptors which you like to avoid mentioning, but regular proxies and 
gateways can be used by an unsafe interceptor and become vulnerable 
themselves as a result. Some of the early attempts at a fix replaced the 
Host with raw-IP from the TCP connection and left the URL with hijacked 
domain name for example.

The take-home risk that should be pointed out is that a malicious client 
can poison the cache of a regular intermediary by presenting conflicting 
Host and URL information unless the intermediary utilizes the 
absolute-URL to protects itself from a mismatch (ie ignore the Host and 
use the absolute-URL given).

Intermediaries that purely do routing are not at risk of this, and if 
the pathway includes a later caching proxy it somewhat self-heals by 
whatever mechanism the cache uses to protect itself on receiving the 
garbage.

If you meant security risks when only routing intermediaries are used. 
I'm not aware of anything current other than the part they play in the 
above and related problems.

Amos

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 24 Apr 2013 01:47:54 +1200

> thing in such deployments than just a matter of correctly relying on the Host

Yes. There are several vulnerabilities which Host enables or enhances. 
But they are problems which the next-hop is best placed to deal with and 
should be protecting itself against regardless of the presence of a 
routing intermediary. Even that unicity issue Willy pointed at is 
something the origin server or a cache is best placed to reject.

Amos