It's true nobody knows what the actual bug is, but I was working with what Ars Technica described: "If the problem were just that it enabled the derandomization of ASLR, this probably wouldn't be a huge disaster... The industry reaction... suggests that it's not just ASLR that's defeated and that a more general ability to leak information from the kernel has been developed." https://arstechnica.com/gadgets/2018/01/whats-behind-the-int...

I guess I've stopped reading security articles by Peter Bright ever since he spent a whole series of articles shitting on project zero for disclosing vulnerabilities after the 90 day disclosure window when Microsoft had just been sitting on the bug.

https://arstechnica.com/information-technology/2015/01/googl...

Bigger than KASLR it seems.

https://twitter.com/brainsmoke/status/948561799875502080

Not good.

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

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.

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.

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.

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. :)

By reading from the actual memory address, yes. Defeating kASLR with side channels is meh. Reading from actual addresses is a different matter entirely.

It looks like he's reading actual data from kernel space.

The best guess I've seen so far is this one: https://plus.google.com/+KristianK%C3%B6hntopp/posts/Ep26AoA...

Actual information about the bug itself is still embargoed. Most people are assuming it's the attack you suggest based on recent commits, but it's a guess.