Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

security risk posed by traffic originating behind firewalls #23

Open
choksi81 opened this issue May 24, 2014 · 6 comments
Open

security risk posed by traffic originating behind firewalls #23

choksi81 opened this issue May 24, 2014 · 6 comments
Assignees

Comments

@choksi81
Copy link
Contributor

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 choksi81 self-assigned this May 24, 2014
@choksi81
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants