http://kernsec.org/wiki/api.php?action=feedcontributions&user=RussellCurrey&feedformat=atomLinux Kernel Security Subsystem - User contributions [en]2024-03-29T06:51:59ZUser contributionsMediaWiki 1.36.1http://kernsec.org/wiki/index.php?title=Exploit_Methods/Userspace_data_usage&diff=3989Exploit Methods/Userspace data usage2019-05-13T04:55:17Z<p>RussellCurrey: ppc PAN merged in 5.2</p>
<hr />
<div>= Details =<br />
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. <br />
<br />
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).<br />
<br />
= Examples =<br />
* [https://github.com/geekben/towelroot/blob/master/towelroot.c cred structure]<br />
* [http://labs.bromium.com/2015/02/02/exploiting-badiret-vulnerability-cve-2014-9322-linux-kernel-privilege-escalation/ fake kernel stack]<br />
* [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=176155dac13f528e0a58c14dc322623219365d91 Bad casts]<br />
<br />
= Mitigations =<br />
* hardware segregation: SMAP (x86), PAN (arm, arm64), Domains (arm)<br />
* emulated PAN (memory segregation via segments, Domains, page table swapping, PCID, etc. e.g. PAX_MEMORY_UDEREF)<br />
<br />
Right now, the upstream options available for Privileged Access Never (PAN) are:<br />
<br />
{| class="wikitable"<br />
!colspan="2"|CPU<br />
! Feature Name<br />
|-<br />
|rowspan="3"| ARM<br />
| v7 (32-bit)<br />
| CONFIG_CPU_SW_DOMAIN_PAN (since Linux v4.3)<br />
|-<br />
| v8.0 (64-bit)<br />
| CONFIG_ARM64_SW_TTBR0_PAN (likely Linux v4.9 [http://www.openwall.com/lists/kernel-hardening/2016/09/13/3 Catalin's series])<br />
|-<br />
| v8.1 (defined since December 2014)<br />
| hardware PAN (none shipping)<br />
|-<br />
|rowspan="2"| x86<br />
| pre-late-Broadwell<br />
|style="color: red;"| nothing (could use PCID?)<br />
|-<br />
| Broadwell+ (since October 2014)<br />
| hardware PAN (SMAP)<br />
|-<br />
|colspan="2"| s/390<br />
| hardware PAN (Address Spaces)<br />
|-<br />
|rowspan="2"| powerpc<br />
| radix MMU (since POWER9)<br />
| hardware PAN (KUAP, since Linux 5.2)<br />
|-<br />
| hash MMU (since POWER7)<br />
|style="color: red;"| nothing yet, but implementation possible<br />
|-<br />
|colspan="2"| MIPS<br />
|style="color: red;"| nothing (could use ASID switching?)<br />
|}</div>RussellCurreyhttp://kernsec.org/wiki/index.php?title=Exploit_Methods/Userspace_data_usage&diff=3988Exploit Methods/Userspace data usage2019-05-08T05:19:21Z<p>RussellCurrey: update PAN for powerpc</p>
<hr />
<div>= Details =<br />
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. <br />
<br />
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).<br />
<br />
= Examples =<br />
* [https://github.com/geekben/towelroot/blob/master/towelroot.c cred structure]<br />
* [http://labs.bromium.com/2015/02/02/exploiting-badiret-vulnerability-cve-2014-9322-linux-kernel-privilege-escalation/ fake kernel stack]<br />
* [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=176155dac13f528e0a58c14dc322623219365d91 Bad casts]<br />
<br />
= Mitigations =<br />
* hardware segregation: SMAP (x86), PAN (arm, arm64), Domains (arm)<br />
* emulated PAN (memory segregation via segments, Domains, page table swapping, PCID, etc. e.g. PAX_MEMORY_UDEREF)<br />
<br />
Right now, the upstream options available for Privileged Access Never (PAN) are:<br />
<br />
{| class="wikitable"<br />
!colspan="2"|CPU<br />
! Feature Name<br />
|-<br />
|rowspan="3"| ARM<br />
| v7 (32-bit)<br />
| CONFIG_CPU_SW_DOMAIN_PAN (since Linux v4.3)<br />
|-<br />
| v8.0 (64-bit)<br />
| CONFIG_ARM64_SW_TTBR0_PAN (likely Linux v4.9 [http://www.openwall.com/lists/kernel-hardening/2016/09/13/3 Catalin's series])<br />
|-<br />
| v8.1 (defined since December 2014)<br />
| hardware PAN (none shipping)<br />
|-<br />
|rowspan="2"| x86<br />
| pre-late-Broadwell<br />
|style="color: red;"| nothing (could use PCID?)<br />
|-<br />
| Broadwell+ (since October 2014)<br />
| hardware PAN (SMAP)<br />
|-<br />
|colspan="2"| s/390<br />
| hardware PAN (Address Spaces)<br />
|-<br />
|rowspan="2"| powerpc<br />
| radix MMU (since POWER9)<br />
| hardware PAN (KUAP, [https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?h=next&id=890274c2dc4c0a57ae5a12d6a76fa6d05b599d98 likely since Linux v5.2])<br />
|-<br />
| hash MMU (since POWER7)<br />
|style="color: red;"| nothing yet, but implementation possible<br />
|-<br />
|colspan="2"| MIPS<br />
|style="color: red;"| nothing (could use ASID switching?)<br />
|}</div>RussellCurreyhttp://kernsec.org/wiki/index.php?title=Exploit_Methods/Userspace_execution&diff=3986Exploit Methods/Userspace execution2019-03-25T02:40:10Z<p>RussellCurrey: update for powerpc</p>
<hr />
<div>= Details =<br />
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".)<br />
<br />
For more details, see [[Exploit Methods/Userspace data usage|Userspace access]], as that can be superset of userspace execution under some emulation situations.<br />
<br />
= Examples =<br />
* See nearly every other exploit example listed under other [[Exploit Methods]] and [[Bug Classes]].<br />
<br />
= Mitigations =<br />
* hardware segregation: SMEP (x86), PXN (arm)<br />
* compiler instrumentation to set high bit on function calls<br />
* emulate memory segregation via separate page tables (e.g. PAX_MEMORY_UDEREF)<br />
<br />
Right now, the upstream options available for Privileged eXecute Never (e.g. PXN, SMEP) are:<br />
<br />
{| class="wikitable"<br />
!colspan="2"|CPU<br />
! Feature Name<br />
|-<br />
|rowspan="3"| ARM<br />
| v7 (32-bit) non-LPAE<br />
| CONFIG_CPU_SW_DOMAIN_PAN (since Linux v4.3)<br />
|-<br />
| v7 (32-bit) LPAE (e.g. Cortex-A7, A15+)<br />
| hardware PXN (since Linux v3.19)<br />
|-<br />
| v8.0+ (64-bit)<br />
| hardware PXN<br />
|-<br />
|rowspan="2"| x86<br />
| pre-Ivy-Bridge<br />
|style="color: red;"| nothing (could use PCID?)<br />
|-<br />
| Ivy-Bridge+ (since May 2012)<br />
| hardware PXN (SMEP)<br />
|-<br />
|colspan="2"| s/390<br />
| hardware PXN (Address Spaces)<br />
|-<br />
|rowspan="2"| powerpc<br />
| radix MMU (since POWER9)<br />
| hardware PXN (KUEP, since Linux v4.10)<br />
|-<br />
| hash MMU (since POWER7)<br />
|style="color: red;"| nothing yet, but implementation possible<br />
|-<br />
|colspan="2"| MIPS<br />
|style="color: red;"| nothing (could use ASID switching?)<br />
|}</div>RussellCurreyhttp://kernsec.org/wiki/index.php?title=User:RussellCurrey&diff=3981User:RussellCurrey2018-10-30T04:35:26Z<p>RussellCurrey: Created page with " == ruscur == I'm [https://russell.cc Russell Currey] aka ruscur, an Australian kernel hacker working at IBM [https://ozlabs.org OzLabs]. Currently focused on POWER kernel h..."</p>
<hr />
<div><br />
== ruscur ==<br />
<br />
I'm [https://russell.cc Russell Currey] aka ruscur, an Australian kernel hacker working at IBM [https://ozlabs.org OzLabs].<br />
<br />
Currently focused on POWER kernel hardening.<br />
<br />
You can email my handle at russell.cc or find me on twitter [https://twitter.com/russelldotcc @russelldotcc].</div>RussellCurrey