Earlier quoted context omitted.
[citation needed]
Here are a lot of citations: https://isopenbsdsecu.re/quotes/
Few groups confuse me more than the ones who vigorously argue I shouldn’t like an operating system.
OpenBSD – pinning all system calls
101–110 of 118 posts
Re: OpenBSD – pinning all system calls
#102Earlier quoted context omitted.
>I'm sure OpenBSD developers have very good intuition on what could be used in a vulnerability, without having to write one themselves Why? On average programmers are not very good security engineers. And the opposite - security engineers are often not a good programmers. If your mitigation doesn't stop any CVE that's being exploited right now in the wild, it's an academic exercise and not particularly useful IMO. >A…
> If your mitigation doesn't stop any CVE that's being exploited right now in the wild, it's an academic exercise and not particularly useful IMO. If your only metric of security is "fixed CVEs", then you're rewarding mistakes that were rectified later, and punishing proactive approach to security that actually makes fewer CVEs appear in the first place. And Theo's reputation and influence on the security is evidence…
You're mischaracterizing their logic. They're saying it's a necessary but not sufficient metric. You can't then shoot it down for being not-sufficient; we all agree about that.
It's not my recollection that Theo created OpenSSH, for what it's worth. My memory of this is that it was mostly Niels and Markus who did the lifting.
You might do some digging on Theo's reputation among exploit developers. It's complicated.
Re: OpenBSD – pinning all system calls
#103Earlier quoted context omitted.
Implying that OpenBSD has not considered Rust? There is plenty of discussion on misc@ already (for example [1]) and while it certainly can be "ranty", I am sure if one reads it in good faith you get a fairly nuanced picture. [1]: https://marc.info/?l=openbsd-misc&m=151233210523661&w=2 Look, I think a lot of programmers and managers fail to understand the number of factors one needs to consider and how it scales with…
> I am sure if one reads it in good faith you get a fairly nuanced picture. I don't see a lot of nuance. The primary argument in that thread boils down to any programmer who isn't using C isn't a serious programmer. The dominant technical analyses are a) adding more compiler toolchains make builds take a lot longer and b) memory safety doesn't protect against everything, so why bother? That's not nuance. Nuance would…
> You can also discuss Rust's failures. Rust, after all, didn't get uninitialized memory right.
I think that's a success story because while Rust 1.0 shipped with the hopelessly broken std::mem::unitialized, Rust 1.36 shipped with std::mem::MaybeUninit that fixed the situation. (it's true that they can't definitely remove the broken API, but it can be aggressively linted against nonetheless)
That is, it's a flaw present in the first version of the language but a success of the development process and language evolution, without breaking backwards compatibility
Re: OpenBSD – pinning all system calls
#104Earlier quoted context omitted.
> Proper mitigations I think stem from proper design and threat modeling. Strong, reality-based statements like "this kills these vulnerabilities," or "this kills this CVE; it delays production of an exploit by one week." And also thorough testing by seasoned exploit writers. Anything else is relying on pure luck, superstition, and wishful thinking. The comment seems to imply that "proper design and threat modeling"…
>I'm sure OpenBSD developers have very good intuition on what could be used in a vulnerability, without having to write one themselves Why? On average programmers are not very good security engineers. And the opposite - security engineers are often not a good programmers. If your mitigation doesn't stop any CVE that's being exploited right now in the wild, it's an academic exercise and not particularly useful IMO. >A…
>> I'm sure OpenBSD developers have very good intuition on what could be used in a vulnerability, without having to write one themselves
> Why?
Exactly, POCOGTFO! :)
But wouldn't providing such a proof-of-concept implementation immediately render a bull's eye on all pre -current (and/or not appropriately syspatched) boxes in the wild?
Re: OpenBSD – pinning all system calls
#105Earlier quoted context omitted.
OpenBSD disabled hyperthreading before speculative execution attacks were in the wild. In the words of Greg K-H “OpenBSD was right”. There probably is some amount of security theatre in OpenBSD but they have also mitigated attacks which weren’t even known to exist.
OpenBSD doesn't even have hyperthreading? Why does anyone use this OS? The Linux developers put in a lot of effort to make hyperthreading actually work for their kernel rather than ignoring it.
It has, but it's disabled by default.
You can find more info on the relevant commit here: https://undeadly.org/cgi?action=article;sid=20180620110722
Some delightful de Raadt finger-wagging along with HN discussion here: https://news.ycombinator.com/item?id=17829790
Re: OpenBSD – pinning all system calls
#106Earlier quoted context omitted.
>I'm sure OpenBSD developers have very good intuition on what could be used in a vulnerability, without having to write one themselves Why? On average programmers are not very good security engineers. And the opposite - security engineers are often not a good programmers. If your mitigation doesn't stop any CVE that's being exploited right now in the wild, it's an academic exercise and not particularly useful IMO. >A…
> If your mitigation doesn't stop any CVE that's being exploited right now in the wild, it's an academic exercise and not particularly useful IMO. If your only metric of security is "fixed CVEs", then you're rewarding mistakes that were rectified later, and punishing proactive approach to security that actually makes fewer CVEs appear in the first place. And Theo's reputation and influence on the security is evidence…
> E.g. he created OpenSSH.
OpenSSH is a fork of Tatu Ylönen's SSH from when it was not proprietary.
Re: OpenBSD – pinning all system calls
#107Earlier quoted context omitted.
Suppose your hoop probabilities are 25% and that you have two hoops so that the probability of jumping through both is 25% * 25% = 6.25%. You can reduce the size of one of the hoops in half, changing the probability to 25% * 25%/2 = 3.125% You can also add a third hoop, in which case the probability is 25% * 25% * 25% = 1.5625% 1.5625% < 3.125%, so adding a third hoop is better than shrinking one of the two existing…
The probabilities aren't independent. The person jumping through the first hoop is probably more able than average. Therefore, any additional hoop - if it doesn't require a completely orthogonal skill - is less selective.
I think it depends on what the "probability" is meant to indicate. You're correct if it's meant to indicate whether a particular attacker can get through a particular hoop. But probabilities could also refer to e.g. the chance that it's possible to get through a particular hoop, period. Or the fraction of some input space which corresponds to an exploitation.
Re: OpenBSD – pinning all system calls
#108Earlier quoted context omitted.
Implying that OpenBSD has not considered Rust? There is plenty of discussion on misc@ already (for example [1]) and while it certainly can be "ranty", I am sure if one reads it in good faith you get a fairly nuanced picture. [1]: https://marc.info/?l=openbsd-misc&m=151233210523661&w=2 Look, I think a lot of programmers and managers fail to understand the number of factors one needs to consider and how it scales with…
> Implying that OpenBSD has not considered Rust? No, not at all. OpenBSD may consider Rust all the time and it may still be not the right language for them. But Rust might be the right language for some greenfield projects (which means, no rewrite), in ways that doesn't apply to a decades-old OS
Thanks, I do think we are largely in agreement. Despite me somehow needing a wall of text to communicate it all.
Re: OpenBSD – pinning all system calls
#109Earlier quoted context omitted.
>I'm sure OpenBSD developers have very good intuition on what could be used in a vulnerability, without having to write one themselves Why? On average programmers are not very good security engineers. And the opposite - security engineers are often not a good programmers. If your mitigation doesn't stop any CVE that's being exploited right now in the wild, it's an academic exercise and not particularly useful IMO. >A…
>> I'm sure OpenBSD developers have very good intuition on what could be used in a vulnerability, without having to write one themselves > Why? Exactly, POCOGTFO! :) But wouldn't providing such a proof-of-concept implementation immediately render a bull's eye on all pre -current (and/or not appropriately syspatched) boxes in the wild?
That’s why you invest in closing the patch gap.
Re: OpenBSD – pinning all system calls
#110Earlier quoted context omitted.
cough go cough Although it is periodically useful to be able to copy a binary to some random Linux server and know it will work.
Even for go it should actually work as-is: the syscalls should exist statically in the binary, so the loader can enumerate and whitelist them. What gets blocked is the system constructing the entire thing at runtime, or at least setting the syscall number dynamically.
Isn’t that how all syscalls work? The syscall number typically goes in a register.