Linux Kernel Security & Hardening Thomas Lamprecht January 17, 2019
Introduction
The Linux Kernel ◮ Widespread ◮ Deployed on: ◮ powerful (high performance compute clusters) ◮ sensitive (bank, gov. systems, ..) ◮ safety critical (Rocket Engine Control System[1], Automotive) ... Systems ◮ → thus: attractive target
Security Beyond Bugs ◮ Performance & Reliability � = Security ◮ Hardening seen as overhead in the past ◮ Critical security bug lifetime is huge ( > 10 years possible) ◮ Non-trivial software/hardware → never bug free ◮ Safety net needed (Kernel Self Protection (KSP) [2]) “Security needs to be more than just access control and attack-surface reduction.” — Kees Cook, 2015 Kernel Summit
Security For Others Wrongdoing ◮ Working around hardware vulnerabilities ◮ Side channel attacks (Meltdown[3], Spectre [4] ) ◮ Firmware/ µ Code bugs ◮ User space programs
Kernel Self Protection vs. User Land Protection Attack surface reduction: ◮ SELinux/AppArmor ◮ seccomp ◮ namespacing (mount, PID, net, ...) Problems: ◮ Usability ◮ Complexity ◮ no protection against common Kernel bugs
Out of Tree Security ◮ Earlier Hardening resentment → out-of-tree approaches [5] ◮ PaX/grsecurity ◮ Lots of Linux Security Research happened until they went private ◮ Low effort to upstream ◮ But, work now taken up by the community
Flaws & Mitigation Technologies
Stack Overflow Attack: ◮ Overwrite saved instruction pointer → execution control Mitigations: ◮ Stack canaries [6] [7] ◮ Guard Pages [6] ◮ KASLR [8] [9] ◮ Shadow Stacks ◮ Virtually mapped kernel stacks [10]
Integer/Heap overflow Caused by: ◮ Integer overflow/Wrong Bound checking ◮ Overwrite adjacent kernel function pointer ◮ refcount overflow → Use after free Mitigations: ◮ detect multiplication overflows with compiler instrumentation ◮ PAX REFCOUNT [11] ◮ (no access) guard pages ◮ Hardened usercopy 1 1 https://lwn.net/Articles/695991/
Out of Order and Speculative Execution Caused by: ◮ Hardware bugs design, problematic known since ’95[12] ◮ exploiting race condition between memory access and privilege check ◮ speculative execution should be side-effect free → isn’t Mitigations: ◮ Kernel page-table isolation (derived from KAISER) ◮ Flush states, branch predictor, TLB, ... (slow) ◮ ... and/or use modern CPU features (PCID, IBRS/PB, STIBP)
Uninitialized variables / Stack Caused by: ◮ “Stack memory is frequently and unpredictably reused by other parts of code” [13] ◮ Uninitialized = previous value Mitigations: ◮ clear/poison kernel stack between syscalls (STACKLEAK plugin) ◮ initialize all structs (compiler plugin) [13]
Kernel Pointer Leakage Renders KASLR useless. Caused by: ◮ /proc ◮ kernel modules ◮ /sys Mitigations: ◮ restrict pointers visibility [14] ◮ hashed pointer [14]
Use After Free Caused by: ◮ Missing refcounting ◮ Aforementioned Integer overflow (“wrong refcounting”) [15] Mitigations: ◮ abstract resource access (refcount t) [16] ◮ avoid reference count overflow [11] ◮ clearing memory on free [17]
Race Conditions & Other Logic Flaws Caused by: ◮ Complex Protocol/Bad Design ◮ False Assumption about access Mitigations: ◮ Harder (often no statical analysis possible) ◮ Fuzzing: ◮ Syszcaller [18] ◮ trinity [19] ◮ American Fuzzy Lop (AFL) ◮ code instrumentation
Return Oriented Programming[22] Attack: ◮ arbitrary code injection not directly possible: ◮ execution disable (NX) ◮ signed code ◮ chain existing (library) functions together ◮ achieve goal Mitigation: ◮ Control Flow Integrity [20] through compiler ◮ Return Address Protection (RAP) [21]
Overwrite Kernel Image Attack: ◮ gain arbitrary code execution ◮ replace (parts) of kernel image ◮ . . . ◮ profit? Mitigation: ◮ Kernel image in read only memory ( ro after init) [23] ◮ “rare write” mechanism [24]
Function pointer overwrite Attack: ◮ builds upon use-after-free ◮ replace function pointer (destructor) with own function ◮ own function gets called in kernel context Mitigation: ◮ read only function pointer tables [23] (compiler plugin)
References
A. Svitak, Dragon’s Radiation-Tolerant Design , https://web.archive.org/web/20131203204735/http: //www.aviationweek.com/Blogs.aspx?plckBlogId= Blog%3A04ce340e-4b63-4d23-9695- d49ab661f385&plckPostId=Blog%3A04ce340e-4b63- 4d23-9695-d49ab661f385Post%3Aa8b87703-93f9-4cdf- 885f-9429605e14df , [Online; accessed 10-January-2019], 2013. L. A. Kees Cook, Kernel Self-Protection , https://git.kernel.org/pub/scm/linux/kernel/git/ torvalds/linux.git/tree/Documentation/security/ self-protection.rst?h=v4.20 , [Online; accessed 10-December-2019], 2016-2019.
M. Lipp, M. Schwarz, D. Gruss, T. Prescher, W. Haas, A. Fogh, J. Horn, S. Mangard, P. Kocher, D. Genkin, et al. , “Meltdown: Reading kernel memory from user space,” in 27th { USENIX } Security Symposium ( { USENIX } Security 18) , 2018, pp. 973–990. P. Kocher, J. Horn, A. Fogh, D. Genkin, D. Gruss, W. Haas, M. Hamburg, M. Lipp, S. Mangard, T. Prescher, M. Schwarz, and Y. Yarom, “Spectre attacks: Exploiting speculative execution,” in 40th IEEE Symposium on Security and Privacy (SP’19) , 2019.
J. Ribas, The kernel of the argument , http://www. washingtonpost.com/sf/business/2015/11/05/net- of-insecurity-the-kernel-of-the-argument/ , [Online; accessed 09-June-2017], 2015. C. Cowan, C. Pu, D. Maier, J. Walpole, P. Bakke, S. Beattie, A. Grier, P. Wagle, Q. Zhang, and H. Hinton, “Stackguard: Automatic adaptive detection and prevention of buffer-overflow attacks.,” in Usenix Security , vol. 98, 1998, pp. 63–78.
K. Cook, Introduce strong stackprotector , https://patchwork.kernel.org/patch/3387921/ , [Online; accessed 12-May-2017], 2013. g. PaX, Address Space Layout Randomisation , https://pax.grsecurity.net/docs/aslr.txt , [Online; accessed 10-May-2017], 2003. J. Edge, Kernel Address Space Layout Randomisation , https://lwn.net/Articles/569635/ , [Online; accessed 10-May-2017], 2013.
J. Corbet, Virtually mapped kernel stacks , https://lwn.net/Articles/692208/ , [Online; accessed 29-May-2017], 2016. g. PaX, PAX REFCOUNT , https: //forums.grsecurity.net/viewtopic.php?f=7&t=4173 , [Online; accessed 09-May-2017], 2015. O. Sibert, P. A. Porras, and R. Lindell, “The intel 80/spl times/86 processor architecture: Pitfalls for secure systems,” in Security and Privacy, 1995. Proceedings., 1995 IEEE Symposium on , IEEE, 1995, pp. 211–222.
K. Lu, M.-T. Walter, D. Pfaff, N. Stefan, W. Lee, and M. Backes, “Unleashing use-before-initialization vulnerabilities in the linux kernel using targeted stack spraying,” , NDSS, 2017. D. Rosenberg, kptr restrict for hiding kernel pointers , https://lwn.net/Articles/420403/ , [Online; accessed 09-June-2017], 2010. L. Song and Q. Xiao-Jun, “Parallelly refill slub objects freed in slow paths: An approach to exploit the use-after-free vulnerabilities in linux kernel,” in 2016 17th International Conference on Parallel and Distributed Computing,
Applications and Technologies (PDCAT) , Dec. 2016, pp. 387–390. doi : 10.1109/PDCAT.2016.088 . D. Windsor, Kernel Protections/HARDENED ATOMIC , https://kernsec.org/wiki/index.php/Kernel_ Protections/HARDENED_ATOMIC , [Online; accessed 29-May-2017], 2017. J. Chow, B. Pfaff, T. Garfinkel, and M. Rosenblum, “Shredding your garbage: Reducing data lifetime through secure deallocation,” in In USENIX Security , 2005.
D. Drysdale, Coverage-guided kernel fuzzing with syzkaller , https://lwn.net/Articles/677764/ , [Online; accessed 09-June-2017], 2016. M. Kerrisk, The Trinity fuzz tester , https://lwn.net/Articles/536173/ , [Online; accessed 09-June-2017], 2013. M. Abadi, M. Budiu, U. Erlingsson, and J. Ligatti, “Control-flow integrity,” in Proceedings of the 12th ACM conference on Computer and communications security , ACM, 2005, pp. 340–353.
PaX/grsecurity, RAP: RIP ROP , https://pax.grsecurity.net/docs/PaXTeam-H2HC15- RAP-RIP-ROP.pdf , [Online; accessed 02-June-2017], 2015. R. Hund, T. Holz, and F. C. Freiling, “Return-oriented rootkits: Bypassing kernel code integrity protection mechanisms.,” in USENIX Security Symposium , 2009, pp. 383–398. J. Corbet, Post-init read-only memory , https://lwn.net/Articles/666550/ , [Online; accessed 10-June-2017], 2015.
N. H. Kees Cook, Introduce rare write() infrastructure , https://lwn.net/Articles/724319/ , [Online; accessed 10-June-2017], 2017.
Recommend
More recommend