Subject: #73: Alt-Svc Elevation of Privilege

From: Mark Nottingham <[email-masked]>
Date: Mon, 8 Jun 2015 11:46:05 +1000

<https://github.com/httpwg/http-extensions/issues/73>

This issue asks if allowing a header to advertise an alternative on another port (but still on the same host) is adequate, since in some shared hosting environments, users will have the ability to add response headers, as well as listen on other ports.

Erik has suggested in the issue that it might be helpful to limit these to privileged ports — i.e., those lower than 1024. I'm assuming such a restriction would be in place if the origin port were also privileged. 

What do people think?

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

---

From: Patrick McManus <[email-masked]>
Date: Mon, 8 Jun 2015 09:11:39 -0400

its not optimal, but I would consider some kind of CORS mechanism (or more
likely, CORS :)) here as part of the alt-svc establishment.

relatedly I've heard concerns about even cross host with the cert check in
environments with broad alternates - and the feeling that this bypasses the
spirit of CORS. (though I disagree on that count, I do understand it).

On Sun, Jun 7, 2015 at 9:46 PM, Mark Nottingham <[email-masked]> wrote:

> This issue asks if allowing a header to advertise an alternative on
> another port (but still on the same host) is adequate, since in some shared
> hosting environments, users will have the ability to add response headers,
> as well as listen on other ports.
>
> Erik has suggested in the issue that it might be helpful to limit these to
> privileged ports — i.e., those lower than 1024. I'm assuming such a
> restriction would be in place if the origin port were also privileged.
>
> What do people think?
>
> --

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 8 Jun 2015 08:59:08 -0700

FWIW, In the chromium implementation of Alternate-Protocol (and now
Alt-Svc) we require the new port to be < 1024 if the original port was <
1024.

Would CORS incur a latency penalty in these cases? Would we need to wait
for a CORS request to come back before we could use Alt-Svc?

On Mon, Jun 8, 2015 at 6:11 AM, Patrick McManus <[email-masked]>
wrote:

>> Erik has suggested in the issue that it might be helpful to limit these
>> to privileged ports — i.e., those lower than 1024. I'm assuming such a

---

From: Patrick McManus <[email-masked]>
Date: Mon, 8 Jun 2015 13:32:54 -0400

yes, with usual caveat that the delay applies to async bg stuff and not qoe
beyond opportunity cost.. so somewhat less impt.

On Mon, Jun 8, 2015 at 11:59 AM, Ryan Hamilton <[email-masked]> wrote:

>> its not optimal, but I would consider some kind of CORS mechanism (or
>> more likely, CORS :)) here as part of the alt-svc establishment.
>>
>> relatedly I've heard concerns about even cross host with the cert check
>> in environments with broad alternates - and the feeling that this bypasses
>> the spirit of CORS. (though I disagree on that count, I do understand it).
>>
>>
>>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Jun 2015 10:52:16 -0700

I think that this is something that can be addressed by applying CORS,
or its model.  The point of CORS is to determine that a request target
is willing to accept the request (and in this situation, the attacker
is the one answering that question).

I think that the <1024 solution is hacky as hell, but better than
anything I can think of.

My alternatives:

. Require an HTTP/2 stack to strip Alt-Svc on the way out, unless it
is specially authorized.  That's predicated on h2 implementers seeing
this advice and it might already be too late for that.

. Insist on the header field being proposed by resources under /.well-known/.

The frame is superior in this sense; hosted resources won't be able to
insert those without authorization.

The /.well-known/ option might work as a means of breaking out of the
1024-port block.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 9 Jun 2015 10:51:10 +1000

On 8 Jun 2015, at 11:11 pm, Patrick McManus <[email-masked]> wrote:
> 
> its not optimal, but I would consider some kind of CORS mechanism (or more likely, CORS :)) here as part of the alt-svc establishment.
> 
> relatedly I've heard concerns about even cross host with the cert check in environments with broad alternates - and the feeling that this bypasses the spirit of CORS. (though I disagree on that count, I do understand it).

I don't see how a CORS-like mechanism would help *this* concern, which is that a local attacker with the ability to add HTTP response headers and listen on another port could hijack a server; if they're listening to the other port, the certainly can do the CORS dance.

It *would* help against an attack whereby someone can inject HTTP response headers, and they want to attack a service that they don't control. I think there are two variants of this:

a) The other port isn't speaking HTTP; i.e., we're doing a cross-protocol attack against something like SMTP. If we disallow h1 in this situation, I *suspect* this is a manageable concern — although I wouldn't be completely surprised if someone found an implementation of some protocol somewhere that was so forgiving that one could shove carefully-crafted H2 into it and get it to do something. If we aren't comfortable allowing this (even though it's same-host only), a potential remedy would be to establish a well-known port (or two) for cases when 80 and/or 443 get an alternative to the same host, instead of adding latency with a CORS-like dance.

b) the other port is speaking HTTP. If we disallow h1 in this situation, the implementation we're talking to would have to ignore the strong warnings in h2 to check the origin for every request, and would be vulnerable not only here but also to other attacks, presumably.

The common thread here is "don't use h1 with alternatives" — which is where we're already at. Am I missing something?

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Jun 2015 20:54:26 -0700

On 8 June 2015 at 17:51, Mark Nottingham <[email-masked]> wrote:
> It *would* help against an attack whereby someone can inject HTTP response headers, and they want to attack a service that they don't control.

This is already something we consider either a) safe, or b) a lost
cause.  Cross protocol attacks using HTTP are already trivially
mounted for requests that only use safe methods and header fields,
such as form submissions.  I believe that the assumption is that HTTP
is well-enough known and unlikely to create a sequence of packets that
would cause bad things to happen.

However, this potentially increases that surface area by allowing
same-origin requests, with the additional control that implies.  I'm
not especially concerned by that though: and I'm not concerned about
h1 as much as I am with unsecured protocols.  ALPN in TLS provides a
pretty strong assurance that the server knows what it is doing.
Unsecured HTTP/1.1 might be exploitable if you have a particularly
stupid service...maybe.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 16 Jun 2015 10:53:03 +1000

So, I think we're back to the suggestion that we require an alternative to be on a privileged port if the origin is on a privileged port.

Thoughts?

> On 9 Jun 2015, at 1:54 pm, Martin Thomson <[email-masked]> wrote:
>

---

From: Mike Bishop <[email-masked]>
Date: Tue, 16 Jun 2015 17:55:39 +0000

Is there a formal definition of privileged ports in an RFC already, or would we be codifying tradition here?

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: Monday, June 15, 2015 5:53 PM
To: Martin Thomson; Mike Bishop
Cc: Patrick McManus; HTTP Working Group
Subject: Re: #73: Alt-Svc Elevation of Privilege

Thoughts?

---

From: Erik Nygren <[email-masked]>
Date: Tue, 16 Jun 2015 16:28:49 -0400

The Systems Ports range of 0-1023 is defined in rfc6335, although the
purpose there is not well-defined.

     Erik

On Tue, Jun 16, 2015 at 1:55 PM, Mike Bishop <[email-masked]>
wrote:

> So, I think we're back to the suggestion that we require an alternative to
> be on a privileged port if the origin is on a privileged port.
>
> Thoughts?
>
>
> >> It *would* help against an attack whereby someone can inject HTTP
> response headers, and they want to attack a service that they don't control.
> >

---

From: Martin Thomson <[email-masked]>
Date: Tue, 16 Jun 2015 13:38:12 -0700

> purpose there is not well-defined.

I'm sure that we can give it some purpose.