3 ms·

> The unfair ad hominem in the middle of your comment that detracts from your overall message, IMO I regretted it shortly after adding that part, but decided t

by wahern 6y ago

> The unfair ad hominem in the middle of your comment that detracts from your overall message, IMO I regretted it shortly after adding that part, but decided to leave it as I feel it dishonest to hide such comments after the fact. FWIW, I think Node.js, Rust, and Kubernetes are great technologies that fully merited their enthusiastic adoption. But it's precisely their ability to enable engineers to implement often sophisticated functional solutions that means the fact of doing so is much less a reflection of an engineer's experience and knowledge with the underlying problem space than was the case with different (often older) systems. Case in point: somebody arguing that Make is the dumbest, most useless tool and/or syntax, Go or Rust/Cargo are the gold standards for build systems, and then adding as an aside the observation that they don't work well in multi-language contexts or when needing to apply ad hoc (i.e. non-blessed) source transformations, which can sometimes be a hassle. It makes your head explode. Their opinion isn't even wrong; it's just oblivious to the design goals and the broader problem space, and that in some respects they're comparing apples and oranges despite providing nominally similar high-level functionality. How many Go or Rust/Cargo advocates even point out the problems with relying on timestamps? It's totally outside their focus despite being one of the most indisputable short-comings. (Though, at the same time also being one of the easiest to explain and justify given context--lack of forward monotonic change counters provided by filesystem APIs and the costs of adding a default file watcher capability to a tool that by original design was stateless between invocations.) Bazel engineers, of course, are quick to point this out, but they're also perfectly willing to boil the oceans in an attempt to more comprehensively solve the various problems in wrangling the chaotic world of FOSS software; more power to them. > some of the “novel features” to improve security seem to have inaccurate or outdated threat models behind them Can you name one technique? I'll even make it easier for you--name one that the Chrome architecture team would outright categorically oppose adding today were they maintaining OpenBSD? (There are plenty of things the team can't or won't add to Chrome for very pragmatic reasons.) The only one that comes to mind might be syscall-origin-verification, but even then it's too early to tell, and implications are beyond inaccurate that the OpenBSD team was oblivious to its limitations. (And FWIW, when I first read about it also seemed completely pointless to me until I dug up context from the mailing list to understand the motivations and goals.) OpenBSD was one of the first systems (arguably the first, depending on how you define things), to comprehensively implement and integrate ASLR, stack protectors, W^X, and various privilege separation techniques. (And I say that having contemporaneous knowledge of pre-existing examples, such as patches to GCC; that is, I know these techniques didn't originate with OpenBSD by any stretch.) At the time people said everything they say now about modern mitigations--circumventable, little effective security, more rigorous alternatives, etc--despite the fact that they've become table stakes today even while circumventions have become more sophisticated and in some cases even automatable. For years people argued you absolutely had to distinguish /dev/urandom from /dev/random, and only in the past couple years have people finally come around to understanding that theoretical and practical security are different, and that the practical benefits of a unified approach are undeniably superior. I mean, just go through the list here: https://www.openbsd.org/innovations.html https://www.openbsd.org/innovations.html Which ones even today are so useless that their continued use is unsupportable? Obviously in many cases there can be differences of opinion regarding relative merit, both then and now, but that's a far cry from saying that OpenBSD developers were naive or ignorant about their utility. In fact, in every case I can think of the naysayers were proven wrong--not because they were wrong about basic facts like circumvention, but because their calculus regarding cost/benefit was mistaken, often for precisely the reasons I stated before--e.g. exploit writers aren't implementing and hosting services, don't appreciate the relative costs and burdens from a systems programmer perspective (particularly one interested in targeting OpenBSD), and tend to assume that OpenBSD is choosing one approach in lieu of another. IIRC, on ARM and MIPS, for example, OpenBSD has removed almost all ROP gadgets even while continuing to add substantially less comprehensive ROP mitigations to cover other architectures and subsystems where it's been more difficult to remove gadgets. AFAIU, the Linux PaX team has had a low opinion of OpenBSD. Of course, they had a low opinion of many mainline Linux kernel maintainers, too. I never cared to follow the debates and recriminations, but objectively speaking much like OpenBSD their choices seemed to have generally been vindicated over the long term. AFAIU, almost every mitigation they implemented and advocated for the Linux kernel was eventually added in substantially similar form to Linux and its ecosystem, even though it took well over a decade in some cases. If history is any guide, criticisms of syscall-origin-verification will soften. I'm hardly of the opinion that OpenBSD design decisions are the most rigorous and appropriate answers to more abstract security dilemmas. But if you start from the perspective of maintaining and extending the received Unix application programming environment, and doing so for something more than running and orchestrating hypervisors, Erlang servers, WASM modules, etc, then their track record is incredible. I still think Capsicum is underappreciated, and if I had the time and inclination (which I don't), were I an OpenBSD maintainer it's something I would emphasize. (Ditto for FreeBSD, where the Capsicum API is nearly complete--I'd focus on increasing usage throughout the system.) But that's different than saying I think unveil and pledge are inferior alternatives.

saagarjha 6y ago
I am not on the Chrome architecture team, so I cannot predict with certainty what they would choose to do, but I can at least provide my opinion and hope that it doesn't stray too far from what they think ;) As for an overall summary, I think it is accurate to say that the OpenBSD people are obviously not idiots, and that they do make a lot of right choices. However, those decisions are (as I have mentioned elsewhere: https://news.ycombinator.com/item?id=26911420 https://news.ycombinator.com/item?id=26911420) mixed with some questionable ones. Overall I think they do adopt a lot of the right things–the ones you mentioned–and I do agree that they are fairly quick to do so, although sometimes they seem like they want to claim a bit more credit about being "first" or designing something than they really should. But those are social issues, so it's not really worth talking about them here. My main issue is that some of the OpenBSD mitigations seem to be designed by people who either have an outdated view of how modern exploits work, or are just entirely wrong. Like, they sound plausible for a bit if you just think about them, but if you look at real exploits you realize that they are not worth it, or they are just not how real chains look like. Ok, let's break this apart a bit. What does it mean to have an outdated view of exploits? This means that you're protecting against things that nobody does these days, because other mitigations exist to prevent it. If your mitigation protects against something that people used to do when NX didn't exist and ASLR was nonexistent or weak (perhaps due to lack of VA space), then it's clear that you're living in the past. Similarly, if your mitigation is intended to protect against some form of attack, but if these kinds of attacks never actually happen in the wild, or protecting against them opens up an alternative vector that you leave open, then your model is incomplete. Finally, when judging a mitigation, you don't look at what fraction of some exploit it mitigates when it is working perfectly–you need to consider it in the context of other things failing. ASLR is a "weak" mitigation because one partial, mildly controlled read might be enough to break it. Privdrop is a "strong" mitigation because there it requires a full kernel chain to undo. That doesn't mean they aren't both good to have, but it is important to keep this in mind when evaluating this kind of stuff. Anyways, onto some of the worse mitigations. Syscall origin verification seems like a weak hardening technique, designed with a lack of understanding of what kind of attacker might exploit it. The reasoning seems to be to prevent an attacker from doing things like writing a syscall into a JIT region, but generally attackers at that point can easily craft shellcode that gives them arbitrary R/W (or have this already), which lets them jump through libc anyways. As such, the general understanding is that it is pretty much useless at stopping an attacker at the level of control it claims it can protect against. ROP gadget removal is similarly problematic, because "removal" in this case doesn't mean "full removal", it means "reduction in their frequency". A ROP chain doesn't actually take that many gadgets, though, so you can do things like remove half or even more of all gadgets with pretty much zero impact on the ability to ROP. (And I'm not even going to get into the fact that using dumb gadget finding scripts, like OpenBSD did, is not how you measure gadget reduction.) And even once you have all the ROP opportunities removed, you need to then start looking at JOP, because that's what attackers are going to pivot to (heh), which AFAIK is not yet being considered. I'll do one more, but hopefully you get the idea by now: trapsleds are basically considered to be a joke. They are meant to protect against ROP nop sleds, except it fails to understand that these don't exist. When people ROP they jump precisely to where they want to go. It sounds good on paper, but in reality the mitigation just doesn't match up with any real attacks. There's a lot of good going on in OpenBSD, but there is also some places where they seem to not have caught up with what is going on in the real world. And I think people's general criticism towards the mitigations follow along those lines.

by wahern 6y ago

saagarjha 6y ago

I am not on the Chrome architecture team, so I cannot predict with certainty what they would choose to do, but I can at least provide my opinion and hope that it doesn't stray too far from what they think ;) As for an overall summary, I think it is accurate to say that the OpenBSD people are obviously not idiots, and that they do make a lot of right choices. However, those decisions are (as I have mentioned elsewhere: https://news.ycombinator.com/item?id=26911420 https://news.ycombinator.com/item?id=26911420) mixed with some questionable ones. Overall I think they do adopt a lot of the right things–the ones you mentioned–and I do agree that they are fairly quick to do so, although sometimes they seem like they want to claim a bit more credit about being "first" or designing something than they really should. But those are social issues, so it's not really worth talking about them here. My main issue is that some of the OpenBSD mitigations seem to be designed by people who either have an outdated view of how modern exploits work, or are just entirely wrong. Like, they sound plausible for a bit if you just think about them, but if you look at real exploits you realize that they are not worth it, or they are just not how real chains look like. Ok, let's break this apart a bit. What does it mean to have an outdated view of exploits? This means that you're protecting against things that nobody does these days, because other mitigations exist to prevent it. If your mitigation protects against something that people used to do when NX didn't exist and ASLR was nonexistent or weak (perhaps due to lack of VA space), then it's clear that you're living in the past. Similarly, if your mitigation is intended to protect against some form of attack, but if these kinds of attacks never actually happen in the wild, or protecting against them opens up an alternative vector that you leave open, then your model is incomplete. Finally, when judging a mitigation, you don't look at what fraction of some exploit it mitigates when it is working perfectly–you need to consider it in the context of other things failing. ASLR is a "weak" mitigation because one partial, mildly controlled read might be enough to break it. Privdrop is a "strong" mitigation because there it requires a full kernel chain to undo. That doesn't mean they aren't both good to have, but it is important to keep this in mind when evaluating this kind of stuff. Anyways, onto some of the worse mitigations. Syscall origin verification seems like a weak hardening technique, designed with a lack of understanding of what kind of attacker might exploit it. The reasoning seems to be to prevent an attacker from doing things like writing a syscall into a JIT region, but generally attackers at that point can easily craft shellcode that gives them arbitrary R/W (or have this already), which lets them jump through libc anyways. As such, the general understanding is that it is pretty much useless at stopping an attacker at the level of control it claims it can protect against. ROP gadget removal is similarly problematic, because "removal" in this case doesn't mean "full removal", it means "reduction in their frequency". A ROP chain doesn't actually take that many gadgets, though, so you can do things like remove half or even more of all gadgets with pretty much zero impact on the ability to ROP. (And I'm not even going to get into the fact that using dumb gadget finding scripts, like OpenBSD did, is not how you measure gadget reduction.) And even once you have all the ROP opportunities removed, you need to then start looking at JOP, because that's what attackers are going to pivot to (heh), which AFAIK is not yet being considered. I'll do one more, but hopefully you get the idea by now: trapsleds are basically considered to be a joke. They are meant to protect against ROP nop sleds, except it fails to understand that these don't exist. When people ROP they jump precisely to where they want to go. It sounds good on paper, but in reality the mitigation just doesn't match up with any real attacks. There's a lot of good going on in OpenBSD, but there is also some places where they seem to not have caught up with what is going on in the real world. And I think people's general criticism towards the mitigations follow along those lines.