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

  • #11
    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.
    https://www.redhat.com/en/blog/specu...t-how-it-works

    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.

    Comment


    • #12
      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.
      ## VGA ##
      AMD: X1950XTX, HD3870, HD5870
      Intel: GMA45, HD3000 (Core i5 2500K)

      Comment


      • #13
        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.

        Comment


        • #14
          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)

          Comment


          • #15
            Regarding Chrome, here it is:

            https://www.chromium.org/Home/chromium-security/ssca

            Comment


            • #16
              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.

              Comment


              • #17
                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.

                Comment


                • #18
                  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.

                  Comment


                  • #19
                    Can Spectre (any variant) read or leak memory from a different process? Furthermore, can it leak memory from another user's processes? i.e. can alice read memory of processes from bob?

                    If not, it's a complete non-issue for desktop use.

                    Comment


                    • #20
                      People must keep in mind that what one can or cannot do exploiting a vulnerability is always an open question. This is true for all vulnerabilities and specially so for Spectre (being a new class of attack that we are just starting to deal with now).
                      And you can be sure we will have Spectre 5, 6, ....

                      Also, keep in mind that hackers can combine multiple vulnerabilites to achieve a larger security hole. So maybe someone is sitting on a 0-day exploit that could not achieve much but now combine it with this and that new vuln and voilá, a new attack vector is born.

                      It is really complex and a moving field, best course of action is to play it safe.

                      Comment

                      Working...
                      X