Meaningful Bounds Checking in the Linux Kernel
Kaya Theatre | Sat 15 Jan 10:45 a.m.–11:30 a.m.
Presented by
-
Kees Cook
@kees_cook
https://outflux.net/blog
Kees Cook has been working with Free Software since 1994, has been a Debian Developer since 2007, and has been a member of the Linux Kernel Technical Advisory Board since 2019. He is currently employed as a Linux kernel security engineer by Google, focusing on upstream kernel security defenses.
From 2006 through 2011 he worked for Canonical as the Ubuntu Security Team's Tech Lead, and served on the Ubuntu Technical Board until 2020. Before that, he worked as the lead sysadmin at OSDL, before it was the Linux Foundation. He wrote various ancient utilities including GOPchop and Sendpage, and contributes randomly to other projects including fun chunks of code in OpenSSH, Inkscape, Wine, MPlayer, and Wireshark.
Kees Cook
@kees_cook
https://outflux.net/blog
Abstract
Like all C/C++ programs, the Linux Kernel regularly suffers from buffer overflow flaws. While stack overflows have been largely addressed, heap overflows remain common. Especially frustrating is that the compiler usually has enough context to have been able to stop the overflow but C APIs are so terrible that it doesn't happen.
We'll take a quick look back through at least the last 3 years of heap buffer overflow CVEs in the kernel. This will lead to the discovery that all 11 memcpy overflows from this timespan (which includes the heap buffer overflow flaw used by the BleedingTooth exploit), could have been detected and mitigated by the compiler. However, limitations in C language usage, APIs, kernel coding conventions, and compiler bugs made this a difficult problem to tackle.
We will explore the path to solutions being developed in the Linux kernel for dealing with array index overflows, string manipulation overflows, and especially memcpy overflows. We will cover the history of C flexible arrays, the unexpected places where the "-Warray-bounds" and "-fsanitize=bounds" compiler options don't work, the limits of "__builtin_object_size" (the work-horse of FORTIFY_SOURCE), and how memcpy is being effectively replaced to stop overflows from ever happening again.
Like all C/C++ programs, the Linux Kernel regularly suffers from buffer overflow flaws. While stack overflows have been largely addressed, heap overflows remain common. Especially frustrating is that the compiler usually has enough context to have been able to stop the overflow but C APIs are so terrible that it doesn't happen. We'll take a quick look back through at least the last 3 years of heap buffer overflow CVEs in the kernel. This will lead to the discovery that all 11 memcpy overflows from this timespan (which includes the heap buffer overflow flaw used by the BleedingTooth exploit), could have been detected and mitigated by the compiler. However, limitations in C language usage, APIs, kernel coding conventions, and compiler bugs made this a difficult problem to tackle. We will explore the path to solutions being developed in the Linux kernel for dealing with array index overflows, string manipulation overflows, and especially memcpy overflows. We will cover the history of C flexible arrays, the unexpected places where the "-Warray-bounds" and "-fsanitize=bounds" compiler options don't work, the limits of "__builtin_object_size" (the work-horse of FORTIFY_SOURCE), and how memcpy is being effectively replaced to stop overflows from ever happening again.