Difference between revisions of "Exploit Methods/Userspace data usage"
Jump to navigation
Jump to search
m (→Details) |
|||
| 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 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 read/write. | 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 = | ||
Revision as of 19:53, 15 September 2016
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).
Examples
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 | nothing? | |
| MIPS | nothing (could use ASID switching?) | |