Linux Kernel Security Subsystem - User contributions [en]

Exploit Methods/Userspace data usage

2019-07-31T12:48:52Z

ChristopheLeroy: /* Mitigations */

= Details =
Sometimes an attacker won't be able to control the instruction pointer directly, but they will be able to redirect the dereference a structure or other pointer. In these cases, it is easiest to aim at malicious structures that have been built in userspace to perform the exploitation.

Note that under some emulation situations, this can be a superset that includes [[Exploit Methods/Userspace execution|Userspace execution]]. (If we can protect against userspace access, we'll also be protecting against userspace execution.) Hardware protections tend to be separate, though, due to different memory paths for instruction fetch (execution) and data access (read/write).

= Examples =
* [https://github.com/geekben/towelroot/blob/master/towelroot.c cred structure]
* [http://labs.bromium.com/2015/02/02/exploiting-badiret-vulnerability-cve-2014-9322-linux-kernel-privilege-escalation/ fake kernel stack]
* [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=176155dac13f528e0a58c14dc322623219365d91 Bad casts]

= Mitigations =
* hardware segregation: SMAP (x86), PAN (arm, arm64), Domains (arm)
* emulated PAN (memory segregation via segments, Domains, page table swapping, PCID, etc. e.g. PAX_MEMORY_UDEREF)

Right now, the upstream options available for Privileged Access Never (PAN) are:

{| class="wikitable"
!colspan="2"|CPU
! Feature Name
|-
|rowspan="3"| ARM
| v7 (32-bit)
| CONFIG_CPU_SW_DOMAIN_PAN (since Linux v4.3)
|-
| v8.0 (64-bit)
| CONFIG_ARM64_SW_TTBR0_PAN (likely Linux v4.9 [http://www.openwall.com/lists/kernel-hardening/2016/09/13/3 Catalin's series])
|-
| v8.1 (defined since December 2014)
| hardware PAN (none shipping)
|-
|rowspan="2"| x86
| pre-late-Broadwell
|style="color: red;"| nothing (could use PCID?)
|-
| Broadwell+ (since October 2014)
| hardware PAN (SMAP)
|-
|colspan="2"| s/390
| hardware PAN (Address Spaces)
|-
|rowspan="4"| powerpc
| radix MMU (since POWER9)
| hardware PAN (KUAP, since Linux 5.2)
|-
| PPC64 hash MMU (since POWER7)
|style="color: red;"| nothing yet, but implementation possible
|-
| PPC32 hash MMU
| hardware PAN (KUAP)
|-
| MPC 8xx
| hardware PAN (KUAP)
|-
|colspan="2"| MIPS
|style="color: red;"| nothing (could use ASID switching?)
|}

Exploit Methods/Userspace execution

2019-07-31T12:33:26Z

ChristopheLeroy: /* Mitigations */

= Details =
Once an attacker has gain control over the instruction pointers, it must be aimed somewhere. The place where attackers have the most control over memory layout tends to be in userspace, so it has been natural to place malicious code in userspace and have the kernel redirection execution there. (Frequently known as "ret2usr".)

For more details, see [[Exploit Methods/Userspace data usage|Userspace access]], as that can be superset of userspace execution under some emulation situations.

= Examples =
* See nearly every other exploit example listed under other [[Exploit Methods]] and [[Bug Classes]].

= Mitigations =
* hardware segregation: SMEP (x86), PXN (arm)
* compiler instrumentation to set high bit on function calls
* emulate memory segregation via separate page tables (e.g. PAX_MEMORY_UDEREF)

Right now, the upstream options available for Privileged eXecute Never (e.g. PXN, SMEP) are:

{| class="wikitable"
!colspan="2"|CPU
! Feature Name
|-
|rowspan="3"| ARM
| v7 (32-bit) non-LPAE
| CONFIG_CPU_SW_DOMAIN_PAN (since Linux v4.3)
|-
| v7 (32-bit) LPAE (e.g. Cortex-A7, A15+)
| hardware PXN (since Linux v3.19)
|-
| v8.0+ (64-bit)
| hardware PXN
|-
|rowspan="2"| x86
| pre-Ivy-Bridge
|style="color: red;"| nothing (could use PCID?)
|-
| Ivy-Bridge+ (since May 2012)
| hardware PXN (SMEP)
|-
|colspan="2"| s/390
| hardware PXN (Address Spaces)
|-
|rowspan="4"| powerpc
| radix MMU (since POWER9)
| hardware PXN (KUEP, since Linux v4.10)
|-
| PPC64 hash MMU (since POWER7)
|style="color: red;"| nothing yet, but implementation possible
|-
| PPC32 hash MMU (except 601 which doesn't have NX segment)
| hardware PXN (KUEP)
|-
| MPC 8xx
| hardware PXN (KUEP)
|-
|colspan="2"| MIPS
|style="color: red;"| nothing (could use ASID switching?)
|}

Exploit Methods/Userspace execution

2019-07-31T12:32:16Z

ChristopheLeroy: /* Mitigations */

= Details =
Once an attacker has gain control over the instruction pointers, it must be aimed somewhere. The place where attackers have the most control over memory layout tends to be in userspace, so it has been natural to place malicious code in userspace and have the kernel redirection execution there. (Frequently known as "ret2usr".)

For more details, see [[Exploit Methods/Userspace data usage|Userspace access]], as that can be superset of userspace execution under some emulation situations.

= Examples =
* See nearly every other exploit example listed under other [[Exploit Methods]] and [[Bug Classes]].

= Mitigations =
* hardware segregation: SMEP (x86), PXN (arm)
* compiler instrumentation to set high bit on function calls
* emulate memory segregation via separate page tables (e.g. PAX_MEMORY_UDEREF)

Right now, the upstream options available for Privileged eXecute Never (e.g. PXN, SMEP) are:

{| class="wikitable"
!colspan="2"|CPU
! Feature Name
|-
|rowspan="3"| ARM
| v7 (32-bit) non-LPAE
| CONFIG_CPU_SW_DOMAIN_PAN (since Linux v4.3)
|-
| v7 (32-bit) LPAE (e.g. Cortex-A7, A15+)
| hardware PXN (since Linux v3.19)
|-
| v8.0+ (64-bit)
| hardware PXN
|-
|rowspan="2"| x86
| pre-Ivy-Bridge
|style="color: red;"| nothing (could use PCID?)
|-
| Ivy-Bridge+ (since May 2012)
| hardware PXN (SMEP)
|-
|colspan="2"| s/390
| hardware PXN (Address Spaces)
|-
|rowspan="2"| powerpc
| radix MMU (since POWER9)
| hardware PXN (KUEP, since Linux v4.10)
|-
| PPC64 hash MMU (since POWER7)
|style="color: red;"| nothing yet, but implementation possible
|-
| PPC32 hash MMU (except 601 which doesn't have NX segment)
| hardware PXN (KUEP)
|-
| MPC 8xx
| hardware PXN (KUEP)
|-
|colspan="2"| MIPS
|style="color: red;"| nothing (could use ASID switching?)
|}

Kernel Self Protection Project/Work

2019-07-31T12:20:02Z

ChristopheLeroy:

= Work Areas =

The [[Kernel Self Protection Project]] has a lot of work to do! While there are already a number of upstream [[Feature List|kernel security features]], we are still missing many. The following is far from a comprehensive list, but it's at least a starting point we can add to:

== [[Bug Classes]] ==

* [[Bug Classes/Stack overflow|Stack overflow]]
* [[Bug Classes/Integer overflow|Integer overflow]]
* [[Bug Classes/Heap overflow|Heap overflow]]
* [[Bug Classes/Format string injection|Format string injection]]
* [[Bug Classes/Kernel pointer leak|Kernel pointer leak]]
* [[Bug Classes/Uninitialized variables|Uninitialized variables]]
* [[Bug Classes/Use after free|Use-after-free]]

== [[Exploit Methods|Exploitation Methods]] ==

* [[Exploit Methods/Kernel location|Kernel location]]
* [[Exploit Methods/Text overwrite|Text overwrite]]
* [[Exploit Methods/Function pointer overwrite|Function pointer overwrite]]
* [[Exploit Methods/Userspace execution|Userspace execution]]
* [[Exploit Methods/Userspace data usage|Userspace data usage]]
* [[Exploit Methods/Reused code chunks|Reused code chunks]]

= Specific TODO Items =

Besides the general work outlined above, there are number of specific tasks that have either been asked about frequently or are otherwise in need some time and attention:

== Kernel items ==
* Split thread_info off of kernel stack (Done: x86, arm64, s390, powerpc. Needed on arm and others?)
* Move kernel stack to vmap area (Done: x86, s390. Needed on arm, arm64, powerpc and others?)
* Implement kernel relocation and KASLR for ARM
* Make CONFIG_STRICT_KERNEL_RWX and CONFIG_STRICT_MODULE_RWX mandatory (done for arm64 and x86, other archs still need it)
* Further restriction of perf_event_open (e.g. perf_event_paranoid=3)
* Extend HARDENED_USERCOPY to split user-facing kmalloc()s and in-kernel kmalloc()
* split short-lived kmalloc()s from long-lived kmalloc()s
* split user-size-controlled kmalloc()s from regular kmalloc()s
* protect ARM vector table as fixed-location kernel target
* disable kuser helpers on arm
* add constant-blinding tests to lib/test_bpf.c
* rename CONFIG_DEBUG_LIST better and default=y
* create defconfig "make" target for by-default hardened Kconfigs
* expand use of __ro_after_init, especially in arch/arm64
* restrict autoloading of kernel modules (like GRKERNSEC_MODHARDEN) ([http://www.openwall.com/lists/kernel-hardening/2017/02/02/21 Timgad LSM])
* set_memory_*() needs __must_check and/or atomicity
* refactor tasklets to avoid unsigned long argument (WIP: Romain Perier <romain.perier@gmail.com>, "rperier" on FreeNode)
* have kfree() (and related) set the pointer to NULL too
* create per-task stack canary (Done: x86, arm, arm64, powerpc. Needed on s390 and others?)
* deprecate strcpy() in favor of strscpy()
* deprecate strlcpy() in favor of strscpy()
* deprecate strncpy() in favor of strscpy(), strscpy_pad(), or str2mem_pad()
* fix sizeof_field() vs SIZEOF_FIELD() vs FIELD_SIZEOF() (WIP: Shyam Saini <mayhs11saini@gmail.com>)
* expand use of opt-in mult/div/add/sub overflow wrappers
* WARN on kfree() of ERR_PTR range (WIP: Shyam Saini <mayhs11saini@gmail.com>)
* add detection for double-reads
* add FORTIFY_SOURCE checks to strscpy*()
* add static_branch for iopl removal (and zeroing?)
* enhance objtool to search for ROP gadgets
* signed integer overflow detection
* unsigned integer overflow detection
* exec brute force detection

== Compiler items ==
* Write a plugin to do format string warnings correctly (gcc's -Wformat-security is bad about const strings)
* Finish Clang implementation of __randomize_layout
* Implement clearing of caller-saved regs (https://github.com/clearlinux-pkgs/gcc/blob/master/zero-regs-gcc8.patch)