Announcement

Collapse
No announcement yet.

Retpoline v5 Published For Fending Off Spectre Branch Target Injection

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

  • Retpoline v5 Published For Fending Off Spectre Branch Target Injection

    Phoronix: Retpoline v5 Published For Fending Off Spectre Branch Target Injection

    David Woodhouse of Amazon has sent out the latest quickly-revising patches for introducing the "Retpoline" functionality to the Linux kernel for mitigating the Spectre "variant 2" attack...

    http://www.phoronix.com/scan.php?pag...e-v5-Published

  • linuxgeex
    replied
    Originally posted by pal666 View Post
    what are you smoking? threads share memory and can read it without attacks
    I think you just agreed with me. I said it would be limited... to what it should already be able to do.

    Leave a comment:


  • linuxgeex
    replied
    Originally posted by nanonyme View Post

    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
    Thanks for sharing that. I'm sure there's people in the audience who don't recognise that setuid root on typical distros is basically the same thing as "run by root".

    There are differences though if you want/need to use setuid and need strong isolation still. A well set up AppArmor or SELinux config can prevent, or restrict: setuid, sudo, su and even su -, and limit their capabilities. And if those tools don't appeal to you there's always fakeroot, LXC, and KVM.

    Leave a comment:


  • linuxgeex
    replied
    Originally posted by carewolf View Post

    Branch target injection? What part of the security issues allows writing? I thought this was all about reading.
    See Spectre Class 2 CVE-2017-5715. It's still a read-only bug, but when you can read security descriptors, write access is moot.

    Leave a comment:


  • pal666
    replied
    Originally posted by andreano View Post
    … 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."
    you conveniently forgot part of quote which says that dll in question is ntdll. i can't comment on windows and i don't care about windows
    Originally posted by andreano View Post
    Note that that's only for the side channel.
    note that side channel is the only way to read the answer

    Leave a comment:


  • nanonyme
    replied
    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

    Leave a comment:


  • ext73
    replied
    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

    Leave a comment:


  • andreano
    replied
    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.

    Leave a comment:


  • pal666
    replied
    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

    Leave a comment:


  • pal666
    replied
    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

    Leave a comment:

Working...
X