1. 7

  2. 1


    I don’t know the OpenBSD team or dev process very well; are there folks who work on OpenBSD with a background in exploit dev who would be able to approach this adversarially and see how hard it is to bypass?

    1. 4

      Perhaps a little, but probably not what you’re thinking. I think this is a problem in heuristic mitigation work, a lot of the review is “outsourced”.

      So I tricked Theo into working on this by telling him I would do it and then slacking. The theory was just look at exploits, see that stack pivots are common, and make it not work. But not a lot of rigor. Can you bypass it? In some cases, probably. Always? Generically?

      There’s some ongoing debate about the merit of mitigations. Are they always defeatable? Ever anything more than temporary roadblocks? Alas, I think there’s some survivor bias. We only see exploits with bypasses, not the exploits that couldn’t be made to work. But a review of history reveals all sorts of constraints on exploits. Must fit in a 96 byte payload, must not contain nil, etc. I remain hopeful that even if a mitigation can be bypassed, unknown future vulns may not always grant sufficient control to execute the bypass.

      1. 2

        FWIW, the way I try to breakdown mitigations that are described as “make exploits harder” are that that means either:

        1. Requires a better quality vulnerability, some vulnerabilities will no longer be exploitable, or will need to be paired with a second vulnerability.

        2. Requires a smarter exploit dev; no new bugs are required, but some exploit devs won’t have the skills to exploit it.

        I think people use “make exploits harder” to describe both of these behaviours interchangeably, so I’m always trying to figure out which it is :-)

        1. 2

          That’s a good split. I’m uncertain this is #1.