Announcement

Collapse
No announcement yet.

Google Publishes "Leaky.Page" Showing Spectre In Action Within Web Browsers

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

  • Google Publishes "Leaky.Page" Showing Spectre In Action Within Web Browsers

    Phoronix: Google Publishes "Leaky.Page" Showing Spectre In Action Within Web Browsers

    Google has published their proof-of-concept code showing the practicality of Spectre exploits within modern web browsers' JavaScript engines. The code is out there and you can even try it for yourself on the leaky.page web-site...

    https://www.phoronix.com/scan.php?pa...y.Page-Spectre

  • #2
    Yup, that's terrifying. Don't run untrusted code in your browser even if you think you have a sandbox.

    Comment


    • #3
      So we can finally ignore all of the people who've had their head in the sand saying "It's not a problem as there are no practical working exploits."?

      Comment


      • #4
        I don't understand.
        If I run:
        Code:
        grep . /sys/devices/system/cpu/vulnerabilities/* 
        I get the following result:
        Code:
        /sys/devices/system/cpu/vulnerabilities/itlb_multihit:KVM: Mitigation: VMX disabled
        /sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
        /sys/devices/system/cpu/vulnerabilities/mds:Mitigation: Clear CPU buffers; SMT disabled
        /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
        /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
        /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
        /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, RSB filling
        /sys/devices/system/cpu/vulnerabilities/srbds:Mitigation: Microcode
        /sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Mitigation: Clear CPU buffers; SMT disabled
        Code:
        
        

        So it seems that all should be mitigated, but the leaky.page works in any case.

        Comment


        • #5
          Originally posted by Xwaang View Post
          I don't understand.
          Code:
          /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp

          So it seems that all should be mitigated, but the leaky.page works in any case.
          The one I cropped means that the mitigation is disabled by default and needs to be enabled by using prctl() or seccomp(). Chromium should be enabling it for its processes by default tho...

          Comment


          • #6
            Originally posted by microcode View Post
            Yup, that's terrifying. Don't run untrusted code in your browser even if you think you have a sandbox.
            Are you telling us not to visit any sites except for those hosted at 127.0.0.1 (and only after you've read the code!) ?

            Comment


            • #7
              Originally posted by Xwaang View Post
              I don't understand.
              If I run:
              Code:
              grep . /sys/devices/system/cpu/vulnerabilities/* 
              I get the following result:
              Code:
              /sys/devices/system/cpu/vulnerabilities/itlb_multihit:KVM: Mitigation: VMX disabled
              /sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
              /sys/devices/system/cpu/vulnerabilities/mds:Mitigation: Clear CPU buffers; SMT disabled
              /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
              /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
              /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
              /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, RSB filling
              /sys/devices/system/cpu/vulnerabilities/srbds:Mitigation: Microcode
              /sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Mitigation: Clear CPU buffers; SMT disabled
              Code:
              
              

              So it seems that all should be mitigated, but the leaky.page works in any case.
              In this case, the target memory is in the same process, so you might have some protection from other processes with mitigations (though no guarantee of that).

              Comment


              • #8
                Originally posted by Xwaang View Post
                I don't understand.
                If I run:
                Code:
                grep . /sys/devices/system/cpu/vulnerabilities/* 
                I get the following result:
                Code:
                /sys/devices/system/cpu/vulnerabilities/itlb_multihit:KVM: Mitigation: VMX disabled
                /sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
                /sys/devices/system/cpu/vulnerabilities/mds:Mitigation: Clear CPU buffers; SMT disabled
                /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
                /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
                /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
                /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, RSB filling
                /sys/devices/system/cpu/vulnerabilities/srbds:Mitigation: Microcode
                /sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Mitigation: Clear CPU buffers; SMT disabled
                Code:
                
                

                So it seems that all should be mitigated, but the leaky.page works in any case.
                Well, it might be a stretch to say this but one of two things must be true based on this leaky.page thing: 1) the above showing these are mitigated is bullshit in reality or 2) Google showing PoC *only* in Chrome is bullshit/smoke and mirrors. Why doesn't this repro in other browsers? it should if the PoC is coded correctly, no? Either way, I call bullshit on this PoC. Repro on other browsers or GTFO.

                Comment


                • #9
                  Just another reason to keep js off by default

                  Comment


                  • #10
                    Originally posted by kozman View Post
                    Why doesn't this repro in other browsers? it should if the PoC is coded correctly, no? Either way, I call bullshit on this PoC. Repro on other browsers or GTFO.
                    It could be that the exploit needs to be tuned to the particular JIT engine, in which case they certainly could do it but haven't invested the time.

                    Comment

                    Working...
                    X