Inspired by this question I came up with this weird idea of making what that user actually wants to prevent. So, bear with me for a little bit:

Let's assume that for some reason we could make the traffic sent from a specific application to another to travel to a router/routing device because the source device cannot determine on its own where does it have to send the packet. This means, even names like "localhost" or IPs like does not work for this source device, but it rather has to send everything to another device to send the information its "destination" device (which, we know, it's that same server).

So, simplifying and making it an actual question: is there any way, remotely as it could be, to hijack routing tables/loopback interfaces/whatever it takes to make a machine send it's traffic out when those communications are supposed to be internal?

Think in how many web server do have their databases in there and send "internal" requests for connection with data... TCP services... and how firewalls are configured to block weird traffic in but not so much for traffic out. This made me tick and come and ask this weird question.

4 Answers 4


There are lots of speculations, let's try it.

Assigning to the network interface

On Debian it works as root to assign to the network interface:

# ifconfig lo netmask
# ifconfig eth0 netmask

and results in:

lo        Link encap:Lokale Schleife  
          inet Adresse:  Maske:
eth0      Link encap:Ethernet  Hardware Adresse 
          inet Adresse:  Bcast:  Maske:

ping, however, fails with an Illegal Argument error:

 $ ping
 PING ( 56(84) bytes of data.
 64 bytes from icmp_seq=1 ttl=64 time=0.030 ms

 $ ping
 connect: Invalid argument

So this is something that needs to be look at in more detail by analyzing the source code.

Pointing "localhost" to another ip-address

Editing /etc/hosts as root so that it points localhost to another ip-address works:

ping localhost
PING localhost ( 56(84) bytes of data.
64 bytes from localhost ( icmp_seq=2 ttl=57 time=165 ms

Whether this is an issue or not depends on the situation: The client may send a password without validating the server by either not using ssl or trusting any certificate (There are testing-certificates for localhost out there that are signed by trusted CAs). This password might be reused elsewhere or the server may accepting connections from other interfaces because it is password protected anyway.

In the standard configuration the host file has precedence over NIS and DNS, which requires local root access and makes this kind of attack pointless. But if the priority was changed, this is exploitable using the DNS or NIS servers.


I believe you would need to compromise the kernel to do this (of course, if you can compromise the kernel, you can do anything). I just did some testing with IPTables and it appears that loopback traffic bypasses the NAT / PREROUTING capabilities, so I think it's out of userspace control (in Linux). OSes will vary, of course, but I think in general you do need to compromise the kernel to do what you want to do.

  • No need to compromise the kernel, write access to /etc/hosts is enough.
    – tdammers
    Aug 19, 2011 at 21:19
  • Cool! How do I map to with /etc/hosts? Oh, wait, I can't. I think the question as asked is somewhat wider than something as simplistic as poisoning name resolution.
    – gowenfawr
    Aug 19, 2011 at 21:54
  • nat and PREROUTING is only used for routing, this means traffic from the local machine to the local machine isn never filtered there. try the mangle table to intercept local packets.
    – allo
    Apr 19, 2018 at 11:21

It's an assumption, but I would think that most networking stacks in OS's would bypass the external interfaces in localhost requests. Certainly for security reasons, but moreso for performance reasons.

  • This is incorrect. For the OS, the loopback interface is a virtual interface called lo. The localhost host and the address are not handled in any special way by the kernel. Only the loopback interface itself is. Typically, localhost is made to resolve to which in turn is assigned to the kernel-managed loopback interface.
    – forest
    Mar 7, 2018 at 11:13

In no way unless having some serious mistake in the networking code which can be triggered remotely but this bug as well can make the host unable to intercommunicate at all → Low probability for success. Moreover, it's too complicated comparing to another types of attacks, so it's nearly not realistic.

  • 1
    The problem is that 'too complicated' has been proven to not put off attackers, in fact it encourages some groups. No matter how many times you'd expect attackers to go for low hanging fruit, some will research the weirdest routes, so the only logical advice is to at least review them, no matter how complicated.
    – Rory Alsop
    Sep 2, 2011 at 9:30
  • That's not a problem since not labeling "too complicated" puts off but "complexity" instead.
    – poige
    Sep 2, 2011 at 14:44

You must log in to answer this question.

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