Re: [PATCH] host_verify_loose option

sön 2012-01-22 klockan 00:41 +1300 skrev Amos Jeffries:

> It adds a host_verify_loose directive which allows requests which fail
> Host: validation to continue through processing. The default is OFF for
> now to encourage safety. Enabling this does open the clients to some
> minor aspects of same-origin bypass again. BUT ...
>
> * blocks caching on the response to protect all other network clients
> against one compromised client spreading infections.
>
> * forces the original (untrusted) destination IP to be used instead of
> any alternative Squid might find. Preventing Squid or peer DNS lookup
> being the point of vulnerability for the same-origin bypass. For any
> client to be vulnerable it must be vulnerable inside the browser agent
> where the original TCP connection is established.

I would say it should be on by default, or actually the directive should
be named host_verify_strict and off by default.

As you note for a client to be vulnerable with this on the client needs
to be vulnerable when used with direct connection without having it's
connections intercepted by Squid.

Having this Host validation enabled breaks valid traffic, something
which we MUST NOT do in default configuration.

> It also adds a new error template ERR_CONFLICT_HOST to replace the
> confusing invalid request message with a clear explanation of the
> problem and some client workarounds.
>
>
> FUTURE WORK:
> adapt processing to allow these requests to safely be passed to peers.
> adapt caching to permit safe sharing between clients making identical
> requests to same sources.

Short term, add a flag which by default prevents these from being passed
to peers to avoid opening up the original CVE issue when intercepting
and then forwarding to some peers.

Mid term, implement tunneling over peers using CONNECT. Keep in mind
that this requires changes in pconn state to track tunnels separately
from normal peer connections.

Long term, a better forwarding mechanism to allow the peer to see the
traffic proper and avoid the tunnel. Needs to be enabled in cache_peer
or some discovery mechanism added (OPTIONS * ?). Here I still vote for
original IP in requested URL and Host header preserved as discussed
before as it degrades in a safe manner no matter how wrongly things gets
configured.

Regards
Henrik
Received on Sat Jan 21 2012 - 22:35:20 MST