Bug Classes/Use after free - Revision history

DavidWindsor: Add reference counter overflow protection to Mitigations

2017-02-04T05:14:40Z

Add reference counter overflow protection to Mitigations

← Older revision		Revision as of 05:14, 4 February 2017
Line 11:		Line 11:
	* segregating memory used by the kernel and by userspace can stop attacks where this boundary is crossed (e.g. PAX_USERCOPY)		* segregating memory used by the kernel and by userspace can stop attacks where this boundary is crossed (e.g. PAX_USERCOPY)
	* randomizing heap allocations can frustrate the reallocation efforts the attack needs to perform (e.g. OpenBSD malloc)		* randomizing heap allocations can frustrate the reallocation efforts the attack needs to perform (e.g. OpenBSD malloc)
			* reference counter overflow protection (e.g. PAX_REFCOUNT, HARDENED_ATOMIC)

DavidWindsor: Undo revision 3836 by DavidWindsor (talk)

2017-02-04T05:13:56Z

Undo revision 3836 by DavidWindsor (talk)

← Older revision		Revision as of 05:13, 4 February 2017
Line 11:		Line 11:
	* segregating memory used by the kernel and by userspace can stop attacks where this boundary is crossed (e.g. PAX_USERCOPY)		* segregating memory used by the kernel and by userspace can stop attacks where this boundary is crossed (e.g. PAX_USERCOPY)
	* randomizing heap allocations can frustrate the reallocation efforts the attack needs to perform (e.g. OpenBSD malloc)		* randomizing heap allocations can frustrate the reallocation efforts the attack needs to perform (e.g. OpenBSD malloc)
	* reference counter overflow protection (PAX_REFCOUNT, HARDENED_ATOMIC)

DavidWindsor: Undo revision 3837 by DavidWindsor (talk)

2017-02-04T05:13:36Z

Undo revision 3837 by DavidWindsor (talk)

← Older revision		Revision as of 05:13, 4 February 2017
Line 11:		Line 11:
	* segregating memory used by the kernel and by userspace can stop attacks where this boundary is crossed (e.g. PAX_USERCOPY)		* segregating memory used by the kernel and by userspace can stop attacks where this boundary is crossed (e.g. PAX_USERCOPY)
	* randomizing heap allocations can frustrate the reallocation efforts the attack needs to perform (e.g. OpenBSD malloc)		* randomizing heap allocations can frustrate the reallocation efforts the attack needs to perform (e.g. OpenBSD malloc)
	* reference counter overflow protection (~~e.g.~~ PAX_REFCOUNT, HARDENED_ATOMIC)		* reference counter overflow protection (PAX_REFCOUNT, HARDENED_ATOMIC)

DavidWindsor: /* Mitigations */

2017-02-04T05:12:59Z

Mitigations

← Older revision		Revision as of 05:12, 4 February 2017
Line 11:		Line 11:
	* segregating memory used by the kernel and by userspace can stop attacks where this boundary is crossed (e.g. PAX_USERCOPY)		* segregating memory used by the kernel and by userspace can stop attacks where this boundary is crossed (e.g. PAX_USERCOPY)
	* randomizing heap allocations can frustrate the reallocation efforts the attack needs to perform (e.g. OpenBSD malloc)		* randomizing heap allocations can frustrate the reallocation efforts the attack needs to perform (e.g. OpenBSD malloc)
	* reference counter overflow protection (PAX_REFCOUNT, HARDENED_ATOMIC)		* reference counter overflow protection (e.g. PAX_REFCOUNT, HARDENED_ATOMIC)

DavidWindsor: /* Mitigations */

2017-02-04T05:12:39Z

Mitigations

← Older revision		Revision as of 05:12, 4 February 2017
Line 11:		Line 11:
	* segregating memory used by the kernel and by userspace can stop attacks where this boundary is crossed (e.g. PAX_USERCOPY)		* segregating memory used by the kernel and by userspace can stop attacks where this boundary is crossed (e.g. PAX_USERCOPY)
	* randomizing heap allocations can frustrate the reallocation efforts the attack needs to perform (e.g. OpenBSD malloc)		* randomizing heap allocations can frustrate the reallocation efforts the attack needs to perform (e.g. OpenBSD malloc)
			* reference counter overflow protection (PAX_REFCOUNT, HARDENED_ATOMIC)

KeesCook: Created page with "= Details = When a memory allocation gets freed but there are still accidentally users of that memory, it is possible that an attacker could control the new memory allocation ..."

2016-01-21T20:24:55Z

Created page with "= Details = When a memory allocation gets freed but there are still accidentally users of that memory, it is possible that an attacker could control the new memory allocation ..."

New page

= Details =
When a memory allocation gets freed but there are still accidentally users of that memory, it is possible that an attacker could control the new memory allocation that fills the freed area, and then manipulate the contents in a way that the system uses its stale pointer and expects a different structure than is currently present. If there are function pointers contained in the structure, this allows for trivial execution control.

= Examples =

* [http://perception-point.io/2016/01/14/analysis-and-exploitation-of-a-linux-kernel-vulnerability-cve-2016-0728/ keyring use-after-free]

= Mitigations =

* clearing memory on free can stop attacks where there is no reallocation control (e.g. PAX_MEMORY_SANITIZE)
* segregating memory used by the kernel and by userspace can stop attacks where this boundary is crossed (e.g. PAX_USERCOPY)
* randomizing heap allocations can frustrate the reallocation efforts the attack needs to perform (e.g. OpenBSD malloc)