Agora que temos nosso Jail pronto, vamos nos autenticar como o usuário bandit e ver o que acontece. :-)

# ssh -l bandit 192.168.106.129
bandit@localhost's password:
Linux mephisto 2.6.18-openvz-686 #1 SMP Tue Apr 10 20:28:40 CEST 2007 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Feb 19 16:01:58 2008 from 192.168.106.1
bandit@mephisto:~$

// Até aqui tudo aparentemente normal. É como se tivéssemos logado em qualquer servidor Debian da vida.

bandit@mephisto:~$ id
bash: id: command not found

// Oops o comando id não existe +_+
// Agora percebemos que realmente estamos limitados :D

bandit@mephisto:~$ uname -a
bash: uname: command not found
bandit@mephisto:~$ pwd
/home/bandit
bandit@mephisto:~$ ps
bash: ps: command not found
bandit@mephisto:~$ netstat -ntpl
bash: netstat: command not found
bandit@mephisto:~$

bandit@mephisto:~$ scp
usage: scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file]
           [-l limit] [-o ssh_option] [-P port] [-S program]
           [[user@]host1:]file1 [...] [[user@]host2:]file2

// Temos a disposição apenas o SCP que adicionamos no momento em que criamos a Jail.

bandit@mephisto:~$ cd /
bandit@mephisto:/$ ls -la
total 36
drwxr-xr-x 9 root root 4096 Feb 19 20:51 .
drwxr-xr-x 9 root root 4096 Feb 19 20:51 ..
drwxr-xr-x 2 root root 4096 Feb 19 20:41 bin
drwxr-xr-x 2 root root 4096 Feb 19 21:04 dev
drwxr-xr-x 5 root root 4096 Feb 19 21:01 etc
drwxr-xr-x 3 root root 4096 Feb 19 20:51 home
drwxr-xr-x 3 root root 4096 Feb 19 20:41 lib
drwxr-xr-x 5 root root 4096 Feb 19 20:41 usr
drwxr-xr-x 3 root root 4096 Feb 19 20:41 var
bandit@mephisto:/$

Como podem ver o usuário enxerga somente o Jail e não o nosso sistema real. Ele vive em um ambiente totalmente separado. Isto ajuda muito pois limitado assim ele não consegue acessar o root do sistema nem executar programas nocivos como exploits.

Como podem ver a versão do kernel que estou utilizando é a 2.6.18 com o patch do openvz para virtualização. Esta versão é vulnerável a falha de escalamento de privilégios em kernel na função vmsplice().

E se nosso usuário estiver mal intencionado e tentar exploitar nosso servidor para virar root e assim sair do Chroot()?

bandit@mephisto:~$ ./vmsplice

-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7de8000 .. 0xb7e1a000
Segmentation fault
bandit@mephisto:~$

Segmentation fault... porque ? Porque o sistema não tem acesso as systemcalls que este exploit precisa para executá-lo. Nossa jail então é algo que vai nos deixar bem confortáveis em relação à algumas explorações.

Para deixar frisado este exploit acima é totalmente funcional e ele executado em um sistema comum, faria o atacante ganhar acesso de root.

O ambiente chroot() mostrou que funciona muito bem. Você pode utilizá-lo em larga escala de acordo com suas necessidades e moldá-lo de forma que consiga implantar com sucesso todos os tipos de aplicativos em diferentes Jails.