Announcement

Collapse
No announcement yet.

Retpoline v5 Published For Fending Off Spectre Branch Target Injection

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

  • #11
    Originally posted by linuxgeex View Post

    The kernel, and all programs on systems that want their user space to have enforcing isolation. Without this, root exploits become trivial with local code execution. So then any system which has a risk of remote arbitrary code execution (anything with a web browser, email client, users, or network-accessible services) needs to have at a minimum all binaries that might be run by root recompiled in order to prevent Sally hijacking root, and all binaries that will be run by users recompiled to prevent Sally from hijacking Bob. Basically without this patch there's no longer meaningful posix groups, permissions, ACLs, namespaces, SELINUX or AppArmor.

    Just to be clear, recompiling protects the recomplied binary only, not other parts of the system, so if you recompiled everything but the browser then users could hijack each other's browser, and trojans from another user could access your browser while it is running. This isn't a big deal for single-user systems where you can point the finger at yourself, but its a huge problem for shared systems with potentially mutually-untrusting users like CPanel accounts.

    One of the reasons Linux users like to believe their systems are more secure than Windows is the set of isolation enforcing security mechanisms, all of which can be bypassed with branch target injection.

    Retpoline solves one type of branch target injection. There will be more patches coming. Spectre affords a lot more opportunities than just branch target injection... this is going to be a very interesting year.

    I've read that Nested Paging is unaffected by Spectre, so perhaps instead of KPTI (Kernel Page Table Isolation) we will have PPTPI (Per-Process Page Table Isolation) inside this year, and then Spectre attacks will be limited to attacks between threads of a process. The overhead will be significant but at least we'll have working isolation again. Until then, I recommend running your browser in Virtualbox and using its shared folder feature to share your Downloads folder with the VM, and if you are keeping documents that you want protected, run the related apps in another Virtualbox, snapshot the volumes daily, and keep backups on a NAS via crontab/rsync. It's a pain but I'd rather waste 30 seconds a day saving a snapshot than lose an entire day's (or worse) work.
    Branch target injection? What part of the security issues allows writing? I thought this was all about reading.

    Comment


    • #12
      Originally posted by Kayote View Post
      hence all this patches need to be backported to androids running 3.xx kernels is going to take a long time to update all those android devices, for a long time a lot will be exposed.
      None will ever update that, it will be already great if new devices will have the fix in the next 2 years.

      Comment


      • #13
        GKH has a nice write up here of fixes so far: http://kroah.com/log/blog/2018/01/06/meltdown-status/

        Seems like all the fixes for spectre will take a while, microcode updates, and gcc/llvm updates, and recompiling everything. Hopefully everyone will get microcode updates without the need for BIOS updates on desktops/laptops. As far as android phones go, now would be a good time to get lineage or paranoid android flashed on your phone. They will get the updates pushed to AOSP Kayote .

        If you're on ubuntu+intel and can't wait to get the kernel meltdown fix, you can get 4.14.12 from kernel.org, copy a /boot/config-* to .config in the newly unzipped directory, do make olddefconfig && make -j* bindeb-pkg in the directory, and install the resulting 3 *.deb packages. Reboot, and you should be running the kernel with KPTI. To verify you can do: dmesg | grep 'page tables isolation'

        Comment


        • #14
          Also, it seems like the initial targets for Spectre have been the ebpf toolkit, and javascript VMs, the JIT compilers in both of them. Hopefully your browser has already updated itself.

          Comment


          • #15
            remember that there were a lot of stuff revealed as part of spetre/meltdown.


            basically, you can split it into two part.



            the first part is what nearly every CPU is susceptible to except a few non speculatively executing (so everyone except Intel's Atoms, ARM's older cores, etc.)

            It is speculative execution working as it is supposed to work: CPU tries to keep the pipeline fed. When it is not sure which is the next path, because there a branching (because there's an "if" test) the CPU takes which of the two paths is the most likely and will feed the instructions into the pipeline to prepare the work. if the guess turn out wrong, the CPU throws away the work, so no wrong result is stored. but some of the effects of this preparation done in advance might be measurable: eg page were prefetched in cache.

            the surface attack is rather limited.

            (running arbitrary code in JIT, as mentioned in some post).





            but then, there's the problem of Intel CPUs, were Intel has done some dangerous optimisation.

            (these are the "variants" of specte, and meltdown utself).



            the branching attack is about abusing how some specific intel cpu make their guess by making collisions in the tables.
            i.e.: CPU learns that after instruction A code always jumps to position B (because that's how the attacker program is written) then when the CPU finds an instruction C it gets confused and guesses point B again (same hashes in the tables of that Intel CPU) even if it was never supposed to go there at all.


            that is the scary variants of spectre where on select Intel CPU (as long as you know how their prediction table are learning/gettibg filled) you can make *Other user land Apps* jump at arbitrary positions and measure the side effect (cache prefetch) that aren't part of thr rollback when the guess turns out wrong.

            Retpoline (return trampolines) are a way around this.

            Comment


            • #16
              Originally posted by andreano View Post
              I don't follow you. Isn't the whole point of Spectre to read memory from one userspace program to another (not via the kernel)?
              only if your two programs share memory mappings. which is when you write those programs specifically to demonstrate spectre or when one of the programs is the kernel

              Comment


              • #17
                Originally posted by linuxgeex View Post
                and then Spectre attacks will be limited to attacks between threads of a process.
                what are you smoking? threads share memory and can read it without attacks

                Comment


                • #18
                  Originally posted by pal666 View Post
                  only if your two programs share memory mappings. Which is …
                  … when two programs use the same shared library? That's how I interpret the Spectre doc: "some shared DLL memory was chosen for performing flush-and-probe detections."

                  Note that that's only for the side channel. The part about telling that other program what to read, and making it load a cache line based on that, does not depend on shared memory.

                  So I'm pretty skeptical that the kernel is necessarily involved, but I don't fully understand that side channel either.

                  Comment


                  • #19
                    Originally posted by audi100quattro View Post
                    GKH has a nice write up here of fixes so far: http://kroah.com/log/blog/2018/01/06/meltdown-status/

                    Seems like all the fixes for spectre will take a while, microcode updates, and gcc/llvm updates, and recompiling everything. Hopefully everyone will get microcode updates without the need for BIOS updates on desktops/laptops. As far as android phones go, now would be a good time to get lineage or paranoid android flashed on your phone. They will get the updates pushed to AOSP Kayote .

                    If you're on ubuntu+intel and can't wait to get the kernel meltdown fix, you can get 4.14.12 from kernel.org, copy a /boot/config-* to .config in the newly unzipped directory, do make olddefconfig && make -j* bindeb-pkg in the directory, and install the resulting 3 *.deb packages. Reboot, and you should be running the kernel with KPTI. To verify you can do: dmesg | grep 'page tables isolation'
                    They can also use our kernels

                    Comment


                    • #20
                      Originally posted by linuxgeex View Post

                      The kernel, and all programs on systems that want their user space to have enforcing isolation. Without this, root exploits become trivial with local code execution. So then any system which has a risk of remote arbitrary code execution (anything with a web browser, email client, users, or network-accessible services) needs to have at a minimum all binaries that might be run by root recompiled in order to prevent Sally hijacking root, and all binaries that will be run by users recompiled to prevent Sally from hijacking Bob. Basically without this patch there's no longer meaningful posix groups, permissions, ACLs, namespaces, SELINUX or AppArmor.

                      Just to be clear, recompiling protects the recomplied binary only, not other parts of the system, so if you recompiled everything but the browser then users could hijack each other's browser, and trojans from another user could access your browser while it is running. This isn't a big deal for single-user systems where you can point the finger at yourself, but its a huge problem for shared systems with potentially mutually-untrusting users like CPanel accounts.

                      One of the reasons Linux users like to believe their systems are more secure than Windows is the set of isolation enforcing security mechanisms, all of which can be bypassed with branch target injection.

                      Retpoline solves one type of branch target injection. There will be more patches coming. Spectre affords a lot more opportunities than just branch target injection... this is going to be a very interesting year.

                      I've read that Nested Paging is unaffected by Spectre, so perhaps instead of KPTI (Kernel Page Table Isolation) we will have PPTPI (Per-Process Page Table Isolation) inside this year, and then Spectre attacks will be limited to attacks between threads of a process. The overhead will be significant but at least we'll have working isolation again. Until then, I recommend running your browser in Virtualbox and using its shared folder feature to share your Downloads folder with the VM, and if you are keeping documents that you want protected, run the related apps in another Virtualbox, snapshot the volumes daily, and keep backups on a NAS via crontab/rsync. It's a pain but I'd rather waste 30 seconds a day saving a snapshot than lose an entire day's (or worse) work.
                      Maybe also every program with setuid. Also every interpreter (bash, Perl etc) since someone might want to run setuid scripts through it. Otherwise you might get to read memory as root

                      Comment

                      Working...
                      X