Open choksi81 opened 10 years ago
Author: justinc This is really a "per community" issue. Some users (like PL nodes and many home users) won't care about this. We need to have the ability to solve this problem, but don't need to force every user / community of users to accept the solution.
In other words, it would be nice to have the ability to limit traffic in this way, but it's not essential for many users.
Author: justinc Steve is looking at using an address other than 127.0.0.1. If we can use a different loopback address, this should help to remove this as an attack vector.
Author: sjs25 Sorry it took so long to get any documentation out on this.
Anyway, I will document various trials I have done here. Note: when I say "loopback IP", I mean something other than 127.0.0.1
Testbed:
Testbed-opensuse:
Tried pinging myself from same loopback IP to same loopback IP, same port: Ping successful Tried pinging myself from localhost to localhost, same port: Ping successful Tried pinging myself from different loopback IPs, same port: Ping failed Tried pinging myself from loopback IP to localhost, same port: Ping failed Tried pinging myself from localhost to loopback IP, same port: Ping failed
Author: sjs25 The above test used sendmess and recvmess. I'm not sure if I did something wrong with it, but here are the results when I used waitforconn and openconn on different processes (waitforconn waits for connection at x localhost and port, openconn makes a connection to x localhost and port from y localhost and port).
I will figure out what I did wrong with recvmess and sendmess later because it should still work.
From same loopback IP and port: Connection failed From localhost to localhost and same port: Connection failed From differnt loopback IPs but same port: Connection successful From localhost to loopback, same port: Connection successful From loopback to localhost, same port: Connection successful
From same loopback IP and different port: Connection successful From localhost and different port: Connection successful From differnt loopback IPs but different port: Connection successful From localhost to loopback, different port: Connection successful From loopback to localhost, different port: Connection successful
Author: justinc I'm a bit confused by the data you present. What does 'from same loopback IP and port' mean? What about the other entries?
I assume that in all cases you have the following (I'll use the UDP calls, but TCP is similar):
recvmess(IP1, port1, func)
sendmess(IP1, port1, message, IP2, port2)
I think that the only really important data in these calls are the values of IP1 and IP2. So, can you restate what you found using this as a reference point? Be sure to clearly state what you used for IP1 and IP2 in your examples. Also, port1 and port2 should be different numbers that are > 1024 and < 65535.
Author: sjs25 Half of my tests were made invalid by the requirement that the ports must be different. Here are the valid ones restated:
waitforconn(IP1, Port1, func) openconn(IP1, Port1, IP2, Port2, 5(timeout))
where func is a message stating that the connection was successful from IP2.
Port1 = 12345 Port2 = 12346
IP1 = '127.12.12.1' IP2 = '127.12.12.1': Connection Successful IP1 = '127.0.0.1' IP2 = '127.0.0.1': Connection successful IP1 = '127.12.12.1' IP2 = '127.14.14.1': Connection successful IP1 = '127.12.12.1' IP2 = '127.0.0.1': Connection successful IP1 = '127.0.0.1' IP2 = '127.12.12.1': Connection successful
Note, that my func states the IP2, not IP1, meaning that it knows which loopback IP I used.
As we allow initiating tcp/udp communication through the loopback interface, we open up some important security risks. Everything on a system that talks tcp/udp which was previously externally inaccessible due to firewalls is potentially subject to malicious traffic when running our software. There are quite a few very serious exploits that can be imagined.
The issue is more generally that the user running our software now has a source of arbitrary traffic that originates behind their firewalls, including any network border firewalls. The localhost example is just an easy one to use to convey the idea.
A good solution would be to restrict sending data to only ports 63100-63180 when the destination is the loopback or an RFC 1918 address (private network address).