1. 19
  1. 3

    Does anyone have an example of the types of bugs or attacks this will prevent?

    1. 2

      This is another mitigation for attacks along the lines of buffer overflows. Any attack that injects something into the stack cannot execute it as well. It’s really hard to pin down what types of attacks it will prevent because people trying to break your stuff generally make use of several bugs, holes, attack surfaces, etc. By putting this mitigation into affect it lowers the attack vector. Perhaps it mitigates an attack launched against a service with a bug in it that tickles the kernel.

      1. 2

        It marks memory as either writable or executable, but never both. Previously, if you found a bug that let you inject instructions and then trigger their execution, that would be all that it took. Now, you also need to find a way to change your injected instructions to be executable for your attack to work. In this context, it may mean fewer exploitable privilege escalation vulnerabilities in the OpenBSD kernel. This is sometimes sidestepped by triggering code that is already present and marked executable. If you’re curious, here’s a pretty high level overview of ROP. Many descriptions of ROP are userspace-centric, but the same general technique applies.

        1. 1

          Thanks all for the explanations, preventing the execution of buffer overflows is a clear use case.

          I just saw http://networkfilter.blogspot.com/2014/12/security-openbsd-vs-freebsd.html which has more information on WX as well.