3

Google is reportedly planning to make Chrome report all web site connecting using http:// as unsafe.

But is this really true if the host in question is localhost and the server is only listening for connections from the local machine? For instance, if there is a server running on the local machine and I navigate to http://localhost:8080 is there anything insecure about that? As far as I know, this resolves to 127.0.0.1 which is inaccessible outside the local machine. I think it should never be possible for localhost to resolve to 127.0.0.1 or that 127.0.0.1 doesn't refer to the local machine.

All communications should be going through a channel that can't be seen from another processes other than the server process on the machine and the client process which is the web browser. So sending things like passwords, session keys, etc. across the channel should be secure, right?

I'm aware of security risks which might be caused by allowing localhost access, and how these might be protected against. What other risks are there?

  • One of the risks is a DNS rebinding attack. – Arminius Jan 4 '17 at 0:29
  • A compromised host file can point the localhost requests anywhere. SSL could help mitigate this risk. – BZN_DBer Jan 4 '17 at 2:48
  • @BZN_DBer If the attacker can compromise arbitrary host files, why wouldn't he also add authorized certificates? – curiousguy Jun 22 '18 at 18:51
6

Sort of.

Loopback traffic does not reach a physical network interface. It is routed through the virtual loopback interface, so it never leaves the machine.

Administrative applications (so that includes administrative users) and the system's high-privilege processes will be able to sniff the loopback interface, at least on Windows, OS X, and Linux. In some configurations, non-root processes may be able to access pcap and sniff loopback. In modern pcap installation config scripts it asks whether you would like to restrict pcap access to root-only, which prevents this issue.

TCP network sockets are not limited to particular users, so on multi-user systems a listening TCP socket will be accessible by all users on that system. Additionally, a process which runs before yours has chance to start may launch its own listening server on that port, and accept requests from the client. Whether or not that's a vulnerability depends on your use-case and threat model.

|improve this answer|||||
  • on multi-user systems a listening TCP socket will be accessible by all users on that system Can you expand on this? Do you mean other processes can essentially read/write the server's open socket, either snooping on it or diverting request or reply packets? – Michael Jan 3 '17 at 23:37
  • 1
    @Michael Non-privileged processes can create their own connections to the server, not sniff existing connections (unless pcap is installed and configure to allow non-root loopback sniffing). – Polynomial Jan 4 '17 at 0:31
  • Ah ok... so not really a threat if the user still has to provide some credentials – Michael Jan 4 '17 at 1:38
  • @Michael Files (incl. directories) have owners in -nix systems, TCP ports don't. So a port is available to anyone and a "reserved" port is available to any process with either UID 0 or some "capability". Either way, it's a first arrived first served (a bad system). – curiousguy Jun 22 '18 at 19:24

Not the answer you're looking for? Browse other questions tagged or ask your own question.