Does Hole Punching put added Vulnerability on the Client Side

Question

Websites and servers frequently get hacked when a vulnerability is present in the server side code. Does UDP or TCP hole punching put that risk onto the users of the application when the connections become peer to peer?

Take for example the clearly vulnerable practice of execing an unsanitized input. Obviously this practice would not be done by design, but this kind of thing happens far too often by mistake. In a traditional setup, if user_a interacts with user_b we would first have user_a send input to the server, the server would process the data, and then send something to user_b. With hole punching, we get a peer to peer between the two users and so user_a sends data to user_b, and user_b processes it for himself. If a vulnerability was present in how the input was processed by the server (in this case execing it without sanitizing), the vulnerability could just as easily be present on the client side, allowing user_a to inject and directly run code on user_b's machine.

If a severe vulnerability were to be found in a hole punching application (Skype and other VoIP services, some multiplayer realtime games, et al), is there anything stopping a malicious hacker from having a direct backdoor into the system of any user they interact with? If not, are peer to peer programs unnecessarily risky? Is there a catch-all way to mitigate this risk for people creating these application? And what about people who use these applications? Do programs like Skype leave users at an undue level of risk (more so than typical)?

Answer 1

The question depends heavily on the software security architecture used but yes there have been cases where the peer to peer software implementation did allow bad actors to access files on the hard-drives of other people participating in the peer to peer network. Likewise some of these designs also allow participants, or ISP's, to identify the files other users are sharing remotely.

This said it doesn't mean these applications are necessarily unsafe some could be very safe but any time you add an application which listens to the Internet (or other systems) you are increasing the attack surface of the computer. This risk is not unique to peer to peer software but peer to peer software is more likely to have listening ports.

Again it really depends on the security models used more than anything.

In general all of the security issues with securing a non peer to peer protocols will apply to peer to peer protocols as well. This just happens to be a many to many set of connections rather than one to one or one to many.

Again, they could be really secure but every implementation will be very different.

Answer 2

Consider threat modeling of the different scenarios, and drawing reasonable trust boundaries. I see the client server model this way:

client-1 | server | client-2

and the hole punching view would look like this:

client-1 | server
client-2 | server
client-1 | client-2

In both cases, neither client-1 nor client-2 should implicitly trust the data that arrives from an external source, so the client code is responsible for validating the input.

Another way to look at it is if an attacker was able to inject a MITM into your connection, regardless of whether it came from a server or client, should you trust that data?

Peer-to-peer increases the ease of an attack by increasing the number of potential hostile vectors. It also forces the client to open a listening port to communicate (even if it's only opened temporarily), instead of the client always originating the connection to the server. These both increase the attack surface. Because of these increases, the client is at an elevated risk of falling prey to a 0day vulnerability.

But the risk posed by a vulnerable client doesn't change: regardless of entry method, the attacker breaches the client and causes damage. The client still needs to be secured the same regardless of the connection method.