cyber.wtf

This happens all the time. In this particular case, speculative execution timing attacks were "in the air" for the last year. A little while ago the C.W. was that Anders Fogh had kicked this off with his blog post from last summer, but Fogh actually posted a chronology taking this work all the way back to December '16: https://cyber.wtf/2018/01/05/behind-the-scene-of-a-bug-collision/ Once there's blood in the water, people race to find exploitable flaws (that's the goal of the game), and so it's not surprising that you'd get multiple teams disclosing, especially with something this egregious. Also: there's a Nyquist Frequency thing happening here: remember that we're dealing with months-long embargoes. So there's a lot of time for people to have found these bugs "separately", and all we're really seeing is a colliding disclosure. But having said all that: straight-up collisions happen a lot. We all have favorite stories. My favorite is when Vitaly McLain (then at Matasano, now one of my partners at Latacora) found an nginx bug that was identical to Heartbleed, 2 years before Heartbleed was disclosed. A fantastic bug. We were on a client engagement, so we had to coordinate with the client before reporting it upstream, and in the one hour it took to do that, someone else reported the same bug.

> Everything else was not seen as practically exploitable. For a concrete blog post, see https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-fro… Note that according to https://en.wikipedia.org/w/index.php?title=Spectre_(security_vulnerabi… Spectre was published January 2018, i.e. this blog post is indeed older. As I wrote: It was unclear how this potential threat could be used to create real attacks.

This is the blog article: https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-fro…

Yeah, the blog post says they knew since June 2017, with that blog post being from July. > This initial report did not contain any information about variant 3. We had discussed whether direct reads from kernel memory could work, but thought that it was unlikely. We later tested and reported variant 3 prior to the publication of Anders Fogh's work at https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-fro…

I thought that: mov rax, [Somekerneladdress] would trigger an interrupt even on speculative execution as described on https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-fro… ADDED: So in the interrupt handler the kernel could evict all user space pages from cache before returning control to user space so it could not use the timing attack on the cache of the speculative execution of Mov rbx,[rax+Someusermodeaddress] on the address rax+Someusermodeaddress.

https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-fro… Failed attempt in July which is being attributed as earliest work via https://twitter.com/lavados/status/948700783259811847

I think they are just using the CR3 register to implement the fix. The actual side channel will be something a bit more esoteric. Something like this: https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-fro…

old news. https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-fro…

Yes as far as we know it allows user-space code to read kernel memory, but not modify it. It affects Intel but not AMD according to them (not sure why Intel says otherwise). Details in this blog post from several months ago: https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-fro… They didn't get it to work but obviously someone else has.

Was the connection with speculative execution already being discussed openly? I know about https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-fro… but not about anything between that and 28 Dec suggesting someone made it work and that's the reason for KPTI. If it wasn't in the open, seems...not ideal embargo-wise for AMD to leak it there. Though no one's in that thread complaining about the disclosure, so maybe they either think that part is already known to anyone looking closely, or just don't think it's a very big piece of the exploit puzzle (like, finding the way to get info out a side channel was the hard part).

They might have succeeded to make it work: https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-fro…

The growing consensus is that someone managed to make this work: https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-fro… Reading kernel memory from user mode = reading cached disk blocks, cached credentials and anything else, by simply running javascript on a web browser. KASLR bypass is just a small bonus.

The author of https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-fro… is listed in the Acknowledgements part as the first name in the Kaiser whitepaper.

https://www.reddit.com/r/programming/comments/5g5brq/armageddon_how_yo… https://cyber.wtf/2016/06/16/cache-side-channel-attacks-cpu-design-as-… https://eprint.iacr.org/2016/980.pdf https://github.com/IAIK/armageddon/tree/master/libflush

I'm trying to understand the timeline of everything that is going on. https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-fro… was published on 2017-07-28. The pythonsweetness.tumblr.com post talks about patches being first posted in October (anyone have a link to the first public patch?). https://lwn.net/Articles/738975/ was published on 2017-11-15. https://lwn.net/SubscriberLink/741878/5c019c71457e0da6/ was published on 2017-12-20. https://lkml.org/lkml/2017/12/27/2 was published on 2017-12-27. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/com… shows that Linus merged the patches on 2017-12-30. https://lwn.net/Articles/742404/ was published on 2017-12-30. http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-cas… which was the post that grabbed everyone's attention, was published on 2018-01-01. Was the blog post on 2017-07-28 talking about the same vulnerability that has the world on fire today, or are there multiple issues going on?