Difference between revisions of "Bug Classes/Stack overflow"

From Linux Kernel Security Subsystem
Jump to navigation Jump to search
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
= Details =
= Details =
The traditional bug results in the stack buffer being written past the end of the stack frame, which allows the saved instruction pointer to be overwritten in order to gain execution control. Other attacks could stay within the stack frame, manipulating local variables ("data only" attacks). Some attacks allow for arbitrary offsets between kernel stacks to be written.
 
The traditional bug results in the stack buffer being written past the end of the stack frame, which allows the saved instruction pointer to be overwritten in order to gain execution control ("stack buffer overflow"). A stack depth overflow bug is when the size of the stack grows past its maximal size (via deep call stacks or via alloca abuse), and allows writing on other stacks or threadinfo. Other attacks could stay within the stack frame, manipulating local variables ("data only" attacks), and some attacks allow for writing by arbitrary offsets between kernel stacks.


= Examples =
= Examples =
Line 9: Line 10:


* stack canaries (e.g. gcc's -fstack-protector and [https://git.kernel.org/linus/8779657d29c0ebcc0c94ede4df2f497baf1b563f -fstack-protector-strong])
* stack canaries (e.g. gcc's -fstack-protector and [https://git.kernel.org/linus/8779657d29c0ebcc0c94ede4df2f497baf1b563f -fstack-protector-strong])
* guard pages (e.g. GRKERNSEC_KSTACKOVERFLOW)
* alloca checking (e.g. PAX_MEMORY_STACKLEAK)
* kernel stack location randomization
* kernel stack location randomization
* shadow stacks
* shadow stacks

Latest revision as of 21:48, 4 November 2015

Details

The traditional bug results in the stack buffer being written past the end of the stack frame, which allows the saved instruction pointer to be overwritten in order to gain execution control ("stack buffer overflow"). A stack depth overflow bug is when the size of the stack grows past its maximal size (via deep call stacks or via alloca abuse), and allows writing on other stacks or threadinfo. Other attacks could stay within the stack frame, manipulating local variables ("data only" attacks), and some attacks allow for writing by arbitrary offsets between kernel stacks.

Examples

  • half-nelson.c This uses stack offsets, rather than the traditional buffer overflow.

Mitigations

  • stack canaries (e.g. gcc's -fstack-protector and -fstack-protector-strong)
  • guard pages (e.g. GRKERNSEC_KSTACKOVERFLOW)
  • alloca checking (e.g. PAX_MEMORY_STACKLEAK)
  • kernel stack location randomization
  • shadow stacks