Difference between revisions of "Exploit Methods/Userspace execution"
Jump to navigation
Jump to search
(→Mitigations: add PXN table) |
|||
(7 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
= Details = | = 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. | 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 | 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 | * 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 | * 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 19: | Line 19: | ||
|- | |- | ||
|rowspan="3"| ARM | |rowspan="3"| ARM | ||
| | | v7 (32-bit) non-LPAE | ||
| CONFIG_CPU_SW_DOMAIN_PAN | | CONFIG_CPU_SW_DOMAIN_PAN (since Linux v4.3) | ||
|- | |- | ||
| | | v7 (32-bit) LPAE (e.g. Cortex-A7, A15+) | ||
| hardware PXN | | hardware PXN (since Linux v3.19) | ||
|- | |- | ||
| | | v8.0+ (64-bit) | ||
| hardware PXN | | hardware PXN | ||
|- | |- | ||
|rowspan="2"| x86 | |rowspan="2"| x86 | ||
| pre-Ivy-Bridge | | pre-Ivy-Bridge | ||
|style="color: red;"| nothing | |style="color: red;"| nothing (could use PCID?) | ||
|- | |- | ||
| Ivy-Bridge+ (since May 2012) | | Ivy-Bridge+ (since May 2012) | ||
Line 42: | Line 42: | ||
|- | |- | ||
|colspan="2"| MIPS | |colspan="2"| MIPS | ||
|style="color: red;"| nothing? | |style="color: red;"| nothing (could use ASID switching?) | ||
|} | |} |
Revision as of 19:47, 15 September 2016
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
- 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:
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 | nothing? | |
MIPS | nothing (could use ASID switching?) |