That Talk of isopen ... is a joke! He start agreeing with puffy supremacy.
All these years I have made jokes with fbsd guys and some "hax0rs" during event's. The reason is simple, they attack OpenBSD community and then always end with a lack of arguments. Even with Qualys recent discoveries, which in my personal opinion they could send all issues together, they preferred to do on that way. That said, I still asking, why the other projects do not try at least start to make their operating system more secure by default? OpenBSD since the begin the main focus is paranoid security. They will take years to have a solid rock like OpenBSD. Also that said, all mothafuckaaa which keep send posts like this, put your head within your ass and just accept: you are OpenBSD user! Em dom., 10 de mai. de 2020 às 01:45, Stéphane Aulery <saul...@legtux.org> escreveu: > 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  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" , 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, > > ------------------------------------------------------------------------ > >  https://isopenbsdsecu.re/about/ >  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 > >