Quotes and testimonies
Brad (spender) Spengler
Seriously though, it’s incredible to me that an entire team of developers whose sole purpose is to develop a secure operating system can be so oblivious to the rest of the world.
In 2019, after the talk was released, he also said:
OpenBSD’s record of mitigations post-drunk-person-in-tent telling them about PaX is nothing to be jealous of. Find any security expert who writes exploits who thinks the silly syscall location “mitigation” makes any difference. Has Theo ever even written an exploit?
On a separate note, defensive security folks, and Apple in particular, loooooove mitigations. On iOS, Apple has lately been slapping proprietary mitigations around like there’s no tomorrow. But thing is, mitigations are often delicate creatures, with rather fragile assumptions. Having too many of them in one place can easily make them break one another, as happened here with execute-only memory vs PAN. And this isn’t the first time either, in my blog post about APRR it was ASLR that got broken by another mitigation, and there are a few more cases like this that I know of. As the number of mitigations around specific features increase, I expect collisions like these to become more common. But hey, something has to stay fun, right? :P
I appreciate experiments, but adding cost without real benefit is not a good showcase of efforts. I’d love to see stricter analysis of stuff
Dave (dwizzzle) Weston, Director of OS Security at Microsoft said in January 2020 about this website:
Agree this is a good analysis. Props.
Albeit he also said:
I don’t really love that whole set of super negative quotes though. Doesn’t make sense to criticize the culture of the project and turn around and do the same thing.
Chris Palmer, security engineer for Google Chrome, previously Technology Director at the Electronic Frontier Foundation, and Principal Security Consultant at iSEC Partners (now NCC Group), said in 2019:
I put a lot more faith in privilege separation and reduction than in all the mitigations. I’d be really impressed by a move to a safe language… most everyone is late to that party, so it’s a chance for someone to pull ahead if they wanted bragging rights
Federico (uid1000) Bento
Their approach to security seems to be implementing every (stupid) idea possible so that attackers just can’t keep up with such nonsense
He also said:
A bunch of masturbating monkeys https://www.openbsd.org/papers/cuug2019-predictable.pdf
Albeit he also said:
Overall bad read: https://isopenbsdsecu.re
Why does this account only retweet @grsecurity, but months late and also claim authorship?
Ilja van Sprundel
Bugs are still easy to find in those kernels. Even OpenBSD.
Chrif Rohlf, Security staff engineer at Square and member of the Black Hat review board, previously Director of penetration testing and red team at Yahoo, Principal security consultant at Matasano, said about OpenBSD' system-call-origin verification in December 2019:
The irony here is that this mitigation is intended to make exploitation of memory safety vulns harder but it breaks many memory safe languages in the process.
pledge is strong. Much prefer that approach to weak mitigations that effectively boil down to weakly held secrets
He also said in January 2020:
I don’t know who made https://isopenbsdsecu.re but its pretty thorough!
I think the OpenBSD crowd is a bunch of masturbating monkeys, in that they make such a big deal about concentrating on security to the point where they pretty much admit that nothing else matters to them.
@kingcope @CaptainKeke Well #OpenBSD has always been more of an experiment than a usable operating system
Luca (qwertyoruiop) Todesco
Is it just me or the entirety of the recent obsd “security” measures are a joke?
interesting talk about OpenBSD mitigations at #36c3, slides @ https://isopenbsdsecu.re, what do people think?
The complaints are legitimate, but the hilarious part is how much more secure OpenBSD is despite such awful development practices. It’s almost like underlying design of privilege domains & security model matters more than good practices…
Niklas (niklasb) Baumstark
It’s insane how far this is detached from reality (which is heap-based memory corruption) I wonder where they get their “insights” from or if this is just random guessing at what the current exploitation meta game is
Daniel Micay is a “security researcher working on mobile privacy/security. Memory allocators, compilers, language design, attestation, sandboxing, permission models, etc.”. He known for his work on CoperheadOS/GrapheneOS, as well as hardened_malloc implementation.
He said in April 2019:
The hardening in OpenBSD doesn’t include bringing a meaningful security model to the desktop software stack. It doesn’t do anything substantial to secure those higher levels of the OS. There’s even less work on overhauling that software stack with a security model outside Linux but there’s no truly meaningful progress on that anywhere right now.
OpenBSD focuses on low level exploit mitigations and privilege separation for a minimal userspace base OS. Most of their time is spent maintaining the OS and playing catch-up with the functionality, hardware support and performance elsewhere. It doesn’t actually leave them with a lot of time to work directly on mitigations and they haven’t bought into important things like memory safe languages or the same concepts of privilege separation for the kernel and drivers. It doesn’t have all of the mitigations present elsewhere like CFI or even a few much older things so it’s not a clear win in that are compared to aLinux [sic] based OS focused on security.
An anonymous exploit connoisseur
This is an excerpt from a private email by a friendly proofreader and OpenBSD exploit enthusiast, late 2019:
An important point I’d like to make is that I am particularly surprised to see the very poor design, and general lack of skill, that comes out of OpenBSD. As far as I can tell, the OpenBSD people like to make bold claims and insult the others, but when it comes to actual security, they don’t deliver. Many of their “security features” have little to no practical use, and the code they produce is generally half-baked, if not completely buggy. As well, they don’t do actual vuln research and security engineering.
An other exploit connoisseur
This was the conclusion of an informal chat with a friendly professional (mostly web browser) exploit writer, about some OpenBSD mitigations, late 2019:
One of the advantage of OpenBSD is that even if their mitigations aren’t super-effective, an exploit written for a particular software running on Linux won’t be straightforward to port on their platform, granting them the time to update it. It’s the lamest mitigation ever, but it’s kinda-working, especially because nobody is spending time porting exploits to OpenBSD.
We’re currently acquiring #0day exploits (privilege escalation or RCE) for the following operating systems: OpenBSD, FreeBSD, NetBSD, Ubuntu, CentOS, Debian, and Tails. For related inquiries or submissions, contact us: https://zerodium.com/submit.html