FreeBSD – A Lesson in Poor Defaults
vez.mrsk.me
vez.mrsk.me
You know what? I appreciate that. The security people want to break stuff all the time and it is terribly annoying to have to go and fix stuff. Sometimes you even can't, there is software out there that only supports older TLS ciphers and you have to keep an old browser around to access it. And inevitably that old browser is going stop working at some point too... If you are so anal about security, the knobs are there to make adjustments. For the rest of us, stop breaking shit!
If something is unexpectedly insecure, you will probably not notice until it's too late.
I think the admittedly annoying security people are right in this instance.
It is not like you can go and tell your government you won't pay your taxes because their tax system doesn't work on newest OS version because it is outdated... Or rather, you can, and then the government will happily shoot you.
I get that access to an unknown site with unknown content with a dated cipher should _by default_ break. By default!
I do not get that I cant't access a well known site any longer because that site that I don't control just doesn't update their cipher. In that latter case I need to and want to be able to override the default recommendation of the gurus --- without having to rebuild my client!
You make configuration available. Most of these disabled-by-default protocols can be enabled by a user who really knows what they are doing (and isn't just saying so). A few might have been outright removed from the code base. In that case, you really need to know what you are doing, but you can still bring them back by installing a custom patch or downgrading the program in question.
I think it is a good idea to create friction along pathways that are probably mistakes. The people who really need to go down that path will put in whatever effort is necessary, while people who are motivated by the path of least resistance will be nudged in a safe direction.
I heard cryptographic weakness are sometimes used to break tivoization/DRM but I don't consider people who do this threat actors - an owner should be free to run any software on own hardware. And an attack on device you hold in hands is completely different than say an attack on remote FreeBSD server.
There is a communications problem within all of this. If I break a cryptosystem, I do not have permission by either party (customer/employer) to go and write a blog post about it. All in the name of "protecting our users". The same goes for my colleagues around the world, as such it gets very little attention.
As for threat actors misusing it, there is a value/effort calculation in their world where it is often easier to access content through other means. Crypto is hard - for everyone, even threat actors - so you won't often see them trying to tackle it.
For example, how does Debian handle this? Debian has testing, then it freezes and it moves to stable.
- Debian 9 (Buster) was released in July 2019 [1] - Debian 9 is LTS supported until June 30, 2024 [2]
Looking, it seems 12.0 was released in December 11, 2018 [3]. From a note on the Wikipedia page,
> The timeline shows that the span of a single release generation of FreeBSD lasts around 5 years
So comparing against Debian looks like a fair comparison.
[1] - https://en.wikipedia.org/wiki/Debian
For example, Fedora will upgrade package versions and defaults often, because they release often. RHEL, which is made from a frozen Fedora version (for the most part), won't even upgrade versions of installed packages, but will instead back-port fixed into the old versions, so you are ultimately as stable as can be expected from running an OS, as without new versions and new features in packages there's little to worry about with regard to changing behavior.
Usually, that means you're responsible for knowing what to set for package defaults, and while they might change the default for a package such as OpenSSH at a point release (or in critical situations as a normal update), the way their config management works is that your existing systems will likely not see any change, but a new install might (there are different actions in different situations, but it's documented).
The main exception to the above is point releases, which are every six months or so, where they may take a subset of packages and allow newer versions of those to allow for new features, but with copious amounts of testing to hopefully catch any problems that might introduce. In some cases they may deem it safer to back-port a feature than to change the shipped package to a newer version (this is common for some kernel features, for example).
What this means in practice though is that you can choose to do regular security and bugfix updates automatically but stage and test point release updates, and do one or two systems to test whether it introduces problems.
Those are the benefits of an enterprise distributions, such as RHEL (and free derivatives such as CentOS and Rocky Linux) and Ubuntu LTS releases. The downside, if you can consider it that, is that they are so stable that five years later you'll find you're still running that same distro and your problem is that that majority of the software stack you're running is very old, and the annoyances from that continue to mount, and harder to migrate to something newer because there's been so much change in all the software that you can't assume that the configs will work cleanly.
Security's a thankless area since you have no way of knowing which exploits were prevented by security measures. It's like precautions against fires: You have no way of knowing how many thousands of deaths were prevented by measures taken to prevent fires from starting - and you never will. It even affects our politics: We don't know how many deaths were prevented by the measures taken to save lives from the present pandemic, and as a result some people complain.
Any reference on this? Thanks!
I have some old servers with older iLO that suffer from this, and I'm only using them on a local network. Similarly, I have used the "None" cipher on a local network to sync a lot of data from my old NAS which definitely did speed things up (that box didn't have AES-NI, ancient processor).
They don't have to enable it out of the box but having it in there when needed is definitely helpful.
On another point, that 'huge diverging patch' from OpenBSD PF was all about multithreading and dramatically improving performance on modern systems, it's not like it was done for the sake of it... But it should have been kept more up to date, yes.
If you need broken old stuff to run, the onus must be on you to disable the security, not the other way around.
When you weaponize interviewing decisions to enforce cultural homogeneity and agreement with your own opinions, you are reducing diversity and excluding people who are intelligent enough to recognize nuances that break rules of thumb.
Anyone that can explain both the trade off and when it is appropriate to make would be unaffected by this. The default must be security - we don't live in the 80s anymore.
The flip side is that shit will work. For everyone. Even people you didn't even know and that should not have access to said shit.
Cyphers are not deprecated daily. They live on for many years.
(you might need to toggle a different option but I forgot the name)
> Some things fall into the category of "we can't change this overnight because we have users, but it will be changing in the future".
I get and appreciate what’s said above. But, 6-years also seems like a long time for FreeBSD to not address some of these things.
Taking a look at the first section, "OpenSSH Modifications" - rather little of it is current. With respect to ciphers disabled by default in upstream we may follow along in main but leave them enabled in a stable/release branch, in an attempt to avoid breaking existing users while deprecating increasingly insecure options over time. We do indeed add support for tcp_wrappers back in. With respect to the base system I think the rest of the section is not applicable.
There are some absurd recommendations on here (disable TCP SACK, use TCP BBR) and the weirdest of all is why anyone who hates FreeBSD security this much would still use the OS?
The performance benefits of HT are also not at all universal. I mean, they do exist in some cases—if you’re running closely related scalar-compute- (or, better, dependency-) bound tasks that bang on the same small piece of memory, or if you run several things that are just bad at loading the CPU so HT-induced contention doesn’t matter. (The latter scenario was obviously much more important at the time HT was introduced, when neither people nor compilers were particularly good at optimizing for superscalars.) Or, though it’s not a performance benefit, it can help if you have few cores and the OS scheduler is bad at letting interactive tasks run in the presence of long-running batch ones or heavy swapping. But properly optimized multithreaded data crunching like video coding or compression doesn’t really run faster when given extra threads to run on HT “cores” rather than just leaving them disabled or idle.
Perhaps we're getting to a point that both disabled is faster than both enabled (and suffering from the mitigations penalties)
At an old job, we disabled SMT on our hypervisor hosts in an effort to mitigate some of the security issues before patches were available. We had to roll back. Without SMT, the hosts struggled to keep up with load. If I had to quantify it, I'd estimate that we lost, at least, 30% performance by disabling SMT (probably more). Those servers were replaced before I left, but I'd be interested to compare disabled SMT to enabled SMT with all the current mitigations in place.
[1] https://www.makeuseof.com/new-spectre-vulnerabilities-amd-in...
It doesn’t seem odd to me at all that this individual would continue to use freebsd while maintaining such strongly held critiques of it.
Then I found a bug (in the base FreeBSD, not Hardened-specific) that had prevented ipfw from being used on big-endian systems for several years. Years, mind you- ipfw went for years without working on big-endian systems and nobody had noticed. That was too much, and I ran for the hills.
Now, on OpenBSD, I very much miss ZFS... but that's a small price to pay in my book.
EDIT: I love it that I get downvoted for asking a question. Seriously people, get a grip.
But DragonflyBSD has Hammer2.
Page 6 especially:
https://freebsdfoundation.org/wp-content/uploads/2021/07/Sev...
Full on "hardened" ;)
This was not the case early on, and to my memory, in the early days of HardenedBSD, the relationship between the two groups could have generously been described as acrimonious. For an example, see the ASLR-on-FreeBSD debate.
Not much of a debate? You either take contribution feedback or you don't contribute. When I open a PR to some open-source project, and maintainers/contributors give me feedback, I incorporate it and don't throw a tantrum.
Everything aside, ASLR is present since 13.0 and default in 14.0. Different implementation. Usefulness of ASLR in general is another debate.
Maybe time for them to write an article on OpenBSD's pros directly instead of indirectly by attacking FreeBSD.
I still preferred filling my multi-Gb/s pipes with backups for an hour or two every night instead of having replication take most of the day at ~300Mb/s. I need backups to be replicated nightly off-site before the start of business. The largest single backup job alone would have been too slow to finish in time after a busy day over unpatched SSH. I needed a tool that's fast enough to finish transfers in the available time window. Had FreeBSD shipped an unpatched SSH I would've had to implement most of its core features in something else instead of running a multi-threaded implementation of the same symmetric ciphers.
Still waiting for a reasoned rebuttal, rather than dismissing them summarily because they like another OS.
Also, what is wrong in updating an article so it stays relevant and doesn't refer to things that have been fixed?
But if your goal is to avoid rants rather than viewing a problem from a different POV, ignoring it is the best choice.
This is a nice way to write if you want to let off steam, or have an argument on a site like this, but if you’re trying to influence people it’s not gonna work.
> FreeBSD's malloc (jemalloc) is very forgiving of buggy/hostile code compared to something like otto malloc.
Sounds vague. I'm not disputing it, as I haven't read the code of the two mallocs. But I would be curious about the details. Does anybody know what that's about? I was under the impression that jemalloc was seen as quite robust, not least thanks to doing away with free-lists (which is also true for otto malloc, as far as I can tell from cursory research).
Their links to commits, mailing list posts, etc., are cherry-picked and taken out of context to present their view.
For one example, they suggest that the FreeBSD community is unwilling to make changes to improve things, and say "some of their users like it that way though", linking to https://lists.freebsd.org/pipermail/freebsd-arch/2020-May/01....
If you actually read the thread that response is taken from (starting at https://lists.freebsd.org/pipermail/freebsd-arch/2020-May/01...) you'll see a wholly different picture: a FreeBSD developer proposed a change, there was general agreement with a small amount of opposition including the cherry-picked message, and the change was made.
The FreeBSD src git repo has hundreds of thousands of commits, and anyone can post to mailing lists, so of course it's possible to find examples of mistakes being made, or misguided posts from developers or users.
I very much welcome constructive criticism and ideas for improving the security landscape within FreeBSD.
Help me understand here. The reply by Julian is a huge overreaction. The text you quote seems to be condemning him (a user, not the developer) for fighting a seemingly worthwhile change on the principle of it being the way it was for a long time.
So doesn't that kind of prove the point that you're saying isn't true?
Dragonfly has superior architecture, performance and security, despite its much smaller team. It is a textbook example of how a small team of focused competent engineers will deliver higher quality than an heterogeneous large body of developers with no focus. They are actually scaling in a manner competitive with Linux, unlike the other BSDs.
When Matt left Freebsd, which was due to a conflict that spawned over bad technical decisions, many good developers followed him.
What was left did implicitly support bad decisions. Fine-grained locks for SMP do explode complexity and makes writing quality code that much harder. It is also a problem in Linux, which compensates with sheer manpower.
Freebsd has been a cesspool since then. Jesus, what a mess Freebsd has become.
It would also be good to read about Dragonfly's exploit mitigations. Are these documented somewhere?
I know there have been new CPU vulnerabilities found past these, but I haven't been keeping track closely.
It would help if they had an announce mailing list. Looking at older release notes seems to be a manner of digging through the users list, or guessing URLs based on the current release notes. They seem in dire need of a maintainer for the website.
0. https://en.wikipedia.org/wiki/DragonFly_BSD#Release_history
https://github.com/memorysafety/ntpd-rs
Server functionality and NTS support is on the way.
Now, there are some spinoffs like DesktopBSD, GhostBSD and HelloSystem but they're very small compared to the situation with Linux where there are several major distros.
But if your focus is security, OpenBSD would be a good alternative for sure.
Some of these recommendations in the post are wrong, so don't follow it to the letter. Post is written by an angry OpenBSD fan.
The "hardening" menu in the installer is pretty pathetic if we're being honest. "enable /tmp cleaning"... wow. I'm secure now.
Please stop with that.
>"enable /tmp cleaning"... wow. I'm secure now.
That's one point, you know that. And then you do the "negative and dismissive comments" too.
>pretty pathetic if we're being honest
True it is...but not the hardening dialog or secure-level.
[1]: https://www.freebsd.org/cgi/man.cgi?query=release&apropos=0&...