Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    OS patches for Intel Microarchitecture Vulnerabilities?

    Scheduled Pinned Locked Moved Hardware
    6 Posts 3 Posters 1.5k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • F
      fabrizior
      last edited by 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?

      JeGrJ 1 Reply Last reply Reply Quote 0
      • JeGrJ
        JeGr LAYER 8 Moderator @fabrizior
        last edited by 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.

        Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

        If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

        1 Reply Last reply Reply Quote 0
        • F
          fabrizior
          last edited by

          @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.

          F 1 Reply Last reply Reply Quote 0
          • F
            fabrizior @fabrizior
            last edited by

            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

            1 Reply Last reply Reply Quote 0
            • B
              bigsy
              last edited by

              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

              F 1 Reply Last reply Reply Quote 1
              • F
                fabrizior @bigsy
                last edited by

                @bigsy Perfect. Thank you.

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.