Linux Kernel Security & Hardening Thomas Lamprecht January 17, - - PowerPoint PPT Presentation

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

1https://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

• ther 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-

• f-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

• f 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.