5 ms·

Basically, let's say there's a syscall that takes a user buffer and size and copies it into kernel stack for processing. (This is common.) If you overflow tha

Basically, let's say there's a syscall that takes a user buffer and size and copies it into kernel stack for processing. (This is common.) If you overflow that buffer, you can overwrite the return address in the kernel stack, which you can then launch into ROP.

userbinator 9y ago
If you overflow that buffer, you can overwrite the return address in the kernel stack, which you can then launch into ROP. The crucial point here being that there must already be an existing overflow vulnerability in the kernel. Knowing all the addresses is no use if you can't force execution to go to them.
- rincebrain 9y ago
  The hypothesis I've seen, and why people seem to be rushing to patch it without explaining, is that you might be able to not only leak addresses, but actual data, from any ring, into unprivileged code, at which point, your security model is burned to the ground. AIUI, the present circumstances are: - there exists a public PoC from some researchers of side-channel leaking kernel address information into userland via JavaScript which may be unrelated - there exists a Xen security embargo that expires Thursday that might be unrelated - AWS and Azure have scheduled reboots of many things for maintenance in the next week, which seems unlikely to be unrelated to the Xen embargo - a feature that appears to be geared toward preventing a side-channel technique of unknown power has been rushed into Linux for Intel-only (both x86_64 and ARM from Intel) - a similar class of prevention technique has been landed in Windows since November for both Intel and AMD x86_64 chips (no idea about ARM) - the rush surrounding this, and people being amazingly willing to land fixes that imply a 5-30% performance impact, strongly suggest that unlike almost every major CPU bug in the last decade, you can't fix or even work around this with a microcode update for the affected CPUs, which is _huge_. The AMD TLB bug, the AMD tight loop bug that DFBSD found, even the Intel SGX flaws that made them repeatedly disable SGX on some platforms - all of them could be worked around with BIOS or microcode updates. This, apparently, cannot. (Either that or they're rushing out fixes because there's live exploit code somewhere and they haven't had time to write a microcode fix yet, but O(months) seems like they probably concluded they outright can't, rather than haven't yet.)
  - j_s 9y ago
    Thanks for summarizing. Does anyone have time to link to more on the "side-channel leaking kernel address information into userland via JavaScript" ?
    - agency 9y ago
      This isn't exactly that, but here[1] is a talk linked in the post from the other day which shows a PoC breaking ASLR in Linux from JavaScript running in the browser, via a timing attack on the MMU. There's a demo a half hour in. EDIT: This post[2] discusses the specific speculative execution cache attack and claims there is a JavaScript PoC (but doesn't cite a source for that claim) [1] https://www.youtube.com/watch?v=ewe3-mUku94 https://www.youtube.com/watch?v=ewe3-mUku94 [2] https://plus.google.com/+KristianK%C3%B6hntopp/posts/Ep26AoAZxxd https://plus.google.com/+KristianK%C3%B6hntopp/posts/Ep26AoA...
      - rincebrain 9y ago
        [1] was what I was referencing, thank you. Also, RUH-ROH. https://twitter.com/brainsmoke/status/948561799875502080 https://twitter.com/brainsmoke/status/948561799875502080
  - rincebrain 9y ago
    Addendum for anyone still reading: - Intel issued a press release saying they planned to announce this next week after more vendors had patched their shit, which lends me more cause to believe that the Xen bug might be the same one [1] - Intel claims in the same PR that "many types of computing devices — with many different vendors’ processors" are affected, so I'll be curious to see whether non-Intel platforms fall into the umbrella soon - macOS implemented partial mitigations in 10.13.2 and apparently has some novel ones coming up in 10.13.3 [2] - someone reasonably respected claims to have a private PoC of this bug leaking kernel memory [3] - ARM64 has KPTI patches that aren't in Linus's tree yet [4] [6] ([6] is just a link showing the patches from 4 aren't in Linus's tree as of this writing) - all the other free operating systems appear to have been left out of the embargoed party (until recently, in FBSD's case), so who knows when they'll have mitigations ready [5] - So far, Microsoft appears to have only patched Windows 10, so it's unknown whether they intend to backport fixes to 7 or possibly attempt to use this as another crowbar to get people off of XP 2.0 - Update: Microsoft is pushing an OOB update later today that will auto-apply to Win10 but not be forced to auto-apply on 7 and 8 until Tuesday, so that's nice [7] [1] - https://newsroom.intel.com/news/intel-responds-to-security-research-findings/ https://newsroom.intel.com/news/intel-responds-to-security-r... [2] - https://twitter.com/aionescu/status/948609809540046849 https://twitter.com/aionescu/status/948609809540046849 [3] - https://twitter.com/brainsmoke/status/948561799875502080 https://twitter.com/brainsmoke/status/948561799875502080 [4] - https://patchwork.kernel.org/patch/10095827/ https://patchwork.kernel.org/patch/10095827/ [5] - https://lists.freebsd.org/pipermail/freebsd-security/2018-January/009651.html https://lists.freebsd.org/pipermail/freebsd-security/2018-Ja... [6] - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/arch/arm64?h=v4.15-rc6&qt=grep&q=kpti https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [7] - https://www.theverge.com/2018/1/3/16846784/microsoft-processor-bug-windows-10-fix https://www.theverge.com/2018/1/3/16846784/microsoft-process...

userbinator 9y ago

If you overflow that buffer, you can overwrite the return address in the kernel stack, which you can then launch into ROP. The crucial point here being that there must already be an existing overflow vulnerability in the kernel. Knowing all the addresses is no use if you can't force execution to go to them.

rincebrain 9y ago
The hypothesis I've seen, and why people seem to be rushing to patch it without explaining, is that you might be able to not only leak addresses, but actual data, from any ring, into unprivileged code, at which point, your security model is burned to the ground. AIUI, the present circumstances are: - there exists a public PoC from some researchers of side-channel leaking kernel address information into userland via JavaScript which may be unrelated - there exists a Xen security embargo that expires Thursday that might be unrelated - AWS and Azure have scheduled reboots of many things for maintenance in the next week, which seems unlikely to be unrelated to the Xen embargo - a feature that appears to be geared toward preventing a side-channel technique of unknown power has been rushed into Linux for Intel-only (both x86_64 and ARM from Intel) - a similar class of prevention technique has been landed in Windows since November for both Intel and AMD x86_64 chips (no idea about ARM) - the rush surrounding this, and people being amazingly willing to land fixes that imply a 5-30% performance impact, strongly suggest that unlike almost every major CPU bug in the last decade, you can't fix or even work around this with a microcode update for the affected CPUs, which is _huge_. The AMD TLB bug, the AMD tight loop bug that DFBSD found, even the Intel SGX flaws that made them repeatedly disable SGX on some platforms - all of them could be worked around with BIOS or microcode updates. This, apparently, cannot. (Either that or they're rushing out fixes because there's live exploit code somewhere and they haven't had time to write a microcode fix yet, but O(months) seems like they probably concluded they outright can't, rather than haven't yet.)
- j_s 9y ago
  Thanks for summarizing. Does anyone have time to link to more on the "side-channel leaking kernel address information into userland via JavaScript" ?
  - agency 9y ago
    This isn't exactly that, but here[1] is a talk linked in the post from the other day which shows a PoC breaking ASLR in Linux from JavaScript running in the browser, via a timing attack on the MMU. There's a demo a half hour in. EDIT: This post[2] discusses the specific speculative execution cache attack and claims there is a JavaScript PoC (but doesn't cite a source for that claim) [1] https://www.youtube.com/watch?v=ewe3-mUku94 https://www.youtube.com/watch?v=ewe3-mUku94 [2] https://plus.google.com/+KristianK%C3%B6hntopp/posts/Ep26AoAZxxd https://plus.google.com/+KristianK%C3%B6hntopp/posts/Ep26AoA...
    - rincebrain 9y ago
      [1] was what I was referencing, thank you. Also, RUH-ROH. https://twitter.com/brainsmoke/status/948561799875502080 https://twitter.com/brainsmoke/status/948561799875502080
- rincebrain 9y ago
  Addendum for anyone still reading: - Intel issued a press release saying they planned to announce this next week after more vendors had patched their shit, which lends me more cause to believe that the Xen bug might be the same one [1] - Intel claims in the same PR that "many types of computing devices — with many different vendors’ processors" are affected, so I'll be curious to see whether non-Intel platforms fall into the umbrella soon - macOS implemented partial mitigations in 10.13.2 and apparently has some novel ones coming up in 10.13.3 [2] - someone reasonably respected claims to have a private PoC of this bug leaking kernel memory [3] - ARM64 has KPTI patches that aren't in Linus's tree yet [4] [6] ([6] is just a link showing the patches from 4 aren't in Linus's tree as of this writing) - all the other free operating systems appear to have been left out of the embargoed party (until recently, in FBSD's case), so who knows when they'll have mitigations ready [5] - So far, Microsoft appears to have only patched Windows 10, so it's unknown whether they intend to backport fixes to 7 or possibly attempt to use this as another crowbar to get people off of XP 2.0 - Update: Microsoft is pushing an OOB update later today that will auto-apply to Win10 but not be forced to auto-apply on 7 and 8 until Tuesday, so that's nice [7] [1] - https://newsroom.intel.com/news/intel-responds-to-security-research-findings/ https://newsroom.intel.com/news/intel-responds-to-security-r... [2] - https://twitter.com/aionescu/status/948609809540046849 https://twitter.com/aionescu/status/948609809540046849 [3] - https://twitter.com/brainsmoke/status/948561799875502080 https://twitter.com/brainsmoke/status/948561799875502080 [4] - https://patchwork.kernel.org/patch/10095827/ https://patchwork.kernel.org/patch/10095827/ [5] - https://lists.freebsd.org/pipermail/freebsd-security/2018-January/009651.html https://lists.freebsd.org/pipermail/freebsd-security/2018-Ja... [6] - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/arch/arm64?h=v4.15-rc6&qt=grep&q=kpti https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [7] - https://www.theverge.com/2018/1/3/16846784/microsoft-processor-bug-windows-10-fix https://www.theverge.com/2018/1/3/16846784/microsoft-process...