What is this website about?
What is OpenBSD?
In the words of Wikipedia:
OpenBSD is a free and open-source, security-focused, Unix-like operating system based on the Berkeley Software Distribution.
Why was this website created?
Someone was bragging on IRC about how secure OpenBSD is compared to everything else, but this came without concrete evidences.
Tired of having to endure this once too often, time was spent documenting OpenBSD’s security features:
- where are they coming from?
- against what are they defending?
- how successful are they?
Because, in the words of Ryan Mallon:
Threat modelling rule of thumb: if you don’t explain exactly what you are securing against and how you secure against it, the answers can be assumed to be: “bears” and “not very well”.
But there are not a lot of public exploits against OpenBSD, so it must be secure!
But OpenBSD has a lot of mitigations, so it must be secure!
Someone even made a fun picture:
Unfortunately, having a lot of mitigations, doesn’t mean that they’re good.
Only two remote holes in the default install, in a heck of a long time!
Two remote public holes in the default install, as in “unauthenticated remote code execution”. How many local privilege escalation? How many remote/local denial of service? How many remote code execution in software not present in the non-default install? Other operating systems didn’t have many unauthenticated RCE either…
This metric alone isn’t enough to assess the security of an operating system.
How should one properly design and implement mitigations, Mr. Smarty Pants?
Halvar Flake wrote a nice little summary about this in July 2019, quoted here verbatim:
Before you ship a mitigation:
- Have a design doc for a mitigation with clear claims of what it intends to achieve. This should ideally be something like “make it impossible to achieve reliable exploitation of bugs like CVE1, CVE2, CVE3”, or similar; claims like “make it harder” are difficult to quantify. If you can’t avoid such statements, quantify them: “Make sure that development of an exploit for bugs like CVE4, CVE5 takes more than N months”.
- Pick a few historical bugs (ideally from the design doc) and involve someone with solid vuln-dev experience; give him a 4-8 full engineering weeks to try to bypass the mitigation when exploiting historical bugs. See if the mitigation holds, and to what extent.
- When writing the code for the mitigation, especially when it touches kernel components, have a very stringent code review with review history. The reviewer should question any unwarranted complexity and ask for clarification.
Follow good coding principles - avoid functions with hidden side effects that are not visible from the name etc. - the stringency of the code review should at least match the stringency of a picky C++ readability reviewer, if not exceed it.
He also gave a great keynote at BSides Zurich 2017 on the topic: Repeated vs. single-round games in security.
Why was this website made public at a conference? Why didn’t you work with the OpenBSD community?
Because the OpenBSD community is notorious for not being nice and welcoming:
- They’re proud of not having a code of conduct, and were mocking FreeBSD for adopting one.
- Theo is known to routinely call people names and being harsh, calling people assholes, inaccurate jerk, …
This website was done because studying mitigations is fun, not to get involved in a huge flamewars or endless bike-shedding on mailing lists.
Who’s behind this website?
A couple of people helped: ts[…], cr[…], st[…], ne[…], sp[…] & pi[…], mv[…], Ob[…], jo[…], ja[…] & ma[…], ss[…], …
I’ve found a mistake!
Please do send me an email so I can fix it :)
Keep also in mind that the website is a work in progress, help to improve it is more than welcome.
Where can I get the kick-ass “Got hacked” OpenBSD t-shirt that stein was wearing on stage?
Why so much negativity and sarcasm on the quotes webpage?
Because I didn’t managed to find positive quotes from security professionals about OpenBSD, but if you know any, I’ll be happy to add them.
What sources were used?
- The exp_moosecox.c exploit, spender, 2009
- The insecurity of OpenBSD, allthatiswrong, 2010
- Notes on abusing exit handlers, bypassing pointer mangling and glibc ptmalloc hooks, Warren Levin, 2017
- Do randomized PIDs bring more security?, stackexchange, 2017
- OpenBSD security features, Wikipedia, 2019
- Documentation for the PaX project, the PaX Team, 2015
- grsecurity and PaX patches, Spender and pipacs.
- Grsecurity and PaX Configuration Options, Wikibooks, 2019
- Maxime Villard‘s entertaining twitter account
- Historical security features map of Ubuntu, 2019, Ubuntu security team
- A Comparison of Buffer Overflow Prevention Implementations and Weaknesses, 2004, Peter Silberman and Richard Johnson
- OpenBSD’s source code (especially the github mirror), 2019, OpenBSD developers
- The OpenBSD’s papers/events, 2019, respective authors
- The endless comment threads of Undeadly.org, 2019, respective authors and Anonymous Cowards
- r/openbsd, 2019, respective authors
- Wideopenbsd.org, 2012, hypercube
- Security Fantasies and Realities for the BSDs, AsiaBSDCon 2019 Keynote, by George Neville-Neil, mostly because it is hilariously embarrassing.
- Effective Memory Safety Mitigations, 2018, Chris Rohlf
- Syssec‘s Review of the State-of-the-Art in Cyberattacks, 2011, Syssec consortium