Difference between revisions of "Exploit Methods/Userspace execution"

From Linux Kernel Security Subsystem
Jump to navigation Jump to search
 
(4 intermediate revisions by 3 users not shown)
Line 2: Line 2:
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".)
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 is technically a superset of userspace execution.
For more details, see [[Exploit Methods/Userspace data usage|Userspace access]], as that can be superset of userspace execution under some emulation situations.


= Examples =
= Examples =
Line 8: Line 8:


= Mitigations =
= Mitigations =
* hardware segmentation: SMEP (x86), PXN (arm)
* hardware segregation: SMEP (x86), PXN (arm)
* compiler instrumentation to set high bit on function calls
* compiler instrumentation to set high bit on function calls
* emulate memory segmentation via separate page tables (e.g. PAX_MEMORY_UDEREF)
* 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:
Right now, the upstream options available for Privileged eXecute Never (e.g. PXN, SMEP) are:
Line 38: Line 38:
| hardware PXN (Address Spaces)
| hardware PXN (Address Spaces)
|-
|-
|colspan="2"| powerpc
|rowspan="4"| powerpc
|style="color: red;"| nothing?
| 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
|colspan="2"| MIPS
|style="color: red;"| nothing (could use ASID switching?)
|style="color: red;"| nothing (could use ASID switching?)
|}
|}

Latest revision as of 12:33, 31 July 2019

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 Userspace access, as that can be superset of userspace execution under some emulation situations.

Examples

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:

CPU Feature Name
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
x86 pre-Ivy-Bridge nothing (could use PCID?)
Ivy-Bridge+ (since May 2012) hardware PXN (SMEP)
s/390 hardware PXN (Address Spaces)
powerpc radix MMU (since POWER9) hardware PXN (KUEP, since Linux v4.10)
PPC64 hash MMU (since POWER7) nothing yet, but implementation possible
PPC32 hash MMU (except 601 which doesn't have NX segment) hardware PXN (KUEP)
MPC 8xx hardware PXN (KUEP)
MIPS nothing (could use ASID switching?)