It’s not just security that’s poor out of the box. I remember having to set a hideous amount of sysctls for things like Mono and Apache, and the Xorg configuration is terrible OOTB - fonts in particular will likely be aliased.
I’d strongly recommend OpenBSD if someone wants an alternative to Linux - and not just the same cut corners for the sake of performance ideas, but with extra pain.
Some of this seems factually incorrect, or possibly just very outdated. For example, the PRNG was previously (FreeBSD10 at least, maybe 9..not sure) yarrow – now fortuna in FreeBSD11. Not rc4.
Some are just personal preference (griping about periodic?).
Other parts of this are sadly quite factual and indeed problematic (or outright dangerous). :(
Ah, for arc4random. Yeah, that certainly needs to be fixed. I thought the original post was talking about the kernel PRNG, or the supported random devices (/dev/(u)random). I don’t believe FreeBSD uses arc4random for /dev/(u)random like OpenBSD does, instead it directly uses the yarrow/fortuna entropy pool. I honestly don’t know why FreeBSD doesn’t just have arc4random pull directly from the kernel entropy pool like /dev/(u)random does, given that they already use yarrow/fortuna. I think that would also obviate the weird fork safety issues with arc4random.
Looks like OpenBSD switched to chacha20 in may 2014 (version 5.5)? NetBSD appears to have made the change to chacha20 as well. Not sure why, but they call arc4random “legacy” though.
I think NetBSD is calling just the name “legacy”. NetBSD no longer supports an ARC4-based generator, but the new ChaCha20-based generator implements the old API and name “arc4random” for historical/compatibility reasons. The OpenBSD manpage takes a different strategy of suggesting a backronym, “A Replacement Call for Random”.
Anyway it looks like that’s only in the NetBSD source code. The manpage doesn’t call it legacy or suggest that it’s deprecated, although it does gripe about the name,
The name `arc4random' was chosen for hysterical raisins – it was originally implemented using the RC4 stream cipher, which has been known since shortly after it was published in 1994 to have observable biases in the output, and is now known to be broken badly enough to admit practical attacks in the real world. Unfortunately, the library found widespread adoption and the name stuck before anyone recognized that it was silly.
Great writeup. Whoever took the time to put this all together did the FreeBSD and Open Source community a great service. Even if you don’t run a particular project’s software you can still learn from their mistakes. Other people’s mistakes are my favorite mistakes to learn from.
It looks like that David fellow he linked to has been fairly persistent in trying to get anyone he can to pay attention the those decades-old portsnap, pmirror, and freebsd-update remotely exploitable vulnerabilities [https://lists.freebsd.org/pipermail/freebsd-hackers/2016-March/049254.html]. It’s really surprising that the FreeBSD Foundation doesn’t fund the patching of these sorts of things. Someone should send David an email and preach the Good News about OpenBSD to him.
I bet if he saw this write-up he’d be grateful to the author for raising these issues and linking to his thread.
It’s not just security that’s poor out of the box. I remember having to set a hideous amount of sysctls for things like Mono and Apache, and the Xorg configuration is terrible OOTB - fonts in particular will likely be aliased.
I’d strongly recommend OpenBSD if someone wants an alternative to Linux - and not just the same cut corners for the sake of performance ideas, but with extra pain.
Some of this seems factually incorrect, or possibly just very outdated. For example, the PRNG was previously (FreeBSD10 at least, maybe 9..not sure) yarrow – now fortuna in FreeBSD11. Not rc4.
Some are just personal preference (griping about periodic?).
Other parts of this are sadly quite factual and indeed problematic (or outright dangerous). :(
It was pointed out to me by TJ that rc4 is still being used in freebsd. https://en.wikipedia.org/wiki/RC4#RC4-based_random_number_generators
There have been several attempts to convince freebsd to update to chacha20 like OpenBSD did. This is from back in 2013: https://lists.freebsd.org/pipermail/freebsd-bugs/2013-October/054018.html
Here is a diff from tedu in 2014: https://lists.freebsd.org/pipermail/freebsd-hackers/2014-May/045235.html
Ah, for arc4random. Yeah, that certainly needs to be fixed. I thought the original post was talking about the kernel PRNG, or the supported random devices (/dev/(u)random). I don’t believe FreeBSD uses arc4random for /dev/(u)random like OpenBSD does, instead it directly uses the yarrow/fortuna entropy pool. I honestly don’t know why FreeBSD doesn’t just have arc4random pull directly from the kernel entropy pool like /dev/(u)random does, given that they already use yarrow/fortuna. I think that would also obviate the weird fork safety issues with arc4random.
Looks like OpenBSD switched to chacha20 in may 2014 (version 5.5)? NetBSD appears to have made the change to chacha20 as well. Not sure why, but they call arc4random “legacy” though.
I think NetBSD is calling just the name “legacy”. NetBSD no longer supports an ARC4-based generator, but the new ChaCha20-based generator implements the old API and name “arc4random” for historical/compatibility reasons. The OpenBSD manpage takes a different strategy of suggesting a backronym, “A Replacement Call for Random”.
Anyway it looks like that’s only in the NetBSD source code. The manpage doesn’t call it legacy or suggest that it’s deprecated, although it does gripe about the name,
Great writeup. Whoever took the time to put this all together did the FreeBSD and Open Source community a great service. Even if you don’t run a particular project’s software you can still learn from their mistakes. Other people’s mistakes are my favorite mistakes to learn from.
It looks like that David fellow he linked to has been fairly persistent in trying to get anyone he can to pay attention the those decades-old portsnap, pmirror, and freebsd-update remotely exploitable vulnerabilities [https://lists.freebsd.org/pipermail/freebsd-hackers/2016-March/049254.html]. It’s really surprising that the FreeBSD Foundation doesn’t fund the patching of these sorts of things. Someone should send David an email and preach the Good News about OpenBSD to him.
I bet if he saw this write-up he’d be grateful to the author for raising these issues and linking to his thread.