27

Let's say we're running a service that's bound to localhost (127.0.0.1), and the goal is to only allow local clients (i.e. from the same machine only)

What techniques might be used to break this security, are there additional measures that could be used to enforce it?

Improve this question
5
  • 1
    Apparently computers in the local network can spoof the IPv6 equivalent ::1 on some operating systems.
    – CodesInChaos
    Apr 24, 2015 at 14:24
  • 6
    @CodesInChaos could you clarify and possibly provide a link for that ?
    – user42178
    Apr 24, 2015 at 16:37
  • @CodesInChaos Without information about which OS and version, then that isn't a verifiable statement.
    – kasperd
    Apr 25, 2015 at 8:34
  • 1
    Bear in mind that anyone with local access to the machine will be able to port forward. The obvious culprit is ssh which has portforwarding built in, but it's pretty trivial to do in other ways. If all your users with access are trusted, this isn't an issue.
    – Sobrique
    Apr 25, 2015 at 11:28
  • 3
    Project Zero - Finding and exploiting ntpd vulnerabilities wrote "Any IP packet arriving on an external interface and with the source IP 127.0.0.1 will be dropped immediately. But if we use IPv6 instead we can actually spoof ::1 and send control mode packets to the daemon (some Linux distributions have firewall rules in place that protect against this, e.g. Red Hat). Thus, if we are on the same local network, we can send spoofed packets to the link-local address of the target"
    – CodesInChaos
    Apr 25, 2015 at 12:36

5 Answers 5

Reset to default
20

The first and main thing is to ensure that the firewall on your host is configured to properly drop incoming packets with source or destination address set to 127.0.0.1.

Under normal circumstances, there should be no packet coming from the network and showing such addresses. However an attacker may attempt to forge such packets in order to reach your local listening services.

I do not know which kind of other services are listening on your machine, but if any service can be used as a relay you must ensure it is properly configured to prevent to relay anything to the local listening services.

For instance, if you have an HTTP proxy running on this host, an attacker can use this proxy to request the host "127.0.0.1": from the firewall perspective this will be a legit connection coming from the network to the proxy service, and locally this will be a legit communication between two local services (the proxy and the targeted local port). The HTTP proxy here is just an example, such technique may also work with other services, including services where relaying connections is not the main functionality (the FTP bounce attack for instance is a classical example of such threat).

Improve this answer
11

A potential vulnerability would be to compromise a low-privilege account/service and use that as a pivot to access the localhost-bound service.

I usually prefer UNIX sockets for that purpose as you can apply user/group permissions on them (that will be transparently handled by the OS, the user won't have to keep yet another password). Plus, they're also a bit faster which makes them preferable for IPC on the same machine.

Note that socket permissions aren't always respected on some UNIX variants and OS-specific tuning may be needed (like increasing the number of allowed connections per socket).

Improve this answer
6
  • 1
    Unix sockets comes with their own issues. Beware that the Unix rights on socket files is not universally respected: on some systems they are not checked at all, in case of doubt use parent directory's rights instead. Moreover, under high load (hundreds of connections), using a socket file may cause performance issue and need specific OS tuning (increase the number of allowed connections per socket) while using standard TCP socket on local interface would not cause any trouble.
    – WhiteWinterWolf
    Apr 24, 2015 at 11:12
  • @GZBK I'll update my answer, though I have yet to encounter such issues.
    – user42178
    Apr 24, 2015 at 11:16
  • The first paragraph is key. On Linux you can mitigate that with iptables rules that inspect the uid of the process from which the packet originated and drop local ip packets from users who should not be able to connect. (This ability is also useful for preventing compromise of low-privilege accounts from allowing the attacker to use your host as a spam relay.)
    – R.. GitHub STOP HELPING ICE
    Apr 24, 2015 at 15:37
  • @AndréDaniel: Not if you're reusing existing code/services already implemented on TCP without a unix socket transport. In that case the iptables approach is quite practical.
    – R.. GitHub STOP HELPING ICE
    Apr 24, 2015 at 17:10
  • The question here was mainly about how to reach remotely processes listening on local interfaces. Using Unix sockets for this is indeed a good workaround. Regarding local processes isolation, Jails / Containers attached to local interface aliases and with communication restrained by the host firewall is also quite powerfull. For @AndréDaniel, I mainly encountered the socket limitation issue when dealing with nginx + php-fpm, as documented here for instance.
    – WhiteWinterWolf
    Apr 24, 2015 at 18:34
8

If the service provides a web interface it might be vulnerable to CSRF attacks, XSS attacks or "same site" scripting. All of these can be triggered by just visiting the attackers external website, which by itself might be caused by malvertising or phishing. For these attacks it does not matter if the service is listening only on localhost, because it is only needed that the host is reachable by the local web browser. The same problems exist with attacking intranet hosts from outside.

Improve this answer
3
  • So in this attack scenario an authorized person is browsing the web with a browser running on the server?
    – Rick
    Apr 7, 2021 at 12:16
  • @Rick: Correct. The whole question is about running a server and client on the same machine.
    – Steffen Ullrich
    Apr 7, 2021 at 13:26
  • Yep, it makes sense now. I just was just thrown off since I was looking at raw TCP connection security for non-web related things. But, the server also happens to have an external facing web interface. But, in this case the browser is on a client PC so your scenario doesn't apply.
    – Rick
    Apr 7, 2021 at 13:41
1

Also consider that the hostname localhost is not exactly the same as the IP 127.0.0.1 (it naturally needs to be resolved first), and in most situations relies on either an entry in the hosts file or a resolver/dns server capable of resolving 127.0.0.1. So, be sure you can strictly specify 127.0.0.1 instead of localhost when implementing security measures, otherwise you will need to step back and also consider security issues in the resolver.

Improve this answer
1

The answer depends on different factors. A few that may or may not apply:

  • What protocol is it? (For example UDP is more prone to security issues in this case as it works statelessly and you might achieve something with a single spoofed packet).
  • Do you consider attacks or only data access. (See above: you might be able to do a DoS attack for a faulty UDP service with a single packet, but won't achieve data flow).
  • Do you have remote access on user level (by design or as a security issue itself)? (For example, a user may set up an SSH tunnel.)
  • Do you have remote root access (by design or as a security issue itself)? (One could set up a NAT to redirect public IP traffic to 127.0.0.1)
  • Do you have firewall, ingress filtering set up properly?
  • Do you have other network services open on non-localhost that can be "tricked" to access the localhost-only service on your behalf?
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .