Hello,
Le 07/05/2020 à 16:00, i...@aulix.com a écrit :
Can you please comment negative appraisal from the following website:
https://isopenbsdsecu.re/quotes/
I did not want to hurt anyone, just looking for a secure OS and OpenBSD looked
very nice to me before I have found this website.
This explanation [1] from the author of the site should be enough for you:
----
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”.
----
The quotes were chosen to be especially aggressive but we could find as
many against other operating systems.
For me it's on the same level as "The UNIX-HATERS Handbook" [2], just a
big ball of hate and FUD.
After full reading, out of 52 exposed points there are 4 frankly against
OpenBSD, 12 for OpenBSD and all the rest is opinion and filling.
It wants to be impressive, but it’s just swank of a meticulous hater.
Regards,
------------------------------------------------------------------------
[1] https://isopenbsdsecu.re/about/
[2] https://web.mit.edu/~simsong/www/ugh.pdf
------------------------------------------------------------------------
Mitigations
Arc4random
[...] Nowadays, arc4random in userland is available on various
platforms, even when not being natively implemented, thanks to libbsd.
NetBSD, FreeBSD, Linux, … have all moved to a ChaCha20-based CSPRNG.
Even Tor is now using some of its code, for performance reasons.
OpenBSD took inspiration from Linux two decades ago, but nowadays, it’s
the other way around, OpenBSD is driving the CSRPNG game!
OK.
ASLR
[...] OpenBSD randomizing everything is neat, and forces attackers to
find/create better leaks. But nowadays, all the modern operating systems
have those kind of mitigations, are are now focusing on killing bugs
exploitable when an attacker has some reading capabilities.
And what are these modern OSes? OpenBSD is a fossilized and archived OS
on archive.org?
Atexit hardening
[...] In the glibc, the pointers to the function are obfuscated with a
rol+xor via the PTR_MANGLE macro against a secret, which is roughly
equivalent to what Windows is doing. This mitigation is completely
bypassed with an arbitrary read: get the secret, obfuscate the pointer
to your payload, done.
Musl has no hardening at all
On OpenBSD, the pointers are stored in a read-only memory zone, only
made writeable when __cxa_atexit is called. To bypass this, an attacker
would need to get code execution to modify the permissions of the memory
zone.
Where is the point?
Development practises - Development practises
OpenBSD got no continuous integration system, and apparently build
breakage are, according to the FAQ, happening from time to time [...]
There is a code style, but since it’s not automatically enforced, if
only because there is no CI.
The VCS used is CVS, the Concurrent Versions System [...]
This is not what makes security!
Development practises - Code reviews
OpenBSD claims that they have “between six and twelve members who
continue to search for and fix new security holes”, but it seems that
this doesn’t prevent low-hanging bugs from entering the codebase, for
example: [...]
Ah, because those who don't read their code are more likely to find errors?
Development practises - Security advisories
OpenBSD is publishing security issues on its Errata pages, but doesn’t
provide much context nor analysis. [...]
Ok, that's a point, but is it necessary to point to the way of
reproducing an exploit after having patched it? It is a practice,
nothing more, which neither adds to nor takes anything away from security.
Disk encryption
[...] This is looking like a solid design, pretty similar to what LUKS
is doing.
Unfortunately, it doesn’t support using a TPM or an enclave (like
Intel’s SGX, AMD’s SEV, …) to perform key-derivation and prevent offline
bruteforcing.
Pathetic.
Embargoes handling
OpenBSD isn’t usually included in security embargoes anymore, likely
because they have the bad habit of not playing well with them, although
they never technically broken one. [...]
And should we play the game of the one with the cleanest ass?
Explicit_bzero and bzero
[...] While it might get optimized away when using static linking with
LTO, it’s sill a neat way of improving forward secrecy, by trying to
remove cryptographic materials from memory as soon as possible.
Where is the problem? OBSD +1
Fork and exec
[...] It seems that OpenBSD was the first to add an exec after the fork
for security purposes, and this is indeed an excellent idea, reducing
the number of reusable information an attacker can infer/reuse between
different executions.
OBSD +1
Fuzzing
Fuzzing is not a practice that allows you to specifically find security
bugs and even less to find all software bugs. So nothing to do with
security even if it is a useful tool among others.
KARL (Kernel Address Randomized Link)
OBSD +1
L1 Terminal Fault (L1TF), aka Foreshadow
[...] On the same day, he committed some mitigations, inspired from the
ones from “other systems”, namely stuffing the L1 cache with garbage,
likely murdering the performances, since Linux allows to do the same,
but advises against it, for … performance reasons. As for userland,
OpenBSD simply disables hyper-threading, which is the most efficient
mitigation, but you lose hyperthreading support.
Shame on Intel. OBSD +1
Lazy bindings
[...] Unfortunately, being able to call kbind is just a matter of
leaking the cookie, which is conveniently stored in the
.openbsd.randomdata section, and to ret2ld in the middle of _dl_bind,
which is the function calling kbind. The aforementioned cookie is stored
in an unsigned long, usually meaning 2^32 different values, which is a
good amount of entropy. [...]
He dislike this feature, which could be removed like did musl, but OBSD
keep it securly. So, where is the problem, it's his opinion?
Libc symbols randomization
Cites https://twitter.com/halvarflake/status/724889896389849088
Should have cited also:
halvarflake
@halvarflake
·
26 avr. 2016
@mkolsek
@cynicalsecurity
@solardiz
Not saying ROP has 0 relevance, just that the relevance is a fraction
of its perceived importance.
Mitja Kolsek
@mkolsek
·
26 avr. 2016
@halvarflake
@cynicalsecurity
@solardiz
Okay, this is softer than "Only academia still cares about ROP" and I
agree.
Library order randomization
But it doesn’t add complexity, hinders performances nor observability,
and improves a bit ASLR, so why not.
OBSD +1
Mandatory W^X in userland
W^X isn’t enought to prevent the introduction of new arbitrary code by
an attacker.
It’s interesting to note that NetBSD, from which OpenBSD was forked, has
a working implementation of PAX_MPROTECT since 2006.
No failure there, it's mitigation, no silver bulet.
MAP_CONCEAL
MAP_CONCEAL is a flag that can be passed to mmap, or used via
malloc_conceal(3) and calloc_conceal(3), to prevent memory to be dumped
in coredumps. It was added by Scott Soule Cheloha, in February 2019, in
OpenBSD 6.5.
[...]
It’s a good way to prevent sensitive materials from being written to the
disk in case of a crash producing a coredump.
But Ted Unangst said on Hacker News in 2019:
So the name conceal was chosen to allow some flexibility, like
prohibiting ptrace. The idea is to keep secrets from escaping into other
programs. Other programs generally can’t read swap, so that’s not a concern.
This is the opinion of a single person while OpenBSD implements
MAP_CONCEAL. It seems that the author is hunting down the slightest
words. It's obsessive and pathological.
MAP_STACK
[...] This mitigation adds a bit of complexity, but no overhead nor
hinders debuggability, and the check-stack-pointer-on-pagefault trick
might annoy an attacker for a couple of hours. It’s definitely not worth
breaking the ABI for this.
Opinion.
Microarchitectural Data Sampling, aka Fallout, RIDL and Zombieload
Nothing wrong there.
Missing mitigations
Valid point, but choices have to be made. You can't have everything in life.
NULL-deref in kernel-land to code execution
Valid point.
Packages updates
[...] Unfortunately, things are a bit less bright on Firefox’ side: in
January 2020, there was some uncertainty about be able to keep the
non-ESR version up-to-date, which was at this time vulnerable to at
least MFSA2020-03, because its too complicated to package it.
This have been solved.
[...] But the vast majority of packages are kept up to date, which is
impressive for such a small project!
OBSD +1
Papers, academic research and threat model
OBSD is not a research OS.
cf. https://www.mail-archive.com/misc%40openbsd.org/msg128001.html
Theo de Raadt Thu, 03 Apr 2014 21:26:23 -0700
> The explanation is simple, we traded about 5% of application
> performance for built-in ALWAYS-ENABLED security mitigations that we
> found in research papers, or elsewhere, or invented ourselves.
> Because machines keep getting faster, our community barely noticed the
> performance loss.
Passwords hashing
OBSD +1
PID randomization
[...] I don’t think that this brings any additional security, but why not.
Opinion.
Pledge
[...] Pledge is a really effective mitigation based on attack surface
reduction, useable and used, that doesn’t add complexity nor hinder
inspectability. It is what seccomp should have been.
OBSD +1
Position independent code
[...] Position-independent executables (PIE): OpenBSD 5.3 was the first
widely used operating system to enable it globally by default, on seven
hardware platforms. Implemented in November 2008 by Kurt Miller and
enabled by default by Pascal Stumpf in August 2012.
This statement is a bit misleading: OpenBSD was the first “widely used
operating system” to enable PIE by default on 7 different CPU
architecture, sure, but:
I think that Gentoo Hardened and Adamantix were/are as much used as
OpenBSD, and they did have PIE everywhere years before. AND EVEN IF THEY
DON’T, Apple was the first one to enable PIE by default.
Android was the first one to enable PIE by default on 6 different
architectures (x86, amd64, arm7, arm5, mips32, mips64)
Fedora was the first one to enable PIE by default on 8 different
architectures and more.
This is an excellent mitigation, improving ASLR by not having the binary
mapped at a fixed offset, and subject to the same threat model.
So, he says that Gentoo activated PIE in 2003 but in fact it is not
certain, and even less for all architectures. Fedora activated PIE for
some important programs but not all. Apple activated PIE before OBSD but
only for one architecture.Apple activated PIE before OBSD but only for 6
architecture. So, for me the sentence of OpenBSD’s website is ok.
OBSD +1
Privsep and privdrop
Nothing wrong there. Why talk about it?
RELRO
[...] RELRO is a pretty standard mitigation [...]
pretty standard, really, while this is only implemented by Redhat,
Ubuntu and OpenBSD? Work in progress, nothing wrong.
OBSD +1
RETGUARD and stack canaries
Opininon.
Rootless Xorg
A thing of the past...
ROP gadgets removal
[...] But removing ROP gadgets the way OpenBSD is doing it doesn’t add a
large amount of complexity, doesn’t harm performances nor debuggability,
so why not, but it doesn’t make exploitation significantly harder, at all.
So, where is the point? Opininon.
Secure boot and trusted boot
Opinion. The author does not understand the positions of OpenBSD.
Secure levels
[...] So much for not keeping useless legacy code around, especially in
the kernel.
Ok, good point.
Setjmp and longjmp
While OpenBSD’s hardening for setjmp/longjmp are decent, Microsoft’s
ones are both simpler and way more effective.
So, not bad for OBSD.
Signify
[...]Unfortunately, it has a couple of shortcomings:
If the key for the next release is lost, a trust path would have to
be reestablished from scratch
There is no revocation mechanism, if the key is stolen, all what
OpenBSD can do is to tell people that they shouldn’t trust the key
anymore. Altought I guess that the OpenBSD people could simply sign a
compromise notice with the key.
The trust-path can hardly be transitive without relying on other
tools: one has to get the key directly from a trusted OpenBSD developer.
But on the other hand, as tedu said, since the keys are pretty small,
people can plaster them everywhere. Unfortunately, for people that can’t
attend various OpenBSD events, living in a place controled by a global
adversary, they have no way to bootstrap the trust without relying on
something else than signify.
1. If, If...
2. Nothing wrong there.
3. Boo. Big brother is watching you.
SMAP, SMEP and their friends
This is a nice and cheap (since it’s implemented in hardware) mitigation
forcing attacker to put their payload into kernel-land, instead of
simply being able to jump to user-land.
OBSD +1
Spectre v1 — CVE-2017-5753
[...] As spender snarkily highlighted in March 2018, OpenBSD has no
mitigation, not even manually removing gadgets, against Spectre v1: the
only solution there is to upgrade the hardware.
It is valid for everyone. So?
Spectre v2 — CVE-2017-5715
Nothing wrong there. Why talk about it?
Spectre v3, aka Meltdown — CVE-2017-5754
Nothing wrong there. Why talk about it?
SROP mitigation
[...] An attacker can simply jump at the end the sigtramp function, and
bypass the cookie via an arbitrary read, but it’s better than nothing, a
bit like stack cookies.
Nothing wrong there. Why talk about it?
Stack clash
Hum, like Embargoes handling.
Stance on memory-safe languages
Ok, if it is the panacea show us another OS much used rewritten with one
of its languages.
cf. https://marc.info/?l=openbsd-misc&m=151605305629876&w=2
Support of %n in printf
Nothing wrong there.
SWAPGS — CVE-2019-1125
Nothing wrong there.
Tarpit
Nothing wrong there.
TCP SYN cookies
Valid point.
TIOCSTI hardening
Nothing wrong there.
TRAPSLED
[...] I don’t think that there is a single use-case for this.
Opinion.
Unveil
OBSD +1
Userland heap management
[...] Otto malloc is an impressive piece of software, one the first
seriously hardened allocator, and still the most secure one publicly
deployed in production.
OBSD +1
W^X
[...] Having no memory both writeable and executable is an excellent
mitigation against the introduction of new code by an attacker, both in
kernel-land and in user-land, forcing attackers to use more convoluted
ways to achieve arbitrary code execution.
Unfortunately, OpenBSD doesn’t keep track of the mappings, and doesn’t
prevent a writeable one from being mapped read-executable, like PaX’
MPROTECT or iOS are doing, as mentioned in WX refinments.
Hum. Bad player.
W^X "refinement"
Maybe a valid point, but this mitigation is fresh.
--
Stéphane Aulery
