SeattleTestbed / attic

ARCHIVAL: Full mirror of SeattleTestbed's SVN in early 2014. We use GitHub since!
MIT License
0 stars 1 forks source link

security risk posed by traffic originating behind firewalls #585

Open choksi81 opened 10 years ago

choksi81 commented 10 years ago

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).

choksi81 commented 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.

choksi81 commented 10 years ago

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.

choksi81 commented 10 years ago

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

choksi81 commented 10 years ago

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

choksi81 commented 10 years ago

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.

choksi81 commented 10 years ago

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.