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?

  • Have you considered what your app leaks of data to the internet?
    – LvB
    Feb 22, 2022 at 22:25
  • What will your server/program do if the client opens a connection to the server on the port that your program listens on, and starts sending packets, even though it is not supposed to?
    – mti2935
    Feb 22, 2022 at 22:26
  • @LvB Yes, I have. It’s just the uptime and state (running, stopped, etc.) of a specific process. I can imagine some situations in which that could be harmful, but this is not one.
    – tjcaul
    Feb 22, 2022 at 23:58
  • @mti2935 My current strategy is to completely ignore the packets. If I understand correctly, they will fill up a buffer, and then the client will be told to stop sending packets. Further packets will be ignored by the operating system.
    – tjcaul
    Feb 23, 2022 at 0:06
  • 1
    @tjcaul actually…. Since the receive is not opened properly…. This does mean you depend on a correct implementation of said buffer. And it could be undefined behaviour…. A discord action might be better.
    – LvB
    Feb 23, 2022 at 11:21

2 Answers 2


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


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.

  • So the open port is a DoS risk, but not an unauthorized access risk? I’m content with that. I will have to consider the authenticity problem, though.
    – tjcaul
    Feb 23, 2022 at 15:41
  • 1
    Not a likely DoS risk either, I was mostly trying to be comprehensive. I suppose if I'm aiming for that I should include the attack surface of the TCP stack too - there have been problems in the distant past with e.g. fragmented packets causing buffer overflows - but realistically, yeah, you're fine already unless you're doing something really expensive with the server, or there's a big risk from tampering/spoofing.
    – CBHacking
    Feb 24, 2022 at 0:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .