Closed Bug 832436 Opened 12 years ago Closed 7 years ago

Do not allow connections to localhost

Categories

(Core :: DOM: Device Interfaces, defect)

Product:
Core
Component:
DOM: Device Interfaces
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INCOMPLETE
Project Flags:
blocking-b2g -
Tracking Flags:
Tracking Status
b2g18 + ---

People

(Reporter: briansmith, Unassigned)

References

Details

(Keywords: sec-vector)

+++ This bug was initially created as a clone of Bug #832000 +++ We do not have any TCP server API (yet), so AFAICT connections to localhost are only useful for doing bad things. For B2G 1.0, at least, we should prohibit loopback connections completely: in XHR, in normal HTTP requests (i.e. no "localhost://" links in content), in the TCP socket API, etc. We can revisit the decision if/when we add APIs that allow well-intentioned apps to do something useful with localhost. I filed this in DOM because my concern is mostly about the TCP socket API (see bug 832000, for example).
So the debugger interface uses a TCP socket for incoming connections?
To clarify, I am proposing here that we block not just localhost (127.0.0.1, ::1), but also that we block all outbound TCP connections to the public IP address(es) of the device.
Jim, is the intra-process communication in bug 797627 going to be over TCP sockets? Should there be an exception for those? I can't find any NSPR APIs for UNIX sockets, FIFOs or pipes.
Don't think we should block on this since the raw socket API is only available to privileged apps. It also may introduce risk of instability for services that rely on local socket communications?
blocking-b2g: tef? → -
Dumb question: do you mean blocking all connections to local ports, or really only blocking outbound app connections to local & public IP ports?
I would have thought the debugger is less of a risk since all connection attempts require user interaction to allow the connection (which could potentially be clickjacked or similar but thats another threat, bug 832000 is probably the best mitigation there). However adb concerns me much more - if adb was enabled (uses the same setting as Remote Debugger) an app with _tcp-socket_ permission could make connections to adb and issue commands. So either we land this fix, or we live with the current mitigation options: - tcp-socket is only available to signed reviewed apps (not a strong mitigation imho) - adb is run with lower privileges than it currently has (not a strong mitigation since it will need to have enough privileges to be useful to an attacker) Thoughts - does this need to be re-evaluated? (As an aside, adb and remote debugger are the only two services that I am aware of that may be an issue here - if people know others, if would be good to be aware of them.)
I certainly hope that adb doesn't allow local connections. We should check that. However, the key here is parity with android, which allows raw tcp sockets for all apps. (Permission-wise, if you're talking adb in current builds, then yes production devices will run it with lower permissions.)
Is this still relevant now we use unix sockets?
Component: DOM: Core & HTML → DOM: Device Interfaces
TCP connections are no longer relevant to the developer tools (including the debugger) on FxOS, since the server listens on a Unix domain socket, access to which is controlled by filesystem permissions. Communication between the parent process and content child processes takes place using the message manager interfaces defined in content/base/public/nsIMessageManager.idl. That communication goes over the same IPDL PContent channel that all the other content child communication goes over. So TCP connection restrictions are not relevant to the developer tools there, either. We *are* using ADB to forward a TCP connection on the workstation to the devtools' Unix domain listening socket on the FxOS device. So the ADB server does need to be running on the FxOS device; however, it doesn't use any TCP sockets there, for devtools.
But it seems like this bug is about which stance FxOS devices should take towards TCP connections overall. I'm only saying that such a policy doesn't have much impact on the developer tools any more.
Bug 797561 enables mozTCPConnection to listen on server sockets now, so we may want to cautiously revisit this bug. From a quick skim of 797561, the main use case seems to be connecting external devices to the phone (e.g. using a web server to allow loading of files onto/off a phone). There may be valid use cases for apps exposing services via tcp sockets to other apps, so maybe we wan't to allow this, but we should make sure we understand the implications first. The last time I checked there were at least a few other local services listening.
I definitely think that you shouldn't be able to use the mozTCPConnection API to either accept incoming connections from localhost, or to create outgoing connections to localhost.
FxOS/Gonk has been removed from the codebase. Mass-invalidating FxOS related Device Interface bugs to clean up the component. If I incorrectly invalidated something, please let me know.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
Bulk correction of resolution of B2G bugs to INCOMPLETE.
Resolution: INVALID → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.