0

When setting up any kind of server application (such as a web server, IRC server, etc) you can usually bind the application to particular IP addresses or hostnames. This tells the application to 'listen' on those addresses.

If I were to bind to an IP address that I do not control, what would be the potential security risks? Of course no requests would ever reach my application, but could there be any other risks or edge-cases?

Regarding binding to a hostname, in some cases this will likely result in a DNS query of the hostname been sent, which would result in potentially malicious DNS record information being returned, as well as the information disclosure/privacy violations, etc. Are there any other risks here?

An example of this situation is when starting a local PHP development server. If I intend to type php -S 127.0.0.1:8080 but I misspell the IP causing PHP to bind to an arbitrary IP that I do not control. This particular risk can be mitigate by using localhost:8080 (which if mistyped would be just invalid) or setting a Bash alias.

Through proper code review and good security practise, this will likely never actually happen. I'm just interested in the theory.

  • 1
    What do you mean by binding to an IP address or hostname that you do not control? Like... one that is not assigned to the machine? Typically this would just mean that no requests would ever reach your application... – nbering Jul 18 '18 at 23:02
  • @nbering Yes that's what I mean. No connections would ever reach my application, but there may be other risks or edge-cases. – jamieweb Jul 18 '18 at 23:17
  • The risk is you waiting forever and nobody ever accessing it. That's it. No packet on Earth will arrive at your service, ever. – ThoriumBR Jul 19 '18 at 1:07
  • 1
    If you try to bind a specific (non-ANY) address that isn't configured on an interface of your machine, POSIX requires it fail with EADDRNOTAVAIL, and although I don't do this often every time I have done so I have gotten the error as specified. – dave_thompson_085 Jul 19 '18 at 2:43
1

If I were to bind to an IP address that I do not control, what would be the potential security risks?

To clarify the comment, this situation can easily happen in a shared hosting type of environment.

The main security risk here is that someone else can easily prevent your service from listening on this IP:port. More, they can run a fake service on the IP:port by taking it over. Then they can possibly act maliciously against your customers, depending on the nature of your service and communications. This can include many things such as:

  • Sending malicious content to your users (if it is a regular Web server which users visit with the browser);
  • Stealing credentials or authentication tokens if your service requires login (either from users or devices);
  • Attacking connecting clients (for example if your client is an IoT sensor submitting data and expecting the "200 ok" status, an attacker can try to overflow the sensor RAM by returning a very long status line);
  • If your service listens on more than one port, an attacker can do MITM attack on it, and perform traffic spoofing/injection/modification (this could be prevented with some measures like SSL, but if you're in shared hosting env, they are less effective).

Note that you cannot bind a listen port to a remote IP, it has to be one of local IP addresses (technically you can, but it will not work, because your ISP will not forward the relevant packets to your IP). So if your example with PHP if you mistype it as "php -S 128.0.0.1" this will only have any effect if your local IP address (or one of) is 128.0.0.1.

PS. The whole 127/8 (i.e. 127...*) is localhost, so if you listen on 127.231.45.90 it is no more accessible remotely than 127.0.0.1.

  • Thanks for your answer. Regarding binding a listen port to a remote IP, what about when there is no NAT, such as on a rented cloud server, etc? In these situations there is no 'internal' address, the remote address is routed all the way through to the machine. – jamieweb Jul 18 '18 at 23:26
  • It is not NAT which prevents this, but the global network routing rules. For example, you can change your local IP address to 8.8.8.8 and listen on it, but you will not receive any packets which go to real 8.8.8.8, because the Internet routers will route this traffic to Google, and not to your server. – George Y. Jul 18 '18 at 23:31
  • To be fair, it is possible to redirect the traffic this way via BGP manipulation - there are articles about it such as theverge.com/2018/4/24/17275982/… - but this requires dedicated effort, and cannot be possibly done by an honest mistake. – George Y. Jul 18 '18 at 23:34
  • Ah I see I have misunderstood there, my bad. :) For some reason I thought you meant that you couldn't bind to non-private addresses (i.e. not 192.168.0.0/16, etc), and I was questioning how any of my server configs work if this is the case! I now realise that by 'remote' IP you mean one that isn't routed to my box. I was thinking that you meant simply any non-private publicly routable address. – jamieweb Jul 18 '18 at 23:40
  • You can even bind to 0.0.0.0 which means "all IP addresses" (but in reality this means "all IP addresses the box offers". – George Y. Jul 19 '18 at 1:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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