Exploit Methods/Userspace data usage

From Linux Kernel Security Subsystem
(Difference between revisions)
Jump to: navigation, search
m (Details)
(Mitigations)
 
(16 intermediate revisions by 2 users not shown)
Line 2: Line 2:
 
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.  
 
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 this is 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.
+
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 =
 
= Examples =
Line 10: Line 10:
  
 
= Mitigations =
 
= Mitigations =
* hardware segmentation: SMAP (x86), PAN (arm, arm64), Domains (arm)
+
* hardware segregation: SMAP (x86), PAN (arm, arm64), Domains (arm)
* emulate memory segmentation via separate page tables, PCID, etc (e.g. PAX_MEMORY_UDEREF)
+
* 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:
 
Right now, the upstream options available for Privileged Access Never (PAN) are:
Line 19: Line 19:
 
! Feature Name
 
! Feature Name
 
|-
 
|-
|rowspan="5"| ARM
+
|rowspan="3"| ARM
| v7 32-bit non-LPAE
+
| v7 (32-bit)
| CONFIG_CPU_SW_DOMAIN_PAN
+
| CONFIG_CPU_SW_DOMAIN_PAN (since Linux v4.3)
 
|-
 
|-
| v7 32-bit LPAE
+
| v8.0 (64-bit)
| CONFIG_CPU_TTBR0_PAN ([http://marc.info/?l=linux-arm-kernel&m=144308911409429&w=2 Catalin's series])
+
| CONFIG_ARM64_SW_TTBR0_PAN (likely Linux v4.9 [http://www.openwall.com/lists/kernel-hardening/2016/09/13/3 Catalin's series])
 
|-
 
|-
| v8.0 32-bit
+
| v8.1 (defined since December 2014)
| CONFIG_CPU_TTBR0_PAN
+
| hardware PAN (none shipping)
|-
+
| v8.0 64-bit
+
|style="color: red;"| nothing
+
|-
+
| v8.1
+
| hardware PAN
+
 
|-
 
|-
 
|rowspan="2"| x86
 
|rowspan="2"| x86
 
| pre-late-Broadwell
 
| pre-late-Broadwell
|style="color: red;"| nothing
+
|style="color: red;"| nothing (could use PCID?)
 
|-
 
|-
| Broadwell+
+
| Broadwell+ (since October 2014)
 
| hardware PAN (SMAP)
 
| hardware PAN (SMAP)
 
|-
 
|-
 
|colspan="2"| s/390
 
|colspan="2"| s/390
| hardware PAN (architectural?)
+
| 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)
 
|-
 
|-
|colspan="2"| powerpc
+
| MPC 8xx
|style="color: red;"| nothing?
+
| hardware PAN (KUAP)
 
|-
 
|-
 
|colspan="2"| MIPS
 
|colspan="2"| MIPS
|style="color: red;"| nothing?
+
|style="color: red;"| nothing (could use ASID switching?)
 
|}
 
|}

Latest revision as of 12:48, 31 July 2019

[edit] 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 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).

[edit] Examples

[edit] 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:

CPU Feature Name
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 Catalin's series)
v8.1 (defined since December 2014) hardware PAN (none shipping)
x86 pre-late-Broadwell nothing (could use PCID?)
Broadwell+ (since October 2014) hardware PAN (SMAP)
s/390 hardware PAN (Address Spaces)
powerpc radix MMU (since POWER9) hardware PAN (KUAP, since Linux 5.2)
PPC64 hash MMU (since POWER7) nothing yet, but implementation possible
PPC32 hash MMU hardware PAN (KUAP)
MPC 8xx hardware PAN (KUAP)
MIPS nothing (could use ASID switching?)
Personal tools
Namespaces

Variants
Actions
Navigation
Tools