3 ms·
Last paragraph is off base. They have a long history of doing mitigations by default before they are seen elsewhere. A lot of those are from more than 20 years
by asveikau 3y ago
Last paragraph is off base. They have a long history of doing mitigations by default before they are seen elsewhere. A lot of those are from more than 20 years ago though -- things like fewer services by default, daemons that chroot and drop privilege at a time when Linux didn't do that, W^X, address randomization.. more recently they do some stuff to prevent shellcode from making syscalls.. this IFUNC mechanism to monkey patch system binaries is something they would not go for.
- jcranmer 3y agoI'm going a bit far off of my wheelbase here, because exploit development and mitigation is not an area I have a lot of experience in, but the sense I've seen from security researchers is that OpenBSD's security posture is far more mixed than their developers' touting implies. So while OpenBSD may have some features that are well-regarded (say, their malloc implementation), they can do a shockingly bad job in other areas (such as ROP mitigations).
- tptacek 3y agoI think you're expressing an opinion that is pretty mainstream among runtime hardening and exploit people. You can find reasonable opinions in both directions, though. Joshua Stein built a page that is a pretty incredible resource on this topic: https://isopenbsdsecu.re/ https://isopenbsdsecu.re/
- cyberpunk 3y agoI’ve not seen any openbsd exploit code in… a decade though? Can you point me to a single working exploit for anything in openbsd lately? (Excluding shellshock/log4shell kind of vulns) I mean an exploit against some service running on openbsd, or even necessarily the os contents.. Edit: I don’t mean an 0day, just an exploit that worked on some combo of openbsd and x. X being anything like e.g Apache or Bind or whatever
- tptacek 3y agoThere was an RCE in OpenSMTPD --- a 25/tcp RCE, that'll bring you back to the '90s! --- like a minute ago.
- asveikau 3y agoI think that was early 2020 if memory serves. There was another serious security bug discovered a few months before too.
- tptacek 3y ago2022.
- asveikau 3y agoDo you have a source for that? I run it on a few machines and monitor that stuff, I think I would remember. I remember patching that one before the portable tree release with the fix was in a distro. I remember it very well because I was rushed, heading out to a meal but realizing a machine was vulnerable. Here's what I find googling: https://github.com/superzerosec/cve-2020-7247 https://github.com/superzerosec/cve-2020-7247 2020-01-29 I think later they had another crashing bug that wasn't exploitable. This one from 2020 was poor validation of input leading to a shell command. A very 90s bug indeed.
- tptacek 3y agoOh! You're totally right. I had two different links, and, of course, the actual Qualys advisory has the date you're giving it. Thanks for taking the time to correct me on this.
- somat 3y agocitation needed for the failings of their ROP mitigations. I don't use openbsd for the security, so I don't pay much attention to that side of things. But the one that stood out was where they removed all rop gadgets. which sounds pretty good to me. https://www.openbsd.org/papers/asiabsdcon2019-rop-paper.pdf https://www.openbsd.org/papers/asiabsdcon2019-rop-paper.pdf
- jcranmer 3y agoThe link tptacek gave to a talk is such a citation, albeit at a very high level.