What are the concrete security risks of forcibly terminating a process?
I'm using the Gnome System Monitor in Linux Mint. Whenever I attempt to "End" or "Kill" a process, I am given this warning via a modal dialog (emphasis mine):
Killing a process may destroy data, break the session or introduce a security risk. Only unresponsive processes should be killed.
(Similarly with "end" instead of "kill" as appropriate.)
It makes sense that in-memory data could be corrupted (or not written to disk when it ought to be) when a process ends abnormally (not under its own control), and that certain processes might be necessary for the login session to work properly. But what security risks can be introduced this way, and how? (And if a process is indeed unresponsive, do I have options other than killing it or waiting?)
2 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
That sounds like bad design on the developers' part. There are many unavoidable ways a program may be terminated unexpectedly:
- Killed by an OOM killer
- Program crash
- Terminated by virus
- OS crash
- Computer lost power
If these really do introduce a security risk, then it's very bad news for the user because there's not much you can do to prevent them.
Generally, perhaps the program has some clean up to do. For example, may be an encrypted secret gets decrypted and saved on disk when it starts, and the exit procedure deletes the decrypted version. If you forcibly terminate, the deletion will never happen. This is of course an insane design, but that hasn't stopped Gnome in the past...
What security risks can be introduced this way, and how?
Consider the following scenario:
-
A legitimate server listens on some network port. Usually¹ no other process can listen on the port.
-
The server exits. This makes the port available to other processes for listening.
-
Another process (possibly under control of another user) starts listening on the port.
-
New clients connect to the wrong process. This may result in:
- clients leaking sensitive data;
- clients accepting responses from the wrong process and thus
- getting wrong (random or phony) data,
- and/or doing something wrong (being manipulated).
We have several mechanisms to eliminate or to mitigate the risk:
-
Privileged ports (usually up to and including 1023), only root can listen on them. But
- in some cases you want your process to listen on a higher port even as root² (e.g. 8080/TCP is a common choice for a web proxy and caching server);
- if you are a regular user and you want your legitimate process to listen on a port then you need to pick an unprivileged port anyway.
-
Application layer protocols that allow clients to verify the identity of the server (e.g. SSH, HTTPS); but not every protocol is like this.
-
Network namespaces. There are programs that use
localhost:portfor inter-process communication or for exposing their interfaces; running them in a separate network namespace would prevent other users from interfering. But as a regular user you cannot use network namespaces freely and the OS does not crate a private network namespace for you automatically (at least this is how it is in common distros). -
Not letting the legitimate server exit in the first place.
-
Using unix domain sockets instead of network ports for local inter-process communication. A socket can be protected from being hijacked by another user; in particular a named socket can be created in a private directory other users cannot access at all (e.g. the tmux server uses
/tmp/tmux-$UID/defaultby default and the mode of thetmux-$UIDdirectory is 700).
The above scenario is equally risky no matter if you send SIGKILL or SIGTERM, or use some interface to tell the server to exit. From the perspective of the user there are many ways to make a process exit, but if you are a not-necessarily-tech-savvy user and if you want to terminate a process you shall never terminate at your wish (even if technically it belongs to you), like a server designed to run until you log out (when you cannot spawn new local clients) or until the OS starts shutting itself down (when nobody can spawn new local clients or local "impostor" servers), and if the server provides no GUI (because by design you should never interact with it directly), then I guess that Gnome System Monitor (or a similar tool) will be your first choice. In this context it's nice the Monitor tries to warn you.
A different but somewhat similar scenario is if the process you are about to kill announces its presence by creating a pidfile with its PID inside. Forcibly terminating the process will probably leave the pidfile behind, then the PID may be eventually reused, then processes reading the stale pidfile may try to interact with some unrelated program.
In general ending a process (forcibly or not) may introduce a security risk by opening a possibility that some other process (by chance or by a rogue action) takes its place in some context.
If a process is indeed unresponsive, do I have options other than killing it or waiting?
As far as I know - no.
But it's a circular reasoning. If the process could respond to other options, it wouldn't be "indeed unresponsive". :D
¹ There is SO_REUSEPORT, see man 7 socket.
² There is /proc/sys/net/ipv4/ip_unprivileged_port_start; root can use it to extend the range of privileged ports.
0 comment threads
0 comment threads