Announcement

Collapse
No announcement yet.

An Initial Look At Spectre V4 "Speculative Store Bypass" With AMD On Linux

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • starshipeleven
    replied
    Originally posted by Royi View Post
    I rather have specific performance hit in some applications which are suspicious to this attacks than a system wide performance hit.
    I accept that I don't know enough nor I want to invest the time into becoming a policeman of my PC's applications, so I apply the biggest blanket protection I can get on my main system while I don't care on my gaming rig (which is running SpywareOS/Windows 10 anyway).

    I don't like having to follow what happens and what application suddenly becomes suspicious and what does not, or having to check for applications or sites or whatever. I don't run very intensive applications anyway, the bigger impact is for serious workloads, not for office work and watching cat videos.

    I wonder how much of those attack are feasible not in a paper but actually used by hackers with limited resources (Not countries) without privileged access to the system.
    There is a trade of malware SDKs where very good hackers (or actual companies made by hackers or "software security consultants") sell a SDK to build malware exploiting something on the black market.
    The less skilled hackers only need to pay the price, add a payload and deploy it, so it's not like all hackers using some exploit are actually good enough to discover new stuff or be "real" hackers at all. It's a businness.

    That said, malware using Spectre and Meltdown was detected in the wild pretty soon, around a hundred https://www.securityweek.com/malware...-flaws-emerges while still technically "using PoC code" (PoC = proof of concept, aka they took the same code used in the papers that found the vulnerabilities) it does mean there is interest in that, the malware found were mostly to "test the waters" so to speak.
    Also javascript-based stuff.
    At the end of january 2018.

    Leave a comment:


  • Royi
    replied
    I rather have specific performance hit in some applications which are suspicious to this attacks than a system wide performance hit.

    Again, I'm not an expert, but from I read over the net from people who seems to understand those issues regular users on CPU which doesn't share multi sessions the problem is almost non existent.
    Given the risk and performance hit balance, I chose to keep the performance.

    Given that it was also the default in Spectre V4 it seems it is not crazy thing to do.
    I wonder how much of those attack are feasible not in a paper but actually used by hackers with limited resources (Not countries) without privileged access to the system.

    This is an interesting discussion and I wonder if there is a community that can have in depth discussion about that.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by Royi View Post
    If Chrome wasn't an OS already I'd be worried it was becoming one, by re-implementing all these OS-level features.

    The part about isolating sites from each other is fixing something was an issue already, even before these vulnerabilities, Noscript Firefox addon is well-known for its ability to intercept cross-site scripting. That's genuinely cool and useful, no complaints, but claiming it also protects from side-channel attacks... is technically right but there was an easier way to spill over other open sites for javascript, so whatever. The main risk added is breaking the sandbox and affecting the system.

    Which they claim to mitigate to some extent by re-mapping (it's basically doing a IOMMU/VT-d) memory addresses of memory assigned to javascript code so that if it does a side-channel then it gets bogus addresses(?), and introduces jittery in timer functions to throw off attacks using them as clock. How effective this actually is at stopping an application from breaking the sandbox? What about performance hit? On paper it's easy to sound legit, but it's not a trivial thing to pull off. Only way is to do some audits on a bigass codebase like Chromium.

    I still think that kernel-side mitigations are much better. Sure they won't isolate a site's javascript from another site (which as I said is nice and a welcome feature), but it's just a few functions less than a hundred lines long that are swapped in the place of the unsafe ones.

    Leave a comment:


  • Royi
    replied
    Regarding Chrome, here it is:

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by Royi View Post
    I'm not an expert on that.
    But Google and Mozilla (I believe WebKit as well) took care of that in their implementation.
    Since I don't run much software on my system besides few applications from trusted resources I'm not troubled by those issues.

    Again, they should mostly alert the cloud services.
    I, as a an average user would more appreciate to have the performance I bought.
    It is a security issue for desktop PCs, period. You might not care, you might make your own choice with your own hardware, and that's fine and I respect that.

    But statements like "it's an issue only for cloud services" or "I believe Google/Mozilla fixed this on their side" are just bullshit misinformation and you should not spread that.

    (for the record, userspace has no control over this kind of stuff as it just just issues the same calls to the kernel, Google/Mozilla cannot fix this from their side, it either gets mitigated by the kernel or by the hardware)

    Leave a comment:


  • Royi
    replied
    Originally posted by darkbasic View Post

    I suppose that you don't browse the web, right? Otherwise I strongly advice you to NOT do that.
    I'm not an expert on that.
    But Google and Mozilla (I believe WebKit as well) took care of that in their implementation.
    Since I don't run much software on my system besides few applications from trusted resources I'm not troubled by those issues.

    Again, they should mostly alert the cloud services.
    I, as a an average user, would more appreciate to have the performance I bought then dealing with edge case which mostly irrelevant to my system.
    Last edited by Royi; 23 May 2018, 04:17 PM.

    Leave a comment:


  • darkbasic
    replied
    Originally posted by Royi View Post

    First, thank you for sharing this, I'm gonna do that now.
    I suppose that you don't browse the web, right? Otherwise I strongly advice you to NOT do that.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by Royi View Post
    It does because they require elevated privileges and if you're the user of the PC and some unwanted software gained elevated privileges you're doomed whether you're patched to those vulnerabilities or not.

    The problem in multi user case (Multi user in the sense at the same time, like in Cloud VM providers) that one user which compromised can be a risk to other users due to leaks of data.
    All do more than that, as they allow to compromise sandbox environments and managed code execution even if you don't have higher privileges.
    In January, the world became aware of a new class of security threat that allows attackers to exploit common industry-wide performance optimizations of modern microprocessors (aka chips). Almost every kind of computing device was affected - from servers, workstations, and laptops, to tablets, smartphones, and other gadgets. As such, “Meltdown” and “Spectre” had a significant impact across the industry.


    Unlike in previous attacks, Speculative Store Buffer Bypass (usually) allows only reading of memory locations from within the same privilege level. Thus, it would allow only a kernel to attack itself, or an application to read memory to which it already has legitimate access. It would, therefore, seem that such accesses are harmless and that it is implicitly safe to allow aggressive speculation. Unfortunately, this is not the case.

    One potential problem arises when an application is implementing a sandbox or other attempt at isolation within a single running process. In this case, there are really two active contexts: the trusted sandbox environment, and the untrusted code running within it. Microprocessors are designed with the concept of different privilege levels, and of course, our entire computing world relies upon this in order to isolate processes and virtual machines from one another. But microprocessor designers don’t (traditionally) factor in separated contexts within the same process (same privilege or exception level). As a result, untrusted (possibly malicious) code can run within a sandbox and abuse store buffer speculation to read sensitive data from the sandbox itself.

    In the common case of managed code environments (such as Java or JavaScript), an ability for a managed code to dump arbitrary content from its managing process could be fatal to the security of the application, or of other applications running within the same shared process. The attack is possible because the code may be constructed to appear to perform benign reads of values to which it has legitimate access. These accesses are seen by the runtime security checks that validate the managed code prior to allowing it to execute. Unfortunately, the untrusted managed code could, in fact, be abusing speculation to see unsafe previous values of memory variables, pointers, and sensitive security structures through a cache side channel.


    Note that javascript is run in web browsers and GNOME, for example.

    Leave a comment:


  • Royi
    replied
    Originally posted by dungeon View Post

    Just boot a kernel with nothis nothat parameters:

    Code:
    nopti nospectre_v2 nospec_store_bypass_disable
    or if you does not like nothis nothat then do this=off that=off

    Code:
    pti=off spectre_v2=off spec_store_bypass_disable=off
    After booting check info what is enabled/disabled, what you are vulnerable or not currently, what mitigation is used or so, just run:

    Code:
    cat /sys/devices/system/cpu/vulnerabilities/*
    On enabled mitigations lines would start with Mitigation: blah blah otherwise Vulnerable or Not affected

    For microcode based mitigations some distros do things on their own so provide nospec or whatever parameter or one can just remove firmware, revert to older one if available, etc...
    First, thank you for sharing this, I'm gonna do that now.
    Am I right those should be updated in the GRUB file by sudo nano /etc/default/grub and then looking for GRUB_CMDLINE_LINUX_DEFAULT="<Kernel Parameters>"?

    For instance:

    Code:
    GRUB_CMDLINE_LINUX_DEFAULT="quiet splash elevator=cfq pti=off spectre_v2=off spec_store_bypass_disable=off"
    What I'd like to see is the performance impact of each flag (8 Combinations).
    Also I wonder if it makes sense to turn those off while the MicroCode is updated (Does that hurt performance?).
    Last edited by Royi; 25 May 2018, 12:15 PM.

    Leave a comment:


  • Royi
    replied
    Originally posted by starshipeleven View Post
    "single user PC" is not relevant to what these vulnerabilities do, applications can use them to pwn the OS or other applications regardless of the amount of users in the system.
    It does because they require elevated privileges and if you're the user of the PC and some unwanted software gained elevated privileges you're doomed whether you're patched to those vulnerabilities or not.

    The problem in multi user case (Multi user in the sense at the same time, like in Cloud VM providers) that one user which compromised can be a risk to other users due to leaks of data.

    Leave a comment:

Working...
X