Linux Kernel Security & Hardening

Thomas Lamprecht

January 17, 2019

Introduction

The Linux Kernel

I WidespreadI Deployed on:

I powerful (high performance compute clusters)I sensitive (bank, gov. systems, ..)I safety critical (Rocket Engine Control System[1], Automotive)

... SystemsI → thus: attractive target

Security Beyond Bugs

I Performance & Reliability 6= SecurityI Hardening seen as overhead in the pastI Critical security bug lifetime is huge (> 10 years possible)I Non-trivial software/hardware → never bug freeI Safety net needed (Kernel Self Protection (KSP) [2])

“Security needs to be more than just access control andattack-surface reduction.”

— Kees Cook, 2015 Kernel Summit

Security For Others Wrongdoing

I Working around hardware vulnerabilitiesI Side channel attacks (Meltdown[3], Spectre [4] )I Firmware/µCode bugsI User space programs

Kernel Self Protection vs. User Land Protection

Attack surface reduction:I SELinux/AppArmorI seccompI namespacing (mount, PID, net, ...)

Problems:I UsabilityI ComplexityI no protection against common Kernel bugs

Out of Tree Security

I Earlier Hardening resentment → out-of-tree approaches [5]I PaX/grsecurityI Lots of Linux Security Research happened until they went

privateI Low effort to upstreamI But, work now taken up by the community

Flaws & Mitigation Technologies

Stack Overflow

Attack:I Overwrite saved instruction pointer → execution control

Mitigations:I Stack canaries [6] [7]I Guard Pages [6]I KASLR [8] [9]I Shadow StacksI Virtually mapped kernel stacks [10]

Integer/Heap overflow

Caused by:I Integer overflow/Wrong Bound checkingI Overwrite adjacent kernel function pointerI refcount overflow → Use after free

Mitigations:I detect multiplication overflows with compiler instrumentationI PAX REFCOUNT [11]I (no access) guard pagesI Hardened usercopy 1

1https://lwn.net/Articles/695991/

Out of Order and Speculative Execution

Caused by:I Hardware bugs design, problematic known since ’95[12]I exploiting race condition between memory access and privilege

checkI speculative execution should be side-effect free → isn’t

Mitigations:I Kernel page-table isolation (derived from KAISER)I Flush states, branch predictor, TLB, ... (slow)I ... and/or use modern CPU features (PCID, IBRS/PB,

STIBP)

Uninitialized variables / Stack

Caused by:I “Stack memory is frequently and unpredictably reused by

other parts of code” [13]I Uninitialized = previous value

Mitigations:I clear/poison kernel stack between syscalls (STACKLEAK

plugin)I initialize all structs (compiler plugin) [13]

Kernel Pointer Leakage

Renders KASLR useless. Caused by:I /procI kernel modulesI /sys

Mitigations:I restrict pointers visibility [14]I hashed pointer [14]

Use After Free

Caused by:I Missing refcountingI Aforementioned Integer overflow (“wrong refcounting”) [15]

Mitigations:I abstract resource access (refcount t) [16]I avoid reference count overflow [11]I clearing memory on free [17]

Race Conditions & Other Logic Flaws

Caused by:I Complex Protocol/Bad DesignI False Assumption about access

Mitigations:I Harder (often no statical analysis possible)I Fuzzing:

I Syszcaller [18]I trinity [19]I American Fuzzy Lop (AFL)

I code instrumentation

Return Oriented Programming[22]

Attack:I arbitrary code injection not directly possible:

I execution disable (NX)I signed code

I chain existing (library) functions togetherI achieve goal

Mitigation:I Control Flow Integrity [20] through compilerI Return Address Protection (RAP) [21]

Overwrite Kernel Image

Attack:I gain arbitrary code executionI replace (parts) of kernel imageI . . .

I profit?Mitigation:

I Kernel image in read only memory ( ro after init) [23]I “rare write” mechanism [24]

Function pointer overwrite

Attack:I builds upon use-after-freeI replace function pointer (destructor) with own functionI own function gets called in kernel context

Mitigation:I 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; accessed10-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,” in27th {USENIX} Security Symposium ({USENIX} Security18), 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: Exploitingspeculative execution,” in 40th IEEE Symposium onSecurity 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 preventionof 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; accessed10-May-2017], 2013.

J. Corbet, Virtually mapped kernel stacks,https://lwn.net/Articles/692208/, [Online; accessed29-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/spltimes/86 processor architecture: Pitfalls for secure systems,”in Security and Privacy, 1995. Proceedings., 1995 IEEESymposium on, IEEE, 1995, pp. 211–222.

K. Lu, M.-T. Walter, D. Pfaff, N. Stefan, W. Lee, andM. Backes, “Unleashing use-before-initializationvulnerabilities in the linux kernel using targeted stackspraying,” , NDSS, 2017.D. Rosenberg, kptr restrict for hiding kernel pointers,https://lwn.net/Articles/420403/, [Online; accessed09-June-2017], 2010.L. Song and Q. Xiao-Jun, “Parallelly refill slub objects freedin slow paths: An approach to exploit the use-after-freevulnerabilities in linux kernel,” in 2016 17th InternationalConference 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; accessed29-May-2017], 2017.J. Chow, B. Pfaff, T. Garfinkel, and M. Rosenblum,“Shredding your garbage: Reducing data lifetime throughsecure deallocation,” in In USENIX Security, 2005.

D. Drysdale, Coverage-guided kernel fuzzing with syzkaller,https://lwn.net/Articles/677764/, [Online; accessed09-June-2017], 2016.M. Kerrisk, The Trinity fuzz tester,https://lwn.net/Articles/536173/, [Online; accessed09-June-2017], 2013.M. Abadi, M. Budiu, U. Erlingsson, and J. Ligatti,“Control-flow integrity,” in Proceedings of the 12th ACMconference 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-orientedrootkits: Bypassing kernel code integrity protectionmechanisms.,” in USENIX Security Symposium, 2009,pp. 383–398.J. Corbet, Post-init read-only memory,https://lwn.net/Articles/666550/, [Online; accessed10-June-2017], 2015.

N. H. Kees Cook, Introduce rare write() infrastructure,https://lwn.net/Articles/724319/, [Online; accessed10-June-2017], 2017.