TЯEИTJul 5, 2017
@lattera Interested to hear your thoughts on KARL and if you think it's possible to port to Hardened?
Show threadShawn WebbJul 5, 2017

@pr1ntf KARL is interesting research. However, I probably wouldn't take that approach. Kernel exploits are typically for local privesc. Randomization techniques (whether ASR, ASLR, KSR, KASRL, or KARL) are nullified by information disclosure vulnerabilities, which kernels are notorious for having all over the place.

I'd be interested in a long-term efficacy study.

Show threadShawn WebbJul 5, 2017
@pr1ntf As far as porting to HardenedBSD, I'm not sure it'd be a great fit. The first thing to do would be to fix the hundreds (if not thousands) of kernel address space information disclosures. Doing so would break fstat(1) and a number of other useful userland utilities.
Show threadBryan SteeleJul 5, 2017
@lattera @pr1ntf Yeah, there's been a lot of commits to OpenBSD to eliminate many of them, zeroing structs copied to userland, etc. In the case of fstat, all addresses are displayed as 0x0 unless root. A lot of the kmem snoopers were converted to using sysctl, or only work at securelevel <= 0.
Show threadShawn WebbJul 5, 2017

@canadianbryan @pr1ntf Yup. And, with how far behind #FreeBSD is with regards to exploit mitigations, we at #HardenedBSD need to spend a whole bunch of time playing catch up to secure userland first. The vast majority of attackers will gain initial entry through userland.

With PaX ASLR, PaX NOEXEC, CFI, and SafeStack, we're doing great at catching up. But we're still not where we want to be.

Show threadShawn WebbJul 6, 2017
@pr1ntf @canadianbryan Once we've ported over grsecurity, we'll probably look into more research-y things.
Show threadBryan SteeleJul 6, 2017
@lattera @pr1ntf 👍
Show threadBryan SteeleJul 6, 2017
@lattera @pr1ntf Lot of cool thought went into this, for example sendbug(1) needs to run acpidump(8), but that's a kmem snooper. So now it runs early and stores them in /var/db/acpi for later use.
Show threadBryan SteeleJul 6, 2017
@lattera @pr1ntf The ports people even went through and annotated scary ports, for example stuff like dmidecode prints instructions on how to optionally shoot yourself in the foot. :-)
Show threadShawn WebbJul 6, 2017

@canadianbryan @pr1ntf Switching subjects, but while you're here:

Is OpenBSD planning to switch amd64 to clang/llvm as the default compiler and lld as the default linker?

If so, porting over the sanitizer framework to gain SafeStack (and possibly CFI with more work) might be of interest to OpenBSD.

Show threadBryan SteeleJul 6, 2017

@lattera @pr1ntf I'd expect sooner or later it'll happen, both clang/lld are in -current amd64/i386 snaps. And arm64 has no working GCC! :-)

The ports guys have been doing bulk builds, coaxing the USE_WXNEEDED stuff, making it easier to select a modern C11/C++ compiler. It'll probably happen after 6.2. Maybe? 🤞

Show threadShawn Webb

@canadianbryan @pr1ntf The next question will hit a sore spot and may seem like a troll question, but I'm genuinely curious:

OpenBSD doesn't like when exploit mitigations require toggles for certain applications. We've talked before about using mprotect to switch between pages between RW and RX.

Now that OpenBSD has a form of a toggle via WX_NEEDED, would OpenBSD be in favor of hardening mprotect like PaX does in NOEXEC?

Jul 6, 2017 at 12:22amWeb
Show threadBryan SteeleJul 6, 2017

@lattera @pr1ntf It's not a user toggle, it's a combination of linker and mountpoint options that allow W^X violating software to work, at the same time shaming them. :-)

I still don't know what mprotect semantics you think OpenBSD lacks here, but the mailing lists would be a better place to bring that up. In summary though, no programs in base can violate W^X, and also a majority of them are pledge as well, and cannot make any page executable.

Show threadBryan SteeleJul 6, 2017
@pr1ntf @lattera To be clear, this is something the install sets for /usr/local when someone chooses the automatic disk layout. In addition to a ports Makefile annotation determined to be required by a developer.
Show threadShawn WebbJul 6, 2017
@canadianbryan @pr1ntf OpenBSD currently only protects against marking mappings as RWX, not transitioning between RW and RX. I'm wondering if OpenBSD could use the WX_NEEDED flag to harden mprotect to protect against switching between RW and RX.
Show threadBryan SteeleJul 6, 2017
@lattera @pr1ntf Well, in that case.. what about mapping alias to the same memory? That's basically what Firefox does now, one is executable and the other is writable.
Show threadShawn WebbJul 6, 2017
@canadianbryan @pr1ntf Firefox simply toggles between RW and RX. They toyed around with shadow pages, but not all operating systems support them in userland (FreeBSD, for example). They decided to go with the mprotect(RW->RX) model.
Show threadBryan SteeleJul 6, 2017
@lattera @pr1ntf Right, you're going with the PaX model and immediately enabling it again for a bunch of binaries.. so what's your point? :-)
Show threadBryan SteeleJul 6, 2017
@lattera @pr1ntf Actually, don't answer here. Send to misc@. 😉
Show threadShawn WebbJul 6, 2017
@pr1ntf @canadianbryan this is going to sound like a week, but I don't mean it that way: why even have the WX_NEEDED flag, then? Sounds like one could use that same argument of "if someone is going to use the you're, then don't have this feature" with WX_NEEDED. I'm just having trouble understanding where the line is drawn.
Show threadBryan SteeleJul 6, 2017
@lattera @pr1ntf It's preventing a whole class of attacks by preventing memory from being mapped W|X. It's automatically a good thing, and it's not putting the decision in the users hands.
Show threadBryan SteeleJul 6, 2017
@lattera @pr1ntf I mean, ultimately the goal here should be to encourage upstreams to stop violating or skirting W^X.. then these features can simply disappear forever.
Show threadShawn WebbJul 6, 2017
@canadianbryan @pr1ntf I think that's also where we differ: HardenedBSD's experience with the PaX model shows that only a few binaries need mprotect restrictions disabled. On my laptop with thousands of applications installed, I have mprotect restrictions disabled only for 4 applications. The rest are fully protected. I'm wondering if the OpenBSD community overestimates how many applications would need mprotect restrictions disabled.