-
Notifications
You must be signed in to change notification settings - Fork 10
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
Comments
Author: justinc 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 |
Author: sjs25 Anyway, I will document various trials I have done here. Testbed: Testbed-opensuse: Tried pinging myself from same loopback IP to same loopback IP, same port: Ping successful |
Author: sjs25 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 same loopback IP and different port: Connection successful |
Author: justinc 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 waitforconn(IP1, Port1, func) where func is a message stating that the connection was successful from IP2. Port1 = 12345 IP1 = '127.12.12.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).
The text was updated successfully, but these errors were encountered: