Intel CPUs Massive Security Flaw issue



  • "All Intel Processors Made in the Last Decade Might Have a Massive Security Flaw"
    https://gizmodo.com/report-all-intel-processors-made-in-the-last-decade-mi-1821728240
    https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
    https://www.postgresql.org/message-id/20180102222354.qikjmf7dvnjgbkxe@alap3.anarazel.de

    I'm really starting to loose my trust in Intel. First ME, than this. Oh and the C2000 series bug
    I used to use AMD CPUs in the past, I switched to Intel about 15 years ago because AMDs tended to overheat etc. while Intels looked more trustworthy, they costed more but had less compromises at that time than AMDs (the era of Athlons and Durons).
    I wonder how do AMDs perform these days...? I definitely intend to start looking at AMDs in my next projects....

    Anyways, the big questions are:

    • do we get (and when) a kernel update to pfSense to address this issue
    • how much performance decrease should we espect. Thinking here of Atoms especially, C2000 series (like the famous Supermicro A1SRi-2758F and its brothers board, used by thousands of us in pfSense)

  • Galactic Empire Netgate Administrator

    No FreeBSD patches as yet.



  • Hmm. I really hope if there will be such a patch, performance loss will only affect Intel CPUs; KPTI (Kernel Page Table Isolation) routine would only be activated if the processor is detected as being an Intel…


  • Galactic Empire Netgate Administrator

    This is a brand new issue so we don't have much of information yet.



  • Intel is just becoming more and more disappointing. I think it's time to start looking to AMD or others…



  • AMD's performance is so far behind that even 30% slower the Intel is still faster  and I suspect they have their own issues.



  • @Chrismallia:

    AMD's performance is so far behind that even 30% slower the Intel is still faster  and I suspect they have their own issues.

    I'm afraid that depends on what type of tasks the CPU has to perform. For example I've got several HP T5730 thin clients equipped with AMD Sempron 2100+ CPUs at 1GHz, they do WAN/LAN NAT-ing at full interface speed between VLANs (1Gbit/s/2) at only 60% CPU usage. Intel Atoms from that era are nowhere compared to Semprons.



  • "I'm afraid that depends on what type of tasks the CPU has to perform. For example I've got several HP T5730 thin clients equipped with AMD Sempron 2100+ CPUs at 1GHz, they do WAN/LAN NAT-ing at full interface speed between VLANs (1Gbit/s/2) at only 60% CPU usage. Intel Atoms from that era are nowhere compared to Semprons."

    Thats good to know, thanks for the info



  • If I have to trade speed for security, I choose security every time. With Intel, it used to be a win-win but, with recent news… I just don't believe it so blindly anymore. Of course AMD is not the cure to all your problems but it sure starts to seem a little better.



  • AMD's performance is so far behind that even 30% slower the Intel is still faster  and I suspect they have their own issues.

    From what I have read, AMD's latest Threadripper CPUs are giving Intel a run for their money, and they're cheaper.  As for issues, unless you have something concrete then you can't really make that claim.  I've seen others saying the same thing on other tech forums, that this Intel bug is bad but AMD might maybe perhaps possibly have something as bad or worse.  It's pure FUD.





  • More info here:

    https://spectreattack.com/


  • Galactic Empire Netgate Administrator

    Our preliminary assessment of Meltdown and Spectre vulnerabilities suggests that most pfSense use cases without untrusted local users or a multi-tenant context should not be concerned.

    Once the FreeBSD project issues a patched release, we will incorporate those patches, test, and release new versions of pfSense.



  • From my understanding of the problem all x86 processors are effected but the AMD processors have the ability to turn off the branch prediction feature. It would seem to me that if some bioses can be updated to turn this feature off on Intel Processors than the problem can be minimized without the 5% performance hit. We all want speed and putting the Kernel page file and user page file in the same space was a way for them to achieve this. I don't really think it's fair to blame Intel. Security is really hard and I would say the problem is really at the OS level. OS makers are working on the fix now so I would say everyone is doing their job. I would imagine in the future Intel processors will have the ability to turn the branch prediction off which will fix this issue.



  • @mikeisfly:

    From my understanding of the problem all x86 processors are effected but the AMD processors have the ability to turn off the branch prediction feature. It would seem to me that if some bioses can be updated to turn this feature off on Intel Processors than the problem can be minimized without the 5% performance hit. We all want speed and putting the Kernel page file and user page file in the same space was a way for them to achieve this. I don't really think it's fair to blame Intel. Security is really hard and I would say the problem is really at the OS level. OS makers are working on the fix now so I would say everyone is doing their job. I would imagine in the future Intel processors will have the ability to turn the branch prediction off which will fix this issue.

    Turning off branch prediction would be a much more significant performance hit. The impact of KPTI is felt on code with a lot of system calls, and has close to zero impact on code that stays in user land. Killing branch prediction would impact everything.

    It's also worth pointing out that this isn't a kernel-specific issue, and that side channel attacks can impact any program that tries to isolate untrusted code. (For example, a browser running javascript.) The kernel mitigations don't fix all of those other programs–and AMD CPUs are impacted by this just as much as Intel CPUs.



  • @ivor:

    Our preliminary assessment of Meltdown and Spectre vulnerabilities suggests that most pfSense use cases without untrusted local users or a multi-tenant context should not be concerned.

    Can you please elaborate a little bit this, so we can understand what you mean? Especially the "most pfSense use cases without untrusted local users or a multi-tenant context ".
    The whole pfSense runs as root, including the web interface afaik…



  • @VAMike:

    AMD CPUs are impacted by this just as much as Intel CPUs.

    Not true:

    AMD processors are not subject to the types of attacks that the kernel
    page table isolation feature protects against.  The AMD microarchitecture
    does not allow memory references, including speculative references, that
    access higher privileged data when running in a lesser privileged mode
    when that access would result in a page fault.

    The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time. We expect the security research to be published later today and will provide further updates at that time.

    Howerver, ARM prcessors are affected:

    ARM, whose chip designs are widely used in cell phones and other devices, confirmed some of its chip architectures are affected, including some of its Cortex-A processors. "This method requires malware running locally and could result in data being accessed from privileged memory," ARM said in a statement to Axios. "Our Cortex-M processors, which are pervasive in low-power, connected IoT devices, are not impacted."



  • @KOM:

    AMD's performance is so far behind that even 30% slower the Intel is still faster  and I suspect they have their own issues.

    From what I have read, AMD's latest Threadripper CPUs are giving Intel a run for their money, and they're cheaper.  As for issues, unless you have something concrete then you can't really make that claim.  I've seen others saying the same thing on other tech forums, that this Intel bug is bad but AMD might maybe perhaps possibly have something as bad or worse.  It's pure FUD.

    Sorry to disagree

    Threadripper  does nearly half the work clock per cycle  of an Intel  plus they run much hotter and are less power efficient



  • This was true 15 years ago, can't believe they are still the same.



  • Here is 1 example  the AMD has 8 cores 16 threads  Intel 4 core 8 threads

    https://www.tomsguide.com/us/amd-ryzen-benchmarks,review-4232.html

    I did not reed the post in detail but at a quick look the Intel did better with less cores , I am not trying to make Intel look better just trying to justify if switching to AMD will be worth it  as you still have to buy expensive CPUs like ryzen to get good performance



  • AMD are hit too

    http://bgr.com/2018/01/03/intel-security-flaw-also-arm-amd-macos-already-patched/

    The only thing different looks like Intel are doing something about it and AMD has not responded yet



  • @robi:

    @VAMike:

    AMD CPUs are impacted by this just as much as Intel CPUs.

    Not true

    No, completely true. First, you trimmed off one heck of a lot of context that's really important:

    It's also worth pointing out that this isn't a kernel-specific issue, and that side channel attacks can impact any program that tries to isolate untrusted code. (For example, a browser running javascript.) The kernel mitigations don't fix all of those other programs–and AMD CPUs are impacted by this just as much as Intel CPUs.

    What a lot of fanboys seem to be missing in their urgency to have an intel bonfire is that this is about a class of vulnerabilities, not a specific vulnerability. AMD processors seem at this point to not be vulnerable to one particular mode of attack, but are vulnerable to other modes of attack. And I guarantee that this area of research will get a lot more attention, and there will be other exploit vectors discovered. Side channel attacks have simply not been something that commodity CPU vendors have worried about, so to some degree finding them is like shooting fish in a barrel. (This is true of all the vendors, not just intel.) "Meltdown" is getting most of the press (that which isn't completely confused about the various attack vectors) and is the biggest PITA for shared infrastructure providers, but "Spectre" is actually much harder to fix, and just as relevant to actual users who do things like browse the web. The most straightforward fixes involve giving up any hope of sandboxing potentially malicious code within a process and relying on process isolation instead–which will have a performance impact on everyone's web browsing.

    And as long as we're talking about AMD, they really botched up the disclosure timeline by publicly asserting that they weren't vulnerable to certain kinds of cache timing attacks in the context of the linux kpti patches...people are going to think twice before trusting AMD to keep their mouths shut in the future.



  • @robi:

    Can you please elaborate a little bit this, so we can understand what you mean? Especially the "most pfSense use cases without untrusted local users or a multi-tenant context ".
    The whole pfSense runs as root, including the web interface afaik…

    My understanding of this is that one application running on the OS would be able to improperly read memory used by other applications. Obviously this is bad if some rogue app/script can pull sensitive data from other apps on a workstation.  Also bad if one VM can read data from another. On a dedicated firewall, the OS is not going to be running untrusted apps. I don't see much of an attack vector on a firewall. I certainly wouldn't worry about pfSense until I had Hypervisors, servers, and end user workstations taken care of.



  • @ivor:

    Our preliminary assessment of Meltdown and Spectre vulnerabilities suggests that most pfSense use cases without untrusted local users or a multi-tenant context should not be concerned.

    Once the FreeBSD project issues a patched release, we will incorporate those patches, test, and release new versions of pfSense.

    Engineering question, if the Meltdown and Spectre kernel fixes reduces pfSense performance by 5% or more, is that prudent ?

    If Meltdown and Spectre require malicious code running locally, all bets are off, and there are far easier methods to extract credentials.

    Bottom line, are the Meltdown and Spectre fixes appropriate for an appliance like pfSense ?



  • @lra:

    @ivor:

    Our preliminary assessment of Meltdown and Spectre vulnerabilities suggests that most pfSense use cases without untrusted local users or a multi-tenant context should not be concerned.

    Once the FreeBSD project issues a patched release, we will incorporate those patches, test, and release new versions of pfSense.

    Engineering question, if the Meltdown and Spectre kernel fixes reduces pfSense performance by 5% or more, is that prudent ?

    If Meltdown and Spectre require malicious code running locally, all bets are off, and there are far easier methods to extract credentials.

    Bottom line, are the Meltdown and Spectre fixes appropriate for an appliance like pfSense ?

    From what I can tell both Meltdown and Spectre use very similar methodologies to gain access to L1 cache memory. Looks like they take advantage of speculative out-of-order features, a form of execution parallelism through predictive execution, to access L1 cache by attempting to create an out-of-order execution on one core while another core processes a prior instruction that is meant to cause an exception. It then produces a race-condition where it tries to access L1 cache from within the out-of-order sequence before the processor has time to terminate the original thread by retiring the whole set of instructions and clearing the L1 of memory and code. During this race condition, perhaps 200 clock cycles, it needs to determine if bits in memory are a 1 or a 0, the details which honestly elude me but seem to involve measuring the time caused by side-effecting the microarchitecture. Even after that it still needs to communicate that outside of the process then using the exception-handling to communicate/raise a couple of registers outside of that thread to the process where it can display the contents to the attacker.

    I haven't seen any working meltdown/spectre example code that can get kernel data but a couple that successfully get user-mode memory pages. I'd find it prudent to patch on shared-infrastructure where resources aren't shared at the VM level but at the container level. For pfSense, an attacker would need to have root/wheel access as a prerequisite to the machine, so they wouldn't be needing to compile/inject cache-exploiting code into other processes to see their memory in the first place. For that reason it means it is extremely unlikely to be a primary attack vector on a firewall system.

    As for CPU usage, it's difficult to tell what the performance impact will be. PostgreSQL suggests somewhere between 17% ~ 23%. I think it's fairly significant but for a firewall I don't know if anyone will notice. Our pfSense setup uses perhaps 5% ~ 10% CPU performance, so 23% I don't think will be recognizable … but who knows, maybe it'll affect traffic-shaping. For hypervisors I could see the performance impact being noticeable when systems are at or near computing capacity.





  • This is not a joke anymore. Really.


  • Galactic Empire Netgate Administrator

    @robi:

    @ivor:

    Our preliminary assessment of Meltdown and Spectre vulnerabilities suggests that most pfSense use cases without untrusted local users or a multi-tenant context should not be concerned.

    Can you please elaborate a little bit this, so we can understand what you mean? Especially the "most pfSense use cases without untrusted local users or a multi-tenant context ".
    The whole pfSense runs as root, including the web interface afaik…

    @lra:

    @ivor:

    Our preliminary assessment of Meltdown and Spectre vulnerabilities suggests that most pfSense use cases without untrusted local users or a multi-tenant context should not be concerned.

    Once the FreeBSD project issues a patched release, we will incorporate those patches, test, and release new versions of pfSense.

    Engineering question, if the Meltdown and Spectre kernel fixes reduces pfSense performance by 5% or more, is that prudent ?

    If Meltdown and Spectre require malicious code running locally, all bets are off, and there are far easier methods to extract credentials.

    Bottom line, are the Meltdown and Spectre fixes appropriate for an appliance like pfSense ?

    We will know more information once there's a fix in place so I would rather not speculate now. Once the fix is ready, it will be available in snapshots.



  • @ivor:

    Our preliminary assessment of Meltdown and Spectre vulnerabilities suggests that most pfSense use cases without untrusted local users or a multi-tenant context should not be concerned.

    Once the FreeBSD project issues a patched release, we will incorporate those patches, test, and release new versions of pfSense.

    Could you please elaborate/simplify to understand more about this statement?





  • @AMD_infinium05:

    @ivor:

    Our preliminary assessment of Meltdown and Spectre vulnerabilities suggests that most pfSense use cases without untrusted local users or a multi-tenant context should not be concerned.

    Once the FreeBSD project issues a patched release, we will incorporate those patches, test, and release new versions of pfSense.

    Could you please elaborate/simplify to understand more about this statement?

    The vulnerabilities do not affect pfSense in a usual configuration where there are no local users that could have local execution privileges for untrusted code.


  • Rebel Alliance

    A "Quantum of Solace" for me in that statement - (To coin a phrase)



  • @ivor:

    Our preliminary assessment of Meltdown and Spectre vulnerabilities suggests that most pfSense use cases without untrusted local users or a multi-tenant context should not be concerned.

    Once the FreeBSD project issues a patched release, we will incorporate those patches, test, and release new versions of pfSense.

    This makes sense for PFSense itself, but what about packages like Snort and Suricata that actively evaluate untrusted and malicious code all the time?



  • thank you ufabet



  • @ivor:

    @lra:

    @ivor:

    Our preliminary assessment of Meltdown and Spectre vulnerabilities suggests that most pfSense use cases without untrusted local users or a multi-tenant context should not be concerned.

    Once the FreeBSD project issues a patched release, we will incorporate those patches, test, and release new versions of pfSense.

    Engineering question, if the Meltdown and Spectre kernel fixes reduces pfSense performance by 5% or more, is that prudent ?

    If Meltdown and Spectre require malicious code running locally, all bets are off, and there are far easier methods to extract credentials.

    Bottom line, are the Meltdown and Spectre fixes appropriate for an appliance like pfSense ?

    We will know more information once there's a fix in place so I would rather not speculate now. Once the fix is ready, it will be available in snapshots.

    For Reference …
    DragonFlyBSD Lands Fixes For Meltdown Vulnerability
    https://www.phoronix.com/scan.php?page=news_item&px=DragonFly-Meltdown-Fixed

    "... system call performance is reduced, similar to Linux, when the isolation is enabled. DragonFly reports that system calls go from about 100ns to ~350ns. In typcial workloads they say you should "not lose more than 5% performance or so. System-call heavy and interrupt-heavy workloads (network, database, high-speed storage, etc) can lose a lot more performance."



  • @bfeitell:

    @ivor:

    Our preliminary assessment of Meltdown and Spectre vulnerabilities suggests that most pfSense use cases without untrusted local users or a multi-tenant context should not be concerned.

    Once the FreeBSD project issues a patched release, we will incorporate those patches, test, and release new versions of pfSense.

    This makes sense for PFSense itself, but what about packages like Snort and Suricata that actively evaluate untrusted and malicious code all the time?

    No they don't, what they do is they analyze patterns in the incoming and outgoing connections on both the IP headers and the data payload level and then make decisions based on rules if there is an active threat going on. None of their operations involve an actual execution of untrusted program code, it would be just plain crazy if such thing was allowed.



  • @Chrismallia:

    @KOM:

    AMD's performance is so far behind that even 30% slower the Intel is still faster  and I suspect they have their own issues.

    From what I have read, AMD's latest Threadripper CPUs are giving Intel a run for their money, and they're cheaper.  As for issues, unless you have something concrete then you can't really make that claim.  I've seen others saying the same thing on other tech forums, that this Intel bug is bad but AMD might maybe perhaps possibly have something as bad or worse.  It's pure FUD.

    Sorry to disagree

    Threadripper  does nearly half the work clock per cycle  of an Intel  plus they run much hotter and are less power efficient

    Work per clock cycle is an irrelevant measurement unless you are comparing similar architectures and even then, while it may be interesting, it still doesn't really matter. The relative performance of AMD vs. Intel depends on the workload. (This applies to Ryzen vs. Core as well as Epyc vs. Xeon.)

    Anandtech rated the ThreadRipper as the best overall workstation processor, taking both price and performance into account. Here is a reference: https://www.anandtech.com/show/11891/best-cpus-for-workstations-2017



  • @dotdash:

    I don't see much of an attack vector on a firewall

    What about installs on hypervisors, be it local on, say vmware, or in the cloud at azure or aws?
    That's where the fun begins and that's where more valuable data can be sourced from than from your home with a dedicated pfSense machine, right?



  • Is is possible for pfSense to load updated CPU microcode at kernel boot as in Linux / windows ?



  • Based on what I've read, pfsense users have nothing to worry about if pfsense is installed on a physical machine or if it is installed as a VM along with other virtual appliances on hardware that you own and only you use.

    You start having risks when you are one of many subscribers to a cloud service and you have no idea if the other subscribers are running malware that exploits these vulnerabilities.

    I'm far more worried that for most of us, the cure will be worse than the disease.


 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy