Comment by ozereray1

If it is, it's not very good. They provide the source for the exploit, great, but the explanation of the exploit is terrible: just seven pithy bullet points. It's not really clear what's going on without a lot more digging. The discussion of mitigations is better, though.

Context: I teach a college-level security class where undergrads do stack-smashing-like attacks (and every year a handful of talented students manage to pull off things like ROP attacks, analysis of entropy for a layout randomizers, or side-channel attacks). All of their writeups are much better than this one.

The point of the GPs comment wasn’t that there isn’t enough developers. It was that the OPs comment of “most heavily audited code bases” was an exaggeration.

It's a tricky balance. I certainly don't want my devices to have a ton of cruft installed which I would never need. But I also certainly don't want to have to spend a month after getting a new device just getting it into usable shape so I can use it for whatever I got it for. I used to think the second concern is very small since I do not get new devices that often, but turns out it's not true, it's often enough that I really want the OS to contain a lot of things from the start. OK, maybe not NetBIOS but wide enough device support and other capabilities so it would be useful for me. And if it's not, I - and most other technically competent, but busy people - would move on to something that provides that service. Goes double for people that are not technical, obviously.

Sure, I don't disagree in principle with the idea that a smaller attack surface is better than a larger one, nor with the idea that explicitly enabling things is better than having to locate and disable services you didn't even know were running.

But saying "only two remote holes" gives the impression that all of OpenBSD is secure and that it's the most heavily scrutinized codebase in the world, it's bulletproof, etc.

It's not.

My toaster hasn't had a remote hole in a heck of a long time either, but then again it doesn't do anything other than make toast.

The default install of OpenBSD doesn't do anything, so the fact that it hasn't had a remote hole in forever isn't saying much.

> Which is almost certainly a combination of the complexities of govt IT procurement, the needs of non-technical users who may only be familiar with Windows & MS Office, and the enterprise management features of Windows that aren't as good in most other OSes.

... and if I were to guess, there's definitely backroom deals between the US government and Microsoft. There's no way all the phone home stuff is even included in "Windows for SCIF".

>And no, OpenBSD is not the most secure OS out there, and very few serious people claim it is.

My beef is that lots of uninformed people have been bamboozled into thinking it is more secure than it really is.

>But sure, keep talking about the two holes if you want.

Thanks for the go-ahead, I probably will.

Yes, but with the exception of sshd (which you get asked about during install), none of these things (NONE!!!) is enabled by default.

I am probably misremembering, but the OpenBSD documentation used to even explain how to disable inetd if you were too paranoid to use that. It is now disabled by default, and--I just checked one of my running systems--my machine does not even have an /etc/inetd.conf file. Most of the things running on a default install are init, cron, slaacd, a handful of gettys, ntpd, syslogd, and sndoid. Arguably sndiod is the only thing you could really remove from that list.

You're forgetting their SMTP server had a remote root RCE a few years ago, their IPSec server an authentication bypass, etc.

Both of these were logic bugs and not "insecure C code".

But if you look at the security track record of opensmtpd, you'll quickly see that "Only two remote holes in the default install, in a heck of a long time!" Does not relate to the base system, but to the "default install" - that is; only sshd listening (and possibly pf).

IMNHO more interesting than bickering over the "secure" label, is all the work openbsd has done and is doing to develop stuff like pledge.

It doesn't matter as they are not enabled by default.

So even if they allow unauthenticated code execution as root or kernel by default when started, it would not count for the "remote hole in default install" claim.

You could as well just not enable network by default. Which makes Windows 95 safer than OpenBSD.

You're not being intellectually honest. Most of those things are disabled by default, so if the httpd had a remote hole, but was disabled by default, then that's not "pArT oF tHe DeFaUlT iNsTaLl" and thus not technically covered by their vaunted claims, and you know it.

So, not OpenBSD, then. I think we're on the same page.

It’s clear from anyone trying to adopt MTE on ARM that there are just _a lot_ of memory-related bugs all over the place.

Where did you report those coreutils issues?

No language is safe, but I assume you mean memory safety in particular. Alternatives are to formally verify the C code to be memory safe or to add some memory safety features to C. Both certainly simpler and cheaper than rewriting everything.

Whether memory safety is really that important is also not clear. Most people get hacked because they run old software or insecure configurations. So a language such as Rust which creates more supply chain risks seems problematic.

It has needed some fixing over the years. errno was one thing. There have been a number of things in that vein, where Bernstein relied upon 1989 C or even K&R semantics and suchlike.

But compared to some other code from the 1990s, it has lasted the test of time quite well.

* https://jdebp.uk/Softwares/djbwares/

He surely also had to face his share of C issues, here advocacy for "Boring C" in 2015,

https://groups.google.com/g/boring-crypto/c/48qa1kWignU/m/o8...

There have been exploitable vulnerabilities in DJB code.

His apps were some of the worst i've ever seen, usability wise.

No. I tried his code too.

Nobody.