OS patches for Intel Microarchitecture Vulnerabilities?

[fabrizior]

Understanding that there first need to be BIOS updates for any given HW, will there need to be any OS/pfSense patches for these too?

Microarchitectural Store Buffer Data Sampling (MSBDS) - CVE-2018-12126

Microarchitectural Load Port Data Sampling (MLPDS) - CVE-2018-12127

Microarchitectural Fill Buffer Data Sampling (MFBDS) - CVE-2018-12130

Microarchitectural Data Sampling Uncacheable Memory (MDSUM) – CVE-2019-11091

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00233.html

I’m running 2.4.4-RELEASE-p2 on FreeBSD 11.2-RELEASE-p6 using a Protectli FW6C Vault with a Intel Kaby Lake U i5-7500U CPU. Have opened a support ticket with regarding BIOS update timing.

Trying to cover my bases.

Update: found a freeBSD security advisory: https://www.freebsd.org/security/advisories/FreeBSD-SA-19:07.mds.asc which seems to indicate the fixes are available with 11.2-RELEASE-p10.

There are multiple solution options presented in the advisory. If I can’t get a BIOS update in a timely fashion, which of the other advised solutions would be the best course of action with a pfSense deployment, and why? Are there any additional considerations for the pfSense image?

[JeGr]

@fabrizior said in OS patches for Intel Microarchitecture Vulnerabilities?:

Trying to cover my bases.

@fabrizior said in OS patches for Intel Microarchitecture Vulnerabilities?:

which of the other advised solutions would be the best course of action with a pfSense deployment, and why?

I'd advise a security consideration. The whole Intel CPU bugs is a nasty thing of course. But the real thread comes from: where can it be exploited or how could pfSense. As the whole thing started there was a good post about all things CPU bug related where all came down to: limit access to pfSense itself to trusted users only. But pfSense itself is no classic server/UI system where dozens of client users log in and share information. So the possibility of gaining any information from any leak is as small as the users allowed access to the WebUI/SSH. In most cases that's a pretty small group that every so often consists of all admins, that have root access anyway. AFAIK no Intel Microcode Vuln. is remote exploitable and most (if I'm not wrong) would require elevated rights.

[fabrizior]

@JeGr
Thanks for the prompt reply. I get the whole "limit access to trusted users only." approach, and that's great as a general SOP. I'm also worried about all of the vectors that may not be so obvious, or may not even have been discovered yet. Besides direct ssh & WebUI, there are several additional packages that include dependencies that either provide additional HTTP servers and/or make calls for remote data feeds, etc... I'm worried about all of those as well that we don't necessarily have direct access to control.

Hows this for a hypothetical...
If there's even one package that utilizes a remote data feed where a spoofed or malicious data is downloaded that when parsed allows any unintended unprivileged code execution due to a buffer overflow or other condition... and the router may very well be compromised given the scope of these latest vulnerabilities. pfBlockerNG, GeoIP, Snort, Suricata, Squid, lighttpd, bandwidthd, etc...???

At the end of the day, security patching must take a holistic and comprehensive approach. From the chipset microcode, kernel, OS packages, 3rd-party packages, and AuthN/AuthZ SOPs.

I can't very well release a security advisory to my users stating "we've limited the scope of users with access, so we're all good here."

At the end of the day, we all should be running a properly and fully-patched environment.

[fabrizior]

Recognizing that few may be using a Protectli Vault as their hardware platform, Here’s what I got back from Protectli regarding BIOS update timing:

Luke Green
May 15, 2019 2:05 pm
This just came in last night and we are currently working towards a resolution. We understand the security concern and this is a high priority.

The BIOS page will be updated as soon as the fix is available for download.

We should be able to provide you with a timeline in the next week or two. Hopefully sooner. I’ll keep you updated as soon as we hear something.

Regards,
Luke

[bigsy]

Looks like 2.4.4p3 is arriving next week with a fix from FreeBSD:

https://forum.netgate.com/topic/143391/recent-intel-mds-flaw-announcement

[fabrizior]

@bigsy Perfect. Thank you.