Re: [Moderator Action] #144: Attacks from Same Host (OppSec)

It seems like there isn't a lot of interest in adding another mechanism to list the alternatives in the well known file. In particular, there hasn't been any implementer interest expressed.

I'm inclined to send it on to WGLC and see if anything comes up in the SecDir review (etc.) about this.

Closing #144.



> On 15 Mar 2016, at 4:30 AM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
> 
> My biggest issue was that saying Alt-Svc filtering was the answer imposed a new requirement on existing servers that haven't seen the spec. The well-known URI could simply signal that the server is aware of the specification and blocks user generated Alt-Svc headers.
> 
> -----Original Message-----
> From: Kari Hurtta [mailto:hurtta-ietf@elmme-mailer.org] 
> Sent: Sunday, March 13, 2016 10:49 AM
> To: HTTP WG <ietf-http-wg@w3.org>
> Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>; Martin Thomson <martin.thomson@gmail.com>; Mark Nottingham <mnot@mnot.net>; Mike Bishop <Michael.Bishop@microsoft.com>
> Subject: Re: [Moderator Action] #144: Attacks from Same Host (OppSec)
> 
> 
> https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0394.html
> 
> | The only thing remaining then is Kari's suggestion that the 
> | .well-known file also include the alternatives, to mitigate the case 
> | when an attacker has 1) the ability to inject response headers, 2) the 
> | ability to listen on a port on the same host, and 3) doesn't have the 
> | ability to modify .well-known (AKA "shared hosting w/ shell access").
> 
> ( I mentioned this earlier, but not to: HTTP WG <ietf-http-wg@w3.org> )
> 
> Yes, I like that browser can defend against this attack also.
> Mike Bishop described that attack:
> 
> https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0064.html
> 
> | http://users.example.com is a shared server which hosts user home 
> | pages.  Eve places a config file in her wwwpages directory to add an 
> | Alt-Svc header to pages served out of http://users.example.com/~eve 
> | announcing an alternative service for http://users.example.com on port 
> | 23412.  Bob is using an Alt-Svc-capable browser.  After Bob has 
> | visited http://users.example.com/~eve, he visits 
> | http://users.example.com/~alice.  His browser, obeying Eve's Alt-Svc 
> | header, accesses the alternative service on port 23412, where Eve is 
> | running a forward proxy that replaces all pages except her own with 
> | dancing hamsters.
> 
> I also have home page on my hosting provider like  http://home.hosting.provider/~account/
> 
> (where 'account' is user id used on shell access. )
> 
> My hosting provider ssh access (that is how pages are modified.)
> 
> There also seems to have over 5000 other accounts, so there is probably quite many home pages like that.
> 
> These are Apache Per-user web directories https://httpd.apache.org/docs/2.4/howto/public_html.html
> 
> I suspect that shell access is not be as rare than you imagine. At least search for "web host provider with shell access" tells that this feature is provided.
> 
> I do not know if these accounts on these providers share same origin (aka http://home.hosting.provider/~account/ or http://home.hosting.provider/account/).
> 
> 
> This is fine when http://home.hosting.provider/.well-known/http-opportunistic
> does not exists.
> 
> Also I have sites http://account.hosting.provider/, https://account.hosting.provider/ and http://www.elmme-mailer.org/ but these does not share same origin with other accounts on here.
> So on these sites sharing is not a problem.
> 
> And documentation on my hosting provider says that users can run application servers which listen ports between 30000–40000.
> 
> This is allowed but not not recommended – Using of FastCGI or CGI is recommended.
> 
> If hosting provider wants provide Opportunistic Security for HTTP for http://home.hosting.provider/, it needs add
> 
> http://home.hosting.provider/.well-known/http-opportunistic
> 
> with content
> 
> {
> "origins": [ "http://home.hosting.provider/" ] }
> 
> 
> 
> But now any of 5000 users can also run listener on home.hosting.provider and inject
> 
> Alt-Svc: h2=":30000"
> 
> header field on his pages http://home.hosting.provider/~username/ when using CGI.
> 
> home.hosting.provider can defend this with filtering Alt-Svc:
> from UserDir -pages generated with CGI or FastCGI
> 
> Alternatively home.hosting.provider can defend this attack with NOT publishing http://home.hosting.provider/.well-known/http-opportunistic
> but instead using valid certificate (RFC for "HTTP Alternative Services").
> 
> There exists wildcard certificate for *.hosting.provider -name.
> 
> But then home.hosting.provider can not use "commit" either because that requires http://home.hosting.provider/.well-known/http-opportunistic
> 
> 
> But there is little what browser can use to defend against that attack:
> 
> 1) Browser can just ignore Alt-Svc: if there is not valid certificate
> 2) Browser can ignore Alt-Svc: if there is ~ on URL
> 3) Browser can ignore Alt-Svc which gives port > 1023
> 4) Browser can ignore Alt-Svc for all other paths except 
>  '/' , '/.well-known/…' and '*' (OPTIONS)
> 
> But these 2) and 3) does give much guarantee to browser.
> 
> Then browser is just ignoring Alt-Svc: if there is not valid certificate
> so no "Opportunistic Security for HTTP" -support, just support for
> "HTTP Alternative Services". 
> 
> Perhaps option 4) makes sense for browser (i.e. look that 
> /.well-known/http-opportunistic ALSO returns same 
> Alt-Svc: -header field). However this is not actually specified.
> This is effectively also same than that .well-known also 
> lists alternatives. And this does not work if several 
> alternatives are rotated on Alt-Svc: -header field.
> 
> Browser is easier to defend for this attack (and support
> Opportunistic Security for HTTP") if there is
> "alternatives" member in the http-opportunistic 
> well-known resource.
> 
> That "alternatives" member lists valid alternatives which 
> are allowed for given in Alt-Svc: -header filed.
> I do not have suggested exact syntax for this member. 
> 
> Alternatively browser can defend for this attack
> if there is "valid-ports" member in the http-opportunistic 
> well-known resource. This is enough when origin and alternative 
> service’s hostnames are the same.
> 
> 
> This is perhaps over-engineering here:
> 
> Alternatively browser can defend for this attack
> if "origins" member in the http-opportunistic is
> not list of strings but if "origins" is
> a object where member names are origins
> and member values are either list of
> alternatives or list of valid-ports.
> 
> That is: every origin lists which are alternatives
> for it. But I think that this is too complicated:
> 
> HTTP/1.1 200 OK
> Content-Type: application/json
> Connection: close
> 
> {
> "origins": { "http://example.com": [ 88 ],
>              "http://www.example.com:81":  87 ] },
> "commit": 86400
> }
> 
> 
> 
> (( And then it makes sense to move "commit" also 
>  to be per-origin:
> 
> {
> "origins": { "http://example.com": {
>      "valid-ports":  [ 88 ],
>      "commit": 86400 },
>     "http://www.example.com:81": {
>  "valid-ports":  [ 87 ],
>      "commit": 86400 },
>  }
> }
> 
> 
> This is too complex.  So just keep it simple:
> 
> {
> "origins": ["http://example.com", "http://www.example.com:81"],
> "commit": 86400,
> "valid-ports": [ 88, 87 ]
> }
> 
> or "alternatives" instead of "valid-ports".
> 
> ))
> 
> 
> There is no so many different browsers, so I think 
> that makes sense them defend against this attack (if 
> they support "Opportunistic Security for HTTP").
> 
> Getting origins / sites correct is harder, I think.
> It is quite easy to add Alt-Svc: header field
> to some places but harder to filter Alt-Svc: 
> header field from all unwanted outputs. 
> 
> / Kari Hurtta
> 
> 
> 
> 

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

Received on Thursday, 17 March 2016 01:06:01 UTC