10 ms·

FreeBSD – a lesson in poor defaults

195 points by beefhash 9y ago

sigil 9y ago
Previous discussion: https://news.ycombinator.com/item?id=11318508 https://news.ycombinator.com/item?id=11318508
iomotoko 9y ago
Been here more than once, for past comments see 469 days ago https://news.ycombinator.com/item?id=12484248 https://news.ycombinator.com/item?id=12484248 647 days ago https://news.ycombinator.com/item?id=11318508 https://news.ycombinator.com/item?id=11318508 For those who already have read it, document has been addended multiple times (see bottom of doc)
- krylon 9y ago
  > For those who already have read it, document has been addended multiple times (see bottom of doc) Thank you, I was just wondering how up to date this is.
0xcde4c3db 9y ago
> I think swap should always be encrypted. FreeBSD developers disagree. It's surprising just how much private data in memory gets written to disk. Someone I know has run hexdump on his swap partition and found PGP private keys in plain view. Your SSH key might be password-protected on disk, but it could end up in swap sooner or later... with no password needed. GnuPG and a few other security-conscious programs try to avoid this by using mlock() [1]. Unfortunately, by default the ZFS ARC can grow beyond the limit for wired pages, which will make those mlock() calls start failing once the system has been up long enough [2]. [1] http://pubs.opengroup.org/onlinepubs/7908799/xsh/mlock.html http://pubs.opengroup.org/onlinepubs/7908799/xsh/mlock.html [2] https://ximalas.info/2012/04/10/not-enough-room-for-wired-pages/ https://ximalas.info/2012/04/10/not-enough-room-for-wired-pa...
- vog 9y ago
  Moreover, you have stuff like password managers going though the clipboard. Relying on all tools correctly identifying their sensitive datasets and protecting them though mlock() is doomed to fail. If anything, a proper security concept should whitelist insensitive datasets, instead of blacklisting sensitive datasets. I don't get why any modern OS would use unencrypted SWAP. The default should be either encrypted SWAP, or no SWAP at all. The downsides are negligible compared to the upsides.
  - ilammy 9y ago
    > encrypted SWAP When I was setting up dm-crypt for my Linux dev box at work I opted for using an encrypted swap as it really made sense: why keep on-disk stuff encrypted if swapped memory is in plain sight. It turned out to be a somewhat bad decision, because when the system did run out of memory (thank you, Firefox and Skype) and began swapping, the whole box just freezes as the kernel was too busy encrypting more and more stuff, not having time to even run the OOM killer. Maybe the systems use unencrypted swap to avoid triggering such bugs in default setups.
    - wolf550e 9y ago
      I don't doubt your story, but modern CPUs can perform AES-GCM at gigabytes per second per core (5GB/sec on my laptop). Disk encryption is a different block cipher mode, but it shouldn't be much slower. So if implemented correctly, encrypted swap should not slow you down vs unencrypted swap. If in your setup encrypted swap is much slower than unencrypted swap, it's a bug in the kernel crypto and it should be fixed.
      - noinsight 9y ago
        Actually, Samsung 960 Pros are fast enough that encryption becomes a bottleneck, at least on my Xeon E5-2620v4. You can test it yourself with `cryptsetup benchmark`: # cryptsetup benchmark --cipher aes-xts # Tests are approximate using memory only (no storage IO). # Algorithm | Key | Encryption | Decryption aes-xts 256b 1874.2 MiB/s 2042.6 MiB/s I was surprised and it made me doubt whether it's using AES-NI at all, but then again it's not an issue in practice.
vog 9y ago
I wonder how this compares to other unix systems, such as OpenBSD or various Linux Distros.
- oscargrouch 9y ago
  HardenedBSD (https://hardenedbsd.org https://hardenedbsd.org) also. Which is a recent fork of FreeBSD that has a focus on security.
  - tachion 9y ago
    Unfortunately, HardenedBSD is nothing more but a PR campaign from a one person who feels rejected due to poor code quality and bad reviews from FreeBSD developers who expect a bit more than just throwing random patches around and saying 'here, I fixed all these security problems with three lines of code'. I would recommend taking HardenedBSD and its announcements with a huge portion of salt.
    - jemsa 9y ago
      The funny part is that FreeBSD has had years to even implement anything as simple as ASLR but it didn't and instead starting to reject other peoples code. What HardenedBSD did is basically following the PaX model which has been documented for a long time[1]. It seems like FreeBSD is just lacking any developers willing to deal with these security features or let alone upstream it because its usually a pain in the ass to upstream stuff like this just look how Linux is having a hard time implementing even basic stuff from grsecurity. Exploit mitigations are not for fixing those security problems it is to make it harder to exploit certain vulnerabilities. 1: https://pax.grsecurity.net/docs/index.html https://pax.grsecurity.net/docs/index.html
      - tachion 9y ago
        The funny part is that even amongst top security researchers there doesn't seem to be an agreement over the fact if ASLR is worth anything, as it was proved to be breakable in no time. And it seems like grsecurity code suffers the same problems as the code from HardenedBSD, that is the quality matching the respective project's standards.
RI_Swamp_Yankee 9y ago
Reminds me of the old "Fixing Solaris" file from the '90s (and the Fixing SunOS that was its forebear.)
- jaxb 9y ago
  Is it archived anywhere?
stouset 9y ago
As an infosec guy having read some of the past discussions here — mostly about how infosec people are overzealous and don’t understand how disruptive these types of changes can be to existing installed bases — we do get it. The problem ends up being that improvements already take ages to work their way downstream, and not making them for compatibility reasons is a self-defeating prophecy. Those compatibility concerns will still exist next week, next month, and next year without actually working to address and reduce the problem. Often times they’re even worse as the installed base continues to grow and/or calcify around the existing setup. The net result is that the compatibility argument, usually unintentionally, results in the status quo being kept for years. And when it already takes so long for these changes to make it out to users due to slow upgrade cycles, slow repackaging by downstream maintainers, slow uptake of new defaults, etc., with this same argument happening at each and every level… it often results in little to no progress over the span of years to common threats and pitfalls that are making people vulnerable today. That’s also why some of us try so hard to make sure developers get things right early on in their designs, since fixing it after the fact can be such an ordeal. Of course, we understand the plight of maintainers not wanting to disrupt their users. It’s a difficult situation from both sides of the debate for sure. And also of course developing new features is more likely to make both users and developers happier than fixing security bugs is, at least in the short term. Just wanted to put the opposite perspective here as well since it felt underrepresented in previous discussions. One thing to note, this isn’t necessarily indicative of my agreement with all of his analysis or belief that many of these are severe and need urgent fixing. This is more targeted at the meta-discussion around overzealous security people.
loeg 9y ago
This was "Last updated 12/08/2017." That update does not include removing portions that are no longer true — instead they have published an update section at the very bottom. Re: sendmail, check out the age of most of those CVEs (2006 or earlier). But also, see https://lists.freebsd.org/pipermail/freebsd-arch/2017-December/018712.html https://lists.freebsd.org/pipermail/freebsd-arch/2017-Decemb... .
deleted 9y ago
[deleted]
azinman2 9y ago
How does pfsense differ from FreeBSD in light of these comments?
marmaduke 9y ago
As someone looking to move a cluster from ancient Debian, I was looking at either CentOS or FreeBSD but this looks not so nice..
- floatboth 9y ago
  Honestly, most of the concerns are rather superficial. You might want to try HardenedBSD instead of regular FreeBSD though, to get all the exploit mitigation stuff.
  - tachion 9y ago
    Don't do that. HardenedBSD is rather a one man project, who's patches have been reviewed and rejected by FreeBSD developers due to bad quality, poor design and lack of cooperation in bringing them to FreeBSD expected standards. It seems like a PR campaign from people who can write some C, but don't have much credibility in writing secure operating systems or production ready code. Beside the quality of the proposed solutions, there was nothing in the FreeBSD project stopping the code from being accepted. Wether the bad ASLR implementation or no implementation is worse, it's up to you to decide, but I'll vote for quality first.
    - X86BSD 9y ago
      I could be wrong but I was under the impression certain sec folks objected to a lot of his patches because they just are not sold on if ASLR really adds any benefit. Or any benefit vs the complexity it adds. Correct me if I’m wrong. I know Theo has bought into it. I just recall in FreeBSD it wasn’t accepted if it really fixes anything.
      - empthought 9y ago
        FYI since a couple weeks ago, all of your comments except this one appear dead. You must have made someone mad.
    - jemsa 9y ago
      Yet FreeBSD hasn't done a single thing to improve the current state of exploit mitigations. It doesn't matter how many people are writing code, grsecurity is mainly Spender & pipacs aka PaXTeam yet 14 Linux developers couldn't spot the vulnerabilities they've created by copy pasting and editing code from grsecrutiy. You can't really blame others for trying while FreeBSD hasn't tried a single thing yet.
deleted 9y ago
[deleted]
krylon 9y ago
> Being alerted to vulnerabilities in your installed packages is nice, but there's simply no need to be doing this operation as root. The dangerous combination of laziness and poor software design is quite prevalent here. Just a thought - if an unprivileged user could download the vulnerability list, couldn't a malicious but unprivileged local user just "download" an empty vulnerability list? At least it would take a user account created specifically for this purpose. (Which I admit would be a good idea!)
- anjbe 9y ago
  A compromised unprivileged user could download an empty vulnerability list. A compromised root user could download an empty vulnerability list or do anything else root can do.
zzzcpan 9y ago
The analysis is not in any way serious, just some feelings the author has about certain things that may not even matter to anyone nor improve security in any meaningful way, if not worsen it by providing a false sense of security.
tachion 9y ago
While you're here, have you donated[0][1] yet? :) You may or may not be aware, but FreeBSD runs your movies on Netflix, your games on PlayStation and Nitendo Switch, your files on FreeNAS and ZFS, your friends on WhatsApp and OpenBSD runs everything else on OpenSSH. ;) So, you may or may not know that, but you need FreeBSD and OpenBSD and they also need you! Every cent counts and so does every contributor, that helps the foundations keep their non-profit status. Also, you CAN be the change, if you specify what you'd like your donation to be used for (like more secure defaults for the OS). [0] https://www.freebsdfoundation.org/donate/ https://www.freebsdfoundation.org/donate/ [1] https://www.openbsd.org/donations.html https://www.openbsd.org/donations.html
- na85 9y ago
  Seems to me that Netflix, Sony, et al should be paying FreeBSD, not the users. Why would I subsidize FreeBSD so that mega corps can leech off the hard work of volunteers, and by extension leech off my donation?
  - boomboomsubban 9y ago
    They do pay, both in code and donations.
    - na85 9y ago
      Obviously these hugely profitable companies don't pay enough. Otherwise I should not need to donate.
      - boomboomsubban 9y ago
        Obviously Windows should be free, with all the huge companies that use that. The logic makes no sense.
        Neeek 9y ago
        It makes perfect sense if you don't personally own or use Windows. I don't pay Microsoft again to play TitanFall just because their servers are hosted on Azure. I understand we all probably use tools everyday that can be attributed to these projects and I don't mean to imply that you shouldn't give them money. Just that the Netflix/WhatsApp comments seem a little disingenuous. That shouldn't be in the "reasons you need BSD", those are just reasons Neflix and WhatsApp need BSD.
tachion 9y ago
A lot of these has been already addressed by a security menu in the FreeBSD installer, since settings and/or mitigations for mentioned issues have been possible in FreeBSD but have not been enabled by default due to POLA (project's rule of Priciple Of Least Astonishment) in order to prevent users expecting some behaviour to be surprised by changes. Those who knew about these could always enable those, and those who didn't now have option to do it via the default installer.

195 points by beefhash 9y ago

Previous discussion: https://news.ycombinator.com/item?id=11318508 https://news.ycombinator.com/item?id=11318508

Been here more than once, for past comments see 469 days ago https://news.ycombinator.com/item?id=12484248 https://news.ycombinator.com/item?id=12484248 647 days ago https://news.ycombinator.com/item?id=11318508 https://news.ycombinator.com/item?id=11318508 For those who already have read it, document has been addended multiple times (see bottom of doc)

krylon 9y ago
> For those who already have read it, document has been addended multiple times (see bottom of doc) Thank you, I was just wondering how up to date this is.

0xcde4c3db 9y ago

> I think swap should always be encrypted. FreeBSD developers disagree. It's surprising just how much private data in memory gets written to disk. Someone I know has run hexdump on his swap partition and found PGP private keys in plain view. Your SSH key might be password-protected on disk, but it could end up in swap sooner or later... with no password needed. GnuPG and a few other security-conscious programs try to avoid this by using mlock() [1]. Unfortunately, by default the ZFS ARC can grow beyond the limit for wired pages, which will make those mlock() calls start failing once the system has been up long enough [2]. [1] http://pubs.opengroup.org/onlinepubs/7908799/xsh/mlock.html http://pubs.opengroup.org/onlinepubs/7908799/xsh/mlock.html [2] https://ximalas.info/2012/04/10/not-enough-room-for-wired-pages/ https://ximalas.info/2012/04/10/not-enough-room-for-wired-pa...

vog 9y ago
Moreover, you have stuff like password managers going though the clipboard. Relying on all tools correctly identifying their sensitive datasets and protecting them though mlock() is doomed to fail. If anything, a proper security concept should whitelist insensitive datasets, instead of blacklisting sensitive datasets. I don't get why any modern OS would use unencrypted SWAP. The default should be either encrypted SWAP, or no SWAP at all. The downsides are negligible compared to the upsides.
- ilammy 9y ago
  > encrypted SWAP When I was setting up dm-crypt for my Linux dev box at work I opted for using an encrypted swap as it really made sense: why keep on-disk stuff encrypted if swapped memory is in plain sight. It turned out to be a somewhat bad decision, because when the system did run out of memory (thank you, Firefox and Skype) and began swapping, the whole box just freezes as the kernel was too busy encrypting more and more stuff, not having time to even run the OOM killer. Maybe the systems use unencrypted swap to avoid triggering such bugs in default setups.
  - wolf550e 9y ago
    I don't doubt your story, but modern CPUs can perform AES-GCM at gigabytes per second per core (5GB/sec on my laptop). Disk encryption is a different block cipher mode, but it shouldn't be much slower. So if implemented correctly, encrypted swap should not slow you down vs unencrypted swap. If in your setup encrypted swap is much slower than unencrypted swap, it's a bug in the kernel crypto and it should be fixed.
    - noinsight 9y ago
      Actually, Samsung 960 Pros are fast enough that encryption becomes a bottleneck, at least on my Xeon E5-2620v4. You can test it yourself with `cryptsetup benchmark`: # cryptsetup benchmark --cipher aes-xts # Tests are approximate using memory only (no storage IO). # Algorithm | Key | Encryption | Decryption aes-xts 256b 1874.2 MiB/s 2042.6 MiB/s I was surprised and it made me doubt whether it's using AES-NI at all, but then again it's not an issue in practice.

vog 9y ago

I wonder how this compares to other unix systems, such as OpenBSD or various Linux Distros.

oscargrouch 9y ago
HardenedBSD (https://hardenedbsd.org https://hardenedbsd.org) also. Which is a recent fork of FreeBSD that has a focus on security.
- tachion 9y ago
  Unfortunately, HardenedBSD is nothing more but a PR campaign from a one person who feels rejected due to poor code quality and bad reviews from FreeBSD developers who expect a bit more than just throwing random patches around and saying 'here, I fixed all these security problems with three lines of code'. I would recommend taking HardenedBSD and its announcements with a huge portion of salt.
  - jemsa 9y ago
    The funny part is that FreeBSD has had years to even implement anything as simple as ASLR but it didn't and instead starting to reject other peoples code. What HardenedBSD did is basically following the PaX model which has been documented for a long time[1]. It seems like FreeBSD is just lacking any developers willing to deal with these security features or let alone upstream it because its usually a pain in the ass to upstream stuff like this just look how Linux is having a hard time implementing even basic stuff from grsecurity. Exploit mitigations are not for fixing those security problems it is to make it harder to exploit certain vulnerabilities. 1: https://pax.grsecurity.net/docs/index.html https://pax.grsecurity.net/docs/index.html
    - tachion 9y ago
      The funny part is that even amongst top security researchers there doesn't seem to be an agreement over the fact if ASLR is worth anything, as it was proved to be breakable in no time. And it seems like grsecurity code suffers the same problems as the code from HardenedBSD, that is the quality matching the respective project's standards.

RI_Swamp_Yankee 9y ago

Reminds me of the old "Fixing Solaris" file from the '90s (and the Fixing SunOS that was its forebear.)

jaxb 9y ago
Is it archived anywhere?

stouset 9y ago

As an infosec guy having read some of the past discussions here — mostly about how infosec people are overzealous and don’t understand how disruptive these types of changes can be to existing installed bases — we do get it. The problem ends up being that improvements already take ages to work their way downstream, and not making them for compatibility reasons is a self-defeating prophecy. Those compatibility concerns will still exist next week, next month, and next year without actually working to address and reduce the problem. Often times they’re even worse as the installed base continues to grow and/or calcify around the existing setup. The net result is that the compatibility argument, usually unintentionally, results in the status quo being kept for years. And when it already takes so long for these changes to make it out to users due to slow upgrade cycles, slow repackaging by downstream maintainers, slow uptake of new defaults, etc., with this same argument happening at each and every level… it often results in little to no progress over the span of years to common threats and pitfalls that are making people vulnerable today. That’s also why some of us try so hard to make sure developers get things right early on in their designs, since fixing it after the fact can be such an ordeal. Of course, we understand the plight of maintainers not wanting to disrupt their users. It’s a difficult situation from both sides of the debate for sure. And also of course developing new features is more likely to make both users and developers happier than fixing security bugs is, at least in the short term. Just wanted to put the opposite perspective here as well since it felt underrepresented in previous discussions. One thing to note, this isn’t necessarily indicative of my agreement with all of his analysis or belief that many of these are severe and need urgent fixing. This is more targeted at the meta-discussion around overzealous security people.

loeg 9y ago

This was "Last updated 12/08/2017." That update does not include removing portions that are no longer true — instead they have published an update section at the very bottom. Re: sendmail, check out the age of most of those CVEs (2006 or earlier). But also, see https://lists.freebsd.org/pipermail/freebsd-arch/2017-December/018712.html https://lists.freebsd.org/pipermail/freebsd-arch/2017-Decemb... .

deleted 9y ago

[deleted]

azinman2 9y ago

How does pfsense differ from FreeBSD in light of these comments?

marmaduke 9y ago

As someone looking to move a cluster from ancient Debian, I was looking at either CentOS or FreeBSD but this looks not so nice..

floatboth 9y ago
Honestly, most of the concerns are rather superficial. You might want to try HardenedBSD instead of regular FreeBSD though, to get all the exploit mitigation stuff.
- tachion 9y ago
  Don't do that. HardenedBSD is rather a one man project, who's patches have been reviewed and rejected by FreeBSD developers due to bad quality, poor design and lack of cooperation in bringing them to FreeBSD expected standards. It seems like a PR campaign from people who can write some C, but don't have much credibility in writing secure operating systems or production ready code. Beside the quality of the proposed solutions, there was nothing in the FreeBSD project stopping the code from being accepted. Wether the bad ASLR implementation or no implementation is worse, it's up to you to decide, but I'll vote for quality first.
  - X86BSD 9y ago
    I could be wrong but I was under the impression certain sec folks objected to a lot of his patches because they just are not sold on if ASLR really adds any benefit. Or any benefit vs the complexity it adds. Correct me if I’m wrong. I know Theo has bought into it. I just recall in FreeBSD it wasn’t accepted if it really fixes anything.
    - empthought 9y ago
      FYI since a couple weeks ago, all of your comments except this one appear dead. You must have made someone mad.
  - jemsa 9y ago
    Yet FreeBSD hasn't done a single thing to improve the current state of exploit mitigations. It doesn't matter how many people are writing code, grsecurity is mainly Spender & pipacs aka PaXTeam yet 14 Linux developers couldn't spot the vulnerabilities they've created by copy pasting and editing code from grsecrutiy. You can't really blame others for trying while FreeBSD hasn't tried a single thing yet.

deleted 9y ago

[deleted]

krylon 9y ago

> Being alerted to vulnerabilities in your installed packages is nice, but there's simply no need to be doing this operation as root. The dangerous combination of laziness and poor software design is quite prevalent here. Just a thought - if an unprivileged user could download the vulnerability list, couldn't a malicious but unprivileged local user just "download" an empty vulnerability list? At least it would take a user account created specifically for this purpose. (Which I admit would be a good idea!)

anjbe 9y ago
A compromised unprivileged user could download an empty vulnerability list. A compromised root user could download an empty vulnerability list or do anything else root can do.

zzzcpan 9y ago

The analysis is not in any way serious, just some feelings the author has about certain things that may not even matter to anyone nor improve security in any meaningful way, if not worsen it by providing a false sense of security.

tachion 9y ago

While you're here, have you donated[0][1] yet? :) You may or may not be aware, but FreeBSD runs your movies on Netflix, your games on PlayStation and Nitendo Switch, your files on FreeNAS and ZFS, your friends on WhatsApp and OpenBSD runs everything else on OpenSSH. ;) So, you may or may not know that, but you need FreeBSD and OpenBSD and they also need you! Every cent counts and so does every contributor, that helps the foundations keep their non-profit status. Also, you CAN be the change, if you specify what you'd like your donation to be used for (like more secure defaults for the OS). [0] https://www.freebsdfoundation.org/donate/ https://www.freebsdfoundation.org/donate/ [1] https://www.openbsd.org/donations.html https://www.openbsd.org/donations.html

na85 9y ago
Seems to me that Netflix, Sony, et al should be paying FreeBSD, not the users. Why would I subsidize FreeBSD so that mega corps can leech off the hard work of volunteers, and by extension leech off my donation?
- boomboomsubban 9y ago
  They do pay, both in code and donations.
  - na85 9y ago
    Obviously these hugely profitable companies don't pay enough. Otherwise I should not need to donate.
    - boomboomsubban 9y ago
      Obviously Windows should be free, with all the huge companies that use that. The logic makes no sense.
      - Neeek 9y ago
        It makes perfect sense if you don't personally own or use Windows. I don't pay Microsoft again to play TitanFall just because their servers are hosted on Azure. I understand we all probably use tools everyday that can be attributed to these projects and I don't mean to imply that you shouldn't give them money. Just that the Netflix/WhatsApp comments seem a little disingenuous. That shouldn't be in the "reasons you need BSD", those are just reasons Neflix and WhatsApp need BSD.

tachion 9y ago

A lot of these has been already addressed by a security menu in the FreeBSD installer, since settings and/or mitigations for mentioned issues have been possible in FreeBSD but have not been enabled by default due to POLA (project's rule of Priciple Of Least Astonishment) in order to prevent users expecting some behaviour to be surprised by changes. Those who knew about these could always enable those, and those who didn't now have option to do it via the default installer.