Is an open TCP port that doesn’t take input secure?

Question

I have written a simple C program (~30 lines) that opens an internet socket and sends data to the client on every connection. The program never read()s from the socket; it just parses the /proc filesystem and write()s the output to the socket, then closes it.

I have almost no defensive programming skills, so we can assume my program is full of bad practices and vulnerabilities.

Is it completely safe to expose the socket to the internet? In other words, are there any known vulnerabilities that could arise from an open TCP port that does not receive anything from the client?

Answer 1

Probably, but mind you that not receiving/parsing data does not make you invincible. Bugs can happen in implementation, and they could be worse than DoS described in CBHacking's answer.

Say your server is designed to handle multiple connections concurrently. If those use shared data (pointers, indexes, allocated buffers, ...) they could be prone to race conditions and potentially be a point where use-after-free, buffer overflow or similar happens.

Even if not a multithreaded server, maybe a global state is tracked which becomes problematic after so and so many connections (buffer overflow, integer overflow resulting in data corruption).

Or even if there's no global data tracked, attacker might be able to provide you with small buffers, so your write/send requests would be split, and there might be bugs/vulnerabilities in how that's handled (seems likely, given that often full size writes succeed, and developers often rely on that).

Of course, the attacker will have limited control over these potential vulnerabilities (number of connections, timings, packets sizes, delays, ...).

Answer 2

There are certainly some ways that such a system could be attacked, although it sounds like in this case it's unlikely that any given attack would matter. A few particular ones, though:

• An attacker might open lots of connections to your server, constantly saturating its connection limit (DoS).
• ... or forcing them to be open as long as possible, consuming system fds/handles and potentially causing DoS.
• ... or trying to open a huge number at once which, depending on how your server is implemented, might cause too many threads/processes (DoS).
• ... or fill up the recv buffer on each, trying to deplete RAM (DoS).

There's also the attacks on the authenticity of the data. You could address that by including a timestamp and digital signature on the data, which clients could then verify using your public key (and their own, hopefully synchronized, clocks).

Realistically, you're almost certainly fine given the scenario as described, though.