Mitigation of ME/Spectre/meltdown on modern hardware with FreeBSD as the OS

I build a new personal "home" server every ten years or so.

Since the system is going to run for a decade, I try to put a lot of thought into the hardware and OS configuration, etc.

This time it is a lot more complicated - in 2010 I was not worrying about out of band / LOM / IPMI - other than simply disabling it in the BIOS and forgetting about it. I was also not worrying about security issues related to speculative branching and caching (spectre/meltdown/zombieload).

I considered simply buying and running a pre-2008 CPU - such as an Intel core2duo - with no management engine and presumably no exposure to meltdown/spectre but there are a number of headaches involved in either the initial procurement or the day to day operation of the system ...

My use-case is a single user (me) FreeBSD system with a few server daemons (mail, www, sshd, wiki) each running in their own jail. There will be no untrusted users that log onto the system but there will be untrusted users connecting to the server daemons and untrusted connections coming in from everywhere - which is to say, it will be on the Internet.

My list of worries, from most concerned to least concerned are: Intel management engine, Spectre, Meltdown and (other speculative branch issues) and side channel attacks like ZombieLoad.

My questions:

Assuming I purchase a current Intel processor in 2019 and use a RELEASE version of either FreeBSD 11.x or 12.x, what best practices may I follow to minimize, or mitigate entirely, these issues ?

Given that this is *not* a multi-user system (there are no other users besides myself and Internet clients connecting to the daemons) how much exposure is there to spectre/meltdown/zombieload ?

Thank you.
 
Assuming I purchase a current Intel processor in 2019 and use a RELEASE version of either FreeBSD 11.x or 12.x, what best practices may I follow to minimize, or mitigate entirely, these issues ?

Given that this is *not* a multi-user system (there are no other users besides myself and Internet clients connecting to the daemons) how much exposure is there to spectre/meltdown/zombieload ?
Which laptops are compatible for FreeBSD based in ARM, AMD Ryzen and AMD-Radeon? Currently the Intel scandals of vulnerability and hardware insecurity.
 
People connecting to daemons do not execute code. You get to decide which code executes. From that viewpoint, the risk of things like Spectre / Meltdown / ... is somewhere between zero and minimal, and completely driven by how well you manage the system.

And note that other CPUs (including PowerPC, AMD and Arm) have had some of the same vulnerabilities. Matter-of-fact, one can argue that they may have just as many vulnerabilities as Intel does, except that their vulnerabilities don't always get found, because both black hats (hackers) and white hats (security researchers) focus on the thing with >90% market share.
 
People connecting to daemons do not execute code. You get to decide which code executes. From that viewpoint, the risk of things like Spectre / Meltdown / ... is somewhere between zero and minimal, and completely driven by how well you manage the system.

Buffer overflows and overruns in form/email/input submissions (depending on what daemon we are talking about) give attackers the ability to execute code.

It *used to be* that the biggest fear was an overflow/overrun that gave someone remote execution as root - and those kind of vulns are very few and far between. The issue now is that an overflow/overrun that merely gives you non-root execution *and perhaps* only gives you non-root execution in a virtual machine ... now there is a mechanism for that to *do anything*.

So it used to be that my httpd, running in a jail, could be vulnerable to some kind of remote execution vuln - but that would be limited to the httpd user and just inside that jail. These spectre/meltdown issues allow that vuln to eavesdrop on all processes, even outside the jail ...

Right ?
 
Yes, you're theoretically right.

But: theoretically, there are also many other vulnerabilities. For example, a hypothetical bug in sshd could allow anyone from anywhere to log in as root. But we are very very certain that those bugs are exceedingly rare, bordering on non-existent. That's because everyone knows that authentication in a remote login daemon (like sshd) is extremely important, doubly so for root login, and that part of the code and configuration is heavily audited, checked, and watched.

Similarly, simple buffer overrun attacks against programs such as apache and sendmail are very unlikely to lead to code execution. That's because the folks who implement those are particularly careful in those areas. That's particularly true because those servers are not intended to ever execute code that a client sends them; to even get to the point of running something, you already have to find a first bug that allows code execution in the first place. Therefore, a code execution that causes information leakage is a double fault: You need a combination of a first bug that allows execution, and a second bug that allows privilege escalation or eavesdropping. And a double fault is statistically less likely, quadratically so. For that reason I think that pure data servers (without logged in users, and in particular without users running web browsers) are quite immune against the various versions of Spectre / Meltdown and friends.
 
Back
Top