Raw Sockets API

[ewilligers]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Raw Sockets API
• Specification or proposal URL: https://github.com/WICG/raw-sockets/blob/master/docs/explainer.md
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional): Marcos Cáceres

[martinthomson]

Proposed Response: Harmful

This proposal enables direct TCP and UDP access to services. This creates a way to circumvent protections, in particular the same-origin policy, that have been developed to protect these services.

End-Run Around Protections

The unique ability of a browser to run untrusted code from arbitrary sources is tolerated only because browsers are careful to avoid being used as a platform to attack others. Providing a web site with access to TCP or UDP creates the opportunity to do just that.

In this case, the same-origin policy and the mechanisms like preflight checks in CORS are designed to limit request forgery attacks that a web site might attempt that exploit the privileged location of the browser in the network. Those protections are not perfect, but as they are well established and understood we believe that further responsibility for protecting vulnerable resources over and above that falls on the operator of those services. This proposal circumvents all existing protections. As a new API, the onus for protecting those potentially affected by the change falls on the proponents of the API.

Note that the same-origin policy is the current formalization of an old contract that dates back to early work on cross-site request forgery. This was reaffirmed in the design of WebSockets after research into attacks on middleboxes. This API would trivially enable the attacks cited in these papers.

Mozilla does not believe that any of the proposed protections are adequate. Many of the supplemental protections are either unworkable or inadequate, for reasons explained below. The proposed protections reduce to the one basic protection: user choice. We don’t believe that this is adequate given the level of exposure possible.

The proposal attempts to use the “chooser” model rather than the “permissions” model for consent. That is, the goal is to have the user specify a destination, rather than have the user grant the capability for sites to choose destinations. The chooser model is generally regarded as a far stronger indication of intent, so it is worth considering here. However, there are a few shortcomings that we have identified.

• The choice is opaque and subject to influence. We expect that people will need to rely on sites to provide the name (or IP) of hosts. This diminishes the value provided by the chooser model.

• It is possible, if not likely, that an attacker will control name resolution for a chosen name. This allows them to provide an IP address (or a redirect that uses CNAME or similar) that could enable request forgery.

• Some of the cited use cases, peer-to-peer in particular, depend on connecting to services that are discovered by the application or are dynamically discovered. For a peer-to-peer application that relies on connections to many peers, individually typing IP addresses is at best unwieldy and more likely completely unworkable. These use cases draw into question the idea that is sufficient to draw addresses solely from user input.

That is, we believe that attempts to rely on the chooser model effectively reduce to asking for permission in this case.

Narrower Applicability

After discussing this at some length, we understand more of the motivation for the proposal. In particular, it was suggested that narrowing applicability might allow us to find some conditions where use of the API is acceptable.

For the purposes of this, let’s stipulate that this applies only to services that cannot be updated at all. Services that can be updated can be given the ability to speak web protocols (like HTTP) or provide signals that indicate a willingness to interact with web sites using TCP or UDP.

Enterprise Managed Browsers

A common case for requiring TCP or UDP access is for access to legacy services in enterprise settings. In that environment, if we assume that the browser is managed by the enterprise, it seems reasonable to provide a way for the enterprise to list services that can be contacted using TCP or UDP directly and the sites that are permitted to do so. That provides one path to enabling this sort of capability.

There’s an assumption here that is worth pointing out. Enterprise management is often singular, but the identities involved are not. This sort of configuration likely changes its meaning depending on where the browser is in the network. Put differently, IP addresses used are not guaranteed to be unique, especially “non-public” ones.

Therefore, this assumes that the browser will not be placed into a different network where the same configuration might take on a different, undesirable meaning. For example, an enterprise might allow some sites access to an internal service identified by an IP address, such as a 10.0.0.0/8 or 192.168.0.0/16 address.

If the browser could be moved to another network, such as an employee’s home, then the sites that were granted access can now attack a host with the same IP address. There might be some ways to bind configuration in some way to network identity, but that depends on new network configuration mechanisms that might not be acceptable to people who wish to use TCP or UDP in this way.

This sort of issue is why we think it is important to continue to have these discussions captured in specifications, rather than insist on authorization models being kept proprietary.

BYO

The challenge is when a device lacks an equivalent source of this sort of authorization. For an enterprise example again, this might be a case of a device that is brought in by a visitor or employee that can’t rely on receiving authorization via enterprise management. That is, an unmanaged BYOD scenario. Similarly, this could be for IoT devices in a person’s home.

Absent the service providing signals and some entity that can provide authorization, our only source of authorization information is users. As previously mentioned, we don’t believe that asking for permission is adequate here and we look forward to the development of the new UX paradigms that this will require in order to offer user control.

Limitations of Analysis

The explainer assumes that use of a “non-public” address is a good indicator of a resource needing protection. That is, firewalls only safeguard RFC1918 addresses. This is a failing in CORS-1918 that is acceptable in that context as CORS-1918 only aims to expand protections; that it fails to extend that protection to services on non-public addresses is merely an unfortunate shortcoming. As this proposal is expanding capabilities, this is not sufficient.

It is also worth noting that many of the services that this API targets will operate in private address space. And, with the move to cloud services, it is entirely possible that services hosted in the cloud will need to connect to these services. The prohibition on loopback and link-local addresses is likely the only constraint that can reasonably be applied.

Blocking specific ports, like blocking non-public addresses, is only a partial defense. Many vulnerable services operate on ports other than the default. Separately, it’s not clear what “the destination host supports CORS” means in the context of this.

• UDP access to port 53 (and maybe TCP port 853) could provide sites with access to DNS information that might then be abused. DNS resolvers that operate in split horizon mode could then be queried directly.

• UDP port 67 might be even worse if it weren’t for quirks in DHCP. However, this does suggest that UDP access could be used to circumvent the privacy protections in draft-ietf-rtcweb-mdns-ice-candidates.

The point here isn’t to suggest that this is bad and that these other ports should be blocked as well, but to point out that a more thorough analysis seems likely to reveal many such problems. This indicates that the analysis performed by the proponents is likely inadequate in identifying potential vulnerabilities.

This is likely a case where an explainer is not a good format for making a proposal. Specifics matter, so the level of hand-waving inherent to an explainer isn't helpful. Yes, that is requesting that proponents do more work, but that seems appropriate for something like this.

Other Issues

Others have already commented on the potential for this name to be confused with existing uses of the term “raw sockets”.

Although the process of setting up a socket is unique to this API, the interactions with an established socket follow the same pattern as other APIs. The API should be unified with other, concurrent work in similar APIs. Updates to the WebSocket API (in the WHATWG) and WebTransport (in the W3C) in particular. It appears as though that is happening with WHATWG streams apparently being the basis of the proposal, but we believe this to be worth noting specially.

We will also note that the lack of cryptographic protection - or a framework that might enable the same - for the content of communications is problematic. This is mentioned in passing, but is non-trivial to add.

The proposed unsafe-eval constraint is interesting, but it is an orthogonal consideration. Part of trusting a site with this capability has to include trusting them to protect themselves from unauthenticated inputs. If we believe that users are competent to make this decision to grant the general capability (something I personally do not), then I think that we could very reasonably assume that such a site is capable of also protecting itself adequately.

[ekr]

This analysis more or less matches my interpretation. I would add several more points:

• You cite "Talking to Yourself for Fun and Profit" [HCBR11] and I agree that that is a concern, but that was actually in a weaker threat model in which (1) there was a consent exchange which meant that the attacker had to control the endpoint and (2) the attacker didn't get to control the entire content of the communication. The point of that paper was that even then you have problems and needed to add XOR-masking.. In this scenario there may be even more attacks, including ones where the victim endpoint is separate and ones where the attacker doesn't have to deal with some stereotyped exchange at the beginning of the connection.

• Your analysis focuses on writing data, but it's worth noting that data exfiltration is an issue as well. It's common for companies to run internal web sites which are not access controlled via anything other than the firewall. Ordinarily, same-origin policy would prevent attackers from accessing them and then exfiltrating the data (because the attackers code will run in the wrong origin), but in this case that will not work. There is a whole literature on DNS rebinding, and effectively this would create a situation where you have universal DNS rebinding and none of the existing countermeasures apply. In particular, attackers would be able to (1) synthesize a Host header of their choice, so that Host does not apply and (2) initiate a TLS connection to the server, regardless of the origin, neither of which they can do in the Web context. You suggest (though don't require) blocking HTTPS ports, but one still sees 8080 and the like.

• I would go further than you in saying that domain names clearly are far more unsafe because the attacker controls their resolution. The Explainer is not clear on this point, but what happens when the user authorizes a connection to foo.example.com and grants persistent permission? Does that mean that the page has permanent access to raw sockets for any IP that foo.example.com resolves to? If so, then that completely bypasses the point of entering the domain name because the attacker can just mount a DNS rebinding style attack and initiate connections to any IPs of his choice.

• Even ignoring the specifics of this API, getting users used to the idea that they should be typing uninterpretable technical data into some browser chrome window seems bad. We already worry about social engineering attacks in which users are persuaded to type things into developer tools and this would lower the bar to that.

I would also second Martin's point about an explainer being a bad format for this. What was already known prior to this proposal was:

(1) this would be a useful capability to have
(2) this is also a dangerous capability as documented by the extensive literature on known attacks both in the weaker Web threat model and specifically on this kind of raw socket access

That's why there has been so much prior work and also why nothing has been standardized here in the past.

Thus, the predicate question to whether or not one ought to attempt to develop a specification here is whether we have a new angle on the security question that would lead us to believe that the known problems are soluble. But assessing that would require far more than a sketchy list of problems and potential mitigations. A complete analysis that demonstrates that things have in fact changed should be the focus of any further work here.

[ceisserer]

too bad, this is one of the last items preventing the browser to become a true application plattform

[jaruba]

@ceisserer I'd even dare to say that this is the last item preventing the browser to become a true application platform..

[lemanschik]

this got superseeded by the web-modules standard which does not need your consensus as conses is reached on the ESHost level have a nice day cheers.

[lemanschik]

@jaruba your wrong it is now a app platform

• PR: Incremental refactoring to web-modules #167505 unlicense-code/editor#12

agreement of mozilla not needed.