Exploit Methods/Userspace data usage - Revision history

ChristopheLeroy: /* Mitigations */

2019-07-31T12:48:52Z

Mitigations

← Older revision		Revision as of 12:48, 31 July 2019
Line 39:		Line 39:
	\| hardware PAN (Address Spaces)		\| hardware PAN (Address Spaces)
	\|-		\|-
	\|rowspan="2"\| powerpc		\|rowspan="4"\| powerpc
	\| radix MMU (since POWER9)		\| radix MMU (since POWER9)
	\| hardware PAN (KUAP, since Linux 5.2)		\| hardware PAN (KUAP, since Linux 5.2)
	\|-		\|-
	\| hash MMU (since POWER7)		\| PPC64 hash MMU (since POWER7)
	\|style="color: red;"\| nothing yet, but implementation possible		\|style="color: red;"\| nothing yet, but implementation possible
			\|-
			\| PPC32 hash MMU
			\| hardware PAN (KUAP)
			\|-
			\| MPC 8xx
			\| hardware PAN (KUAP)
	\|-		\|-
	\|colspan="2"\| MIPS		\|colspan="2"\| MIPS
	\|style="color: red;"\| nothing (could use ASID switching?)		\|style="color: red;"\| nothing (could use ASID switching?)
	\|}		\|}

2019-05-13T04:55:17Z

ppc PAN merged in 5.2

← Older revision		Revision as of 04:55, 13 May 2019
Line 41:		Line 41:
	\|rowspan="2"\| powerpc		\|rowspan="2"\| powerpc
	\| radix MMU (since POWER9)		\| radix MMU (since POWER9)
	\| 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])		\| hardware PAN (KUAP, since Linux 5.2)
	\|-		\|-
	\| hash MMU (since POWER7)		\| hash MMU (since POWER7)

2019-05-08T05:19:21Z

update PAN for powerpc

← Older revision		Revision as of 05:19, 8 May 2019
Line 39:		Line 39:
	\| hardware PAN (Address Spaces)		\| hardware PAN (Address Spaces)
	\|-		\|-
	\|~~colspan~~="2"\| powerpc		\|rowspan="2"\| powerpc
	\|style="color: red;"\| nothing?		\| radix MMU (since POWER9)
			\| 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])
			\|-
			\| hash MMU (since POWER7)
			\|style="color: red;"\| nothing yet, but implementation possible
	\|-		\|-
	\|colspan="2"\| MIPS		\|colspan="2"\| MIPS
	\|style="color: red;"\| nothing (could use ASID switching?)		\|style="color: red;"\| nothing (could use ASID switching?)
	\|}		\|}

2016-09-15T19:53:49Z

Details

← Older revision		Revision as of 19:53, 15 September 2016
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 =

2016-09-15T19:49:42Z

Details

← Older revision		Revision as of 19:49, 15 September 2016
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 read/write.

	= Examples =		= Examples =

2016-09-15T19:48:32Z

Mitigations

← Older revision		Revision as of 19:48, 15 September 2016
Line 10:		Line 10:

	= Mitigations =		= Mitigations =
	* hardware ~~segmentation~~: SMAP (x86), PAN (arm, arm64), Domains (arm)		* hardware segregation: SMAP (x86), PAN (arm, arm64), Domains (arm)
	* emulated PAN (memory ~~segmentation~~ via segments, Domains, page table swapping, 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:

2016-09-15T03:59:40Z

Mitigations

← Older revision		Revision as of 03:59, 15 September 2016
Line 31:		Line 31:
	\|rowspan="2"\| x86		\|rowspan="2"\| x86
	\| pre-late-Broadwell		\| pre-late-Broadwell
	\|style="color: red;"\| nothing		\|style="color: red;"\| nothing (could use PCID?)
	\|-		\|-
	\| Broadwell+ (since October 2014)		\| Broadwell+ (since October 2014)

2016-09-15T03:54:27Z

Mitigations

← Older revision		Revision as of 03:54, 15 September 2016
Line 21:		Line 21:
	\|rowspan="3"\| ARM		\|rowspan="3"\| ARM
	\| v7 (32-bit)		\| v7 (32-bit)
	\| CONFIG_CPU_SW_DOMAIN_PAN		\| CONFIG_CPU_SW_DOMAIN_PAN (since Linux v4.3)
	\|-		\|-
	\| v8.0 (64-bit)		\| v8.0 (64-bit)
	\| ~~future:~~ CONFIG_ARM64_SW_TTBR0_PAN ([http://www.openwall.com/lists/kernel-hardening/2016/09/13/3 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.1 (defined since December 2014)		\| v8.1 (defined since December 2014)

2016-09-15T03:49:46Z

Mitigations

← Older revision		Revision as of 03:49, 15 September 2016
Line 23:		Line 23:
	\| CONFIG_CPU_SW_DOMAIN_PAN		\| CONFIG_CPU_SW_DOMAIN_PAN
	\|-		\|-
	\| v8.0		\| v8.0 (64-bit)
	\| future: CONFIG_ARM64_SW_TTBR0_PAN ([http://www.openwall.com/lists/kernel-hardening/2016/09/13/3 Catalin's series])		\| future: CONFIG_ARM64_SW_TTBR0_PAN ([http://www.openwall.com/lists/kernel-hardening/2016/09/13/3 Catalin's series])
	\|-		\|-
	\| v8.1 (since December 2014)		\| v8.1 (defined since December 2014)
	\| hardware PAN		\| hardware PAN (none shipping)
	\|-		\|-
	\|rowspan="2"\| x86		\|rowspan="2"\| x86

2016-09-15T03:48:31Z

Mitigations