FreeBSD 14.0-RC2 Pulls In OpenZFS 2.2, OpenSSH 9.5p1

[phoronix]

Phoronix: FreeBSD 14.0-RC2 Pulls In OpenZFS 2.2, OpenSSH 9.5p1

FreeBSD 14.0 is preparing for release in early November as a big update to this leading BSD operating system. It's going to be a great release and Friday's FreeBSD 14.0-RC2 milestone landed some last minute updates...

https://www.phoronix.com/news/FreeBSD-14.0-RC2

[kylew77]

FreeBSD was my first BSD daily driver. It is a fantastic system, BUT their repeated security holes make me reluctant to use it in production on my own systems. It feels way less secure than Linux and of course it's BSD counterpart, OpenBSD. Thank God FreeBSD 14.0 is coming with ASLR by default enabled.

[pong]

FreeBSD was my first BSD daily driver. It is a fantastic system, BUT their repeated security holes make me reluctant to use it in production on my own systems. It feels way less secure than Linux and of course it's BSD counterpart, OpenBSD. Thank God FreeBSD 14.0 is coming with ASLR by default enabled.

Interesting, I haven't kept track for many years of their security track record vs. LINUX.

I would have guessed they'd have kept up as well or better than LINUX wrt. code generation security option use / mitigations / etc. though don't recall anything about how
mandatory access controls and such may apply to the newer BSDs vs. selinux, apparmor, what not.

BSDs had lots of jail / chroot stuff forever though IDK if there's anything about cgroups or other containerization etc. on LINUX that's now much superior to whatever BSDs ship.

Using a BSD in a desktop / workstation use case certainly would make overall security much more complex to maintain vs. a more typically locked down and low attack surface typical CLI server setup which is mostly what I used BSDs for back when.

[Luke_Wolf]

Interesting, I haven't kept track for many years of their security track record vs. LINUX.

I would have guessed they'd have kept up as well or better than LINUX wrt. code generation security option use / mitigations / etc. though don't recall anything about how
mandatory access controls and such may apply to the newer BSDs vs. selinux, apparmor, what not.

BSDs had lots of jail / chroot stuff forever though IDK if there's anything about cgroups or other containerization etc. on LINUX that's now much superior to whatever BSDs ship.

Using a BSD in a desktop / workstation use case certainly would make overall security much more complex to maintain vs. a more typically locked down and low attack surface typical CLI server setup which is mostly what I used BSDs for back when.

FreeBSD has an order of magnitude less CVEs than Linux does and only a couple per year basically https://www.cvedetails.com/vulnerabi...d-Freebsd.html vs https://www.cvedetails.com/vulnerabi...ux-Kernel.html however there's at least an order of magnitude less eyes on it as well.

That said I'd put money down on the idea that the average Linux install and the average FreeBSD install are about as secure as each other. Why? Well the truth is only OpenBSD and Red Hat believe in any concept of "Secure by default" which bit Fedora in the ass for many years until they finally got the SELinux MAC labeling all correct and done and could properly flip on enforcing mode as opposed to being stuck in permissive mode until they got all of the configuration right.

That said all the usual suspects like MAC, ACLs, Sandboxing, Resource Limits, and such are all there in FreeBSD if you so choose to implement such policies. So I wouldn't consider Security a big argument in favour of or against FreeBSD especially on a personal computer where you're probably not going to use any of that unless you're exceptionally paranoid.

[kylew77]

FreeBSD has an order of magnitude less CVEs than Linux does and only a couple per year basically https://www.cvedetails.com/vulnerabi...d-Freebsd.html vs https://www.cvedetails.com/vulnerabi...ux-Kernel.html however there's at least an order of magnitude less eyes on it as well.

That said I'd put money down on the idea that the average Linux install and the average FreeBSD install are about as secure as each other. Why? Well the truth is only OpenBSD and Red Hat believe in any concept of "Secure by default" which bit Fedora in the ass for many years until they finally got the SELinux MAC labeling all correct and done and could properly flip on enforcing mode as opposed to being stuck in permissive mode until they got all of the configuration right.

That said all the usual suspects like MAC, ACLs, Sandboxing, Resource Limits, and such are all there in FreeBSD if you so choose to implement such policies. So I wouldn't consider Security a big argument in favour of or against FreeBSD especially on a personal computer where you're probably not going to use any of that unless you're exceptionally paranoid.

Thanks for this. I didn't know. The vulnerability that comes to mind for me is when they had a remote code execution vulnerability in the ping command.

[Tsuroerusu]

FreeBSD was my first BSD daily driver. It is a fantastic system, BUT their repeated security holes make me reluctant to use it in production on my own systems. It feels way less secure than Linux and of course it's BSD counterpart, OpenBSD. Thank God FreeBSD 14.0 is coming with ASLR by default enabled.

ASLR is also on by default in FreeBSD 13.2. I do recall an interview from 2013 with Theo de Raadt where he is asked about other OSes turning on mitigations by default, and he smiles/chuckles when the interviewer asks about FreeBSD.

[stormcrow]

ASLR is also on by default in FreeBSD 13.2. I do recall an interview from 2013 with Theo de Raadt where he is asked about other OSes turning on mitigations by default, and he smiles/chuckles when the interviewer asks about FreeBSD.

FreeBSD takes a conservative approach to changes. Changes that can break user land are introduced disabled, then later on after they've been tested a while, they're typically enabled by default unless there's a lot of ports that break by doing so - and nothing stops people from turning them on if their use case allows it. Specifically about ASLR though... It's easily bypassed by a number of techniques including, but not limited to, leveraging speculative execution exploits (Spectre and its ilk again) to do an end run around it. Not a silver bullet, but it does mean the number of people able to make useful attacks will coincide either with people willing to purchase service malware (often trivial), or skilled attackers (less trivial). The average script kiddie won't manage, but that's not saying much these days. (And it won't stop someone that's managed to guess or brute force a log in, or managed to get someone to run an e'mailed executable or script, anyway. It's usually a user's account and its data that's valuable, not the system itself.)

[Luke_Wolf]

Thanks for this. I didn't know. The vulnerability that comes to mind for me is when they had a remote code execution vulnerability in the ping command.

I mean at least it was a vulnerability restricted to a single userspace program and you would have had to have intentionally been invoking ping against a malicious server which means it was hard to exploit and if you were running a supported version of FreeBSD you were running a version of ping that ran in a capsicum sandbox so the amount of damage it could do was pretty limited. The main opportunity for exploit would be having the user connect to a malicious network and then get them to ping common server names such as google which you would redirect to your malicious server.

The truth is though any sufficiently large C or old C++ codebase that uses naked allocations or otherwise fusses with memory directly with memset and such probably has vulnerabilities, and a lot of the code we take for granted like Xorg and OpenSSL are just complete crap. I don't want to downplay this too much but to be honest it's really just run of the mill. it's nothing special like Shellshock https://en.wikipedia.org/wiki/Shellshock_(software_bug) which effected Bash or Heartbleed https://en.wikipedia.org/wiki/Heartbleed which showed just how broken OpenSSL was where this had some massive system wide effects and it was upgrade or be pwned levels of vital. This you just had to not run the ping command or only run it against known trusted servers on a known trusted network. Which how often are you doing that anyway really?

If this is what got your underwear in a twist you should probably check out what vulnerabilities are being patched almost daily in other software throughout your system. Not to say this isn't bad but it's nothing to sit there screaming hysterics about.

[stormcrow]

I mean at least it was a vulnerability restricted to a single userspace program and you would have had to have intentionally been invoking ping against a malicious server which means it was hard to exploit and if you were running a supported version of FreeBSD you were running a version of ping that ran in a capsicum sandbox so the amount of damage it could do was pretty limited. The main opportunity for exploit would be having the user connect to a malicious network and then get them to ping common server names such as google which you would redirect to your malicious server.

The truth is though any sufficiently large C or old C++ codebase that uses naked allocations or otherwise fusses with memory directly with memset and such probably has vulnerabilities, and a lot of the code we take for granted like Xorg and OpenSSL are just complete crap. I don't want to downplay this too much but to be honest it's really just run of the mill. it's nothing special like Shellshock https://en.wikipedia.org/wiki/Shellshock_(software_bug) which effected Bash or Heartbleed https://en.wikipedia.org/wiki/Heartbleed which showed just how broken OpenSSL was where this had some massive system wide effects and it was upgrade or be pwned levels of vital. This you just had to not run the ping command or only run it against known trusted servers on a known trusted network. Which how often are you doing that anyway really?

If this is what got your underwear in a twist you should probably check out what vulnerabilities are being patched almost daily in other software throughout your system. Not to say this isn't bad but it's nothing to sit there screaming hysterics about.

This. Plus going ape-shit over who has which mitigations or security features by default tends to miss the over all landscape by focusing on one bush. Roughly 80-90% of security breaches has little to nothing to do with bad code. It's mostly poor identity management policies, ignoring social engineering, flat network models, and poor logistics controls (ie: not keeping a running complete inventory of devices with network access & not patching in timely manner).

Attackers are after data. They usually don't need to exploit anything but human frailties to reach it or even gain persistence. I'm not saying patching and things like ASLR, KASLR (Linux's version is in the kernel, Linux's userspace version is very very weak and easily undermined), PIE, signed libraries and executables, etc aren't important, just that they're being emphasized way out of proportion to the majority of successful real life attacks. Us, the individual users, are the biggest threat to our data, whether you're just giving it away willy nilly for "free services" or choosing bad passwords, or being engineered to fall for the scam du jour (and no, you're not immune to con men - this is the biggest mistake of all).

[unwind-protect]

Thanks for this. I didn't know. The vulnerability that comes to mind for me is when they had a remote code execution vulnerability in the ping command.

IIRC that arbitrary code was still in a sandbox.