How to deal with a kite process?

Navigation
15

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 with each iteration the process will create a child clone and kill itself next. For all intents and purposes, this is the equivalent of exchanging your own ID. Then I use setpgid to open a new group of processes including only the current process , without the original process before the clone. So with 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, since kill needs a process ID or a group ID and the time it takes to identify the ID of the group and send a kill will be enough time for it to change.

  • Why is this process not listed?
    When I run ps -A | grep teste (assuming my executable is called teste ), sometimes the process does not appear. It makes no sense to me. I understand that in some moments there is a process with the same name (the clone and the relative that has not yet killed himself), and that most of the time there is only one. But zero does not make sense. He is at no time dead. If I repeat the command a considerable number of times the process is listed in some. Why?

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

  • Does this structure represent a flaw in API design?
    What I see here is an API that allows the process ID to float and at the same time depend on it being stable as the only way to kill a process. Would not that be a flaw in the original design? Could it be considered a security breach until?

asked by anonymous 31.01.2014 / 15:54

4 answers

7

Use the SIGSTOP sign.

Signals manual is available at: 

man 7 signals

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

killall -SIGSTOP cmd

Then kill the processes: 

killall -SIGKILL cmd

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

So, you have to reduce the limit of processes that the user can create, by means of ulimit -u , so the kernel will prevent you from doing fork() .

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

One of the ways to get around this is, before you lower the limit, create another user with uid equal to 0, and use that user to kill the process.

    
31.01.2014 / 16:19
5

Surely the guy who fired this process is evil, so without mercy for him: 

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

If you do not know the user, or are afraid to do so, look at the users who are logged on to 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 the login time, CPU consumption, and connection method in the scan. Once you have done this, you will have criteria to send the comet process back into space!

    
26.09.2014 / 14:36
1

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

But this condition will not happen 100% of the time, eventually it will be able to catch this comet by the tail, just keep repeating the action until it is successful.

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

nice -n -20 killall -9 nome_do_processo
    
31.01.2014 / 16:54
0

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

    
31.01.2014 / 16:00
How to find out the mobile operator of Android? Assigning value to a dictionary variable that is optional