9 ms·

Bigger than KASLR it seems. https://twitter.com/brainsmoke/status/948561799875502080 https://twitter.com/brainsmoke/status/948561799875502080 Not good.

tptacek 9y ago
That's a tweet of someone using the bug to defeat KASLR.
- monocasa 9y ago
  It looks like he's reading actual data from kernel space.
- blattimwind 9y ago
  I'm fairly sure he's actually reading from the syscall table. He already defeated KASLR when he typed /proc/kallsyms. That aside, I don't think KASLR would be important enough to rush KPTI like it has happened now and to even enable it by default, given its drawbacks.
  - tptacek 9y ago
    Sorry, I'm being imprecise. Yes, they're reading from kernel memory. But the specific thing they're reading is useful as a KASLR bypass. I think I understand that the subtext of this thread is: can you only bypass KASLR with it, or can you read pretty much anything from kernel memory? And yeah: it sure seems like you can work out arbitrary kernel values; it's hard to think of a way this bug could work where you can figure out the symbols of specific kernel functions, but not arbitrary values in the kernel.
    - monocasa 9y ago
      If you know the specific kernel being used, all you have to figure out is the base address of the kernel to have to whole layout to break KASLR. So if it had been a timing attack where an unmapped memory reference takes longer to fail than a memory reference with the wrong permissions, then you could scan all of the KASLR slots without actually reading back any data. Actually reading data is a waaaaayyy bigger deal.
      - tptacek 9y ago
        Yeah, that's true. I hadn't considered that the fragility of KASLR meant that there are lots of vectors for breaking it that don't require a huge chip break. Sorry, I'm making the thread dumber. But, I mean: that's what that dude is doing in that tweet, is all I'm saying. :)
- klt0825 9y ago
  By reading from the actual memory address, yes. Defeating kASLR with side channels is meh. Reading from actual addresses is a different matter entirely.
  - deleted 9y ago
    [deleted]

tptacek 9y ago

That's a tweet of someone using the bug to defeat KASLR.

monocasa 9y ago
It looks like he's reading actual data from kernel space.
blattimwind 9y ago
I'm fairly sure he's actually reading from the syscall table. He already defeated KASLR when he typed /proc/kallsyms. That aside, I don't think KASLR would be important enough to rush KPTI like it has happened now and to even enable it by default, given its drawbacks.
- tptacek 9y ago
  Sorry, I'm being imprecise. Yes, they're reading from kernel memory. But the specific thing they're reading is useful as a KASLR bypass. I think I understand that the subtext of this thread is: can you only bypass KASLR with it, or can you read pretty much anything from kernel memory? And yeah: it sure seems like you can work out arbitrary kernel values; it's hard to think of a way this bug could work where you can figure out the symbols of specific kernel functions, but not arbitrary values in the kernel.
  - monocasa 9y ago
    If you know the specific kernel being used, all you have to figure out is the base address of the kernel to have to whole layout to break KASLR. So if it had been a timing attack where an unmapped memory reference takes longer to fail than a memory reference with the wrong permissions, then you could scan all of the KASLR slots without actually reading back any data. Actually reading data is a waaaaayyy bigger deal.
    - tptacek 9y ago
      Yeah, that's true. I hadn't considered that the fragility of KASLR meant that there are lots of vectors for breaking it that don't require a huge chip break. Sorry, I'm making the thread dumber. But, I mean: that's what that dude is doing in that tweet, is all I'm saying. :)
klt0825 9y ago
By reading from the actual memory address, yes. Defeating kASLR with side channels is meh. Reading from actual addresses is a different matter entirely.
- deleted 9y ago
  [deleted]