How to deal with a comet process?

Question

Analyzing the linux API I noticed that an interesting structure is possible:

#include <unistd.h>
#include <stdlib.h>

int main()
{
    while (1)
    {
        if (fork()) exit(0); // Altera meu pid
        setpgid(0, 0); // Cria um novo grupo de processos, o atual sendo o único membro

        // Agora executar alguma operação "maligna":
        usleep(1000);
    }
}

What happens here is that every iteration the process will create a clone child and then kill itself. For all intents and purposes, this is the equivalent of changing your own ID. Then I use the setpgid to open a new group of processes including only the current process, without the original process before the clone. So at each iteration the group ID is also changed. Then I run a short operation and change my Ids again.

This type of process is known as comet process by system administrators.

The problem is that it is very difficult to kill a process like this, because the kill needs a process ID or a group ID and the time it takes for me to identify its ID and send a Kill, will be enough time for it to change.

• Why this process does not appear listed?
  When I execute ps -A | grep teste (assuming my executable is called teste), sometimes the process doesn’t show up. That doesn’t make sense to me. I understand that some moments there are 2 processes with the same name (the clone and the relative who has not yet killed himself), and that most of the time there is only one. But zero doesn’t make sense. He’s not dead at any point. If I repeat the command a considerable number of times the process is listed in some. Why?

• How to kill this process?
  Although I can list and get his ID (after many attempts) the time it takes to call kill is enough for him to clone himself and commit suicide. I can try with the killall teste, but the command fails on almost every call. How to effectively kill it?

• The fact that this structure is possible represents a flaw in the API design?
  What I see here is an API that allows the process ID to fluctuate and at the same time depend on it being stable as the only way to kill a process. Wouldn’t that be a flaw in the original design? It could be considered a security flaw until?

Answer 1

Use the sign SIGSTOP.

The signals manual is available (in English) at:

man 7 signals

I send the signal SIGSTOP for all processes with that same name using the command

killall -SIGSTOP cmd

then kill the processes:

killall -SIGKILL cmd

However, it is possible that the killall cannot send the signal in time, so that a race condition will be established.

Therefore, it is necessary to decrease the limit of processes that that user can create, through the ulimit -u, thus, the kernel will prevent you from doing fork().

However, once reached, this limit will also prevent you from using the killall.

One of the ways to circumvent this is, before lowering the limit, create another user with uid equal to 0, and use this user to kill the process.

Answer 2

Surely the guy who fired this lawsuit is from the bad guy, so no mercy to him:

# su - <maligno>
$ kill -9 -1

If you don’t know the user, or are afraid to do so, analyze the users who are connected on the machine first

# w
 09:22:33 up 24 days, 22:01,  5 users,  load average: 0.18, 0.18, 0.17
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
usuario  :0       -                01Sep14 ?xdm?   8:56m  0.10s /bin/sh /usr/bin/startkde
usuario  pts/1    :0               01Sep14 24days  0.00s  4:10  kded --new-startup
usuario  pts/3    :0               08:46    0.00s  0.15s  0.08s /bin/bash
usuario  pts/5    :0               08:55    1:08   0.26s  0.13s /bin/bash
maligno  pts/8    cometa           09:21    1:08   0.08s  0.08s -sh

consider login time, CPU consumption and connection method in the analysis. Once this is done, you will have the criteria to send the comet process back into space!

Answer 3

I think using the killall would be the only solution that does not involve tampering with the system kernel. But as you said yourself it can curl since the constant creation and elimination of processes can happen asynchronously and in parallel.

But this condition won’t happen 100% of the time, eventually he’ll be able to catch this comet by the tail, just keep repeating the action until it succeeds.

The trick you can use to increase your chances is the nice, which will increase the priority of implementing killall making it have a bigger action window than the target program.

nice -n -20 killall -9 nome_do_processo

Answer 4

The process group ID (PGID) does not change when it does Fork. You can kill (or send a SIGSTOP) by sending a signal to the process group -- do kill + plus PGID instead of PID.