An analogy that was useful for explaining part of this to my (non-technical) father. Maybe others will find it helpful as well.
Imagine that you want to know whether someone has checked out a particular library book. The library refuses to give you access to their records and does not keep a slip inside the front cover. You can only see the record of which books you have checked out.
What you do is follow the person of interest into the library whenever they return a book. You then ask the librarian for a copy of the books you want to know whether the person has checked out. If the librarian looks down and says "You are in luck, I have a copy right here!" then you know the person had checked out that book. If the librarian has to go look in the stacks and comes back 5 minutes later with the book, you know that the person didn't check out that book (this time).
The way to make the library secure against this kind of attack is to require that all books be reshelved before they can be lent out again, unless the current borrower is requesting an extension.
There are many other ways to use the behavior of the librarian and the time it takes to retrieve a book to figure out which books a person is reading.
edit: A closer variant. Call the library pretending to be the person and ask for a book to be put on hold. Then watch how long it takes them in the library. If they got that book they will be in and out in a minute (and perhaps a bit confused), if they didn't take that book it will take 5 minutes.
Your analogy is more apt for side-channel attacks in general. Here is a more specific version for Meltdown:
A library has two rooms, one for general books and one for restricted books. The restricted books are not allowed out of the library, and no notes or recordings are allowed to be taken out of the restricted room.
An attacker wants to sneak information out of the restricted room. To do this the pick up a pile of non-restricted books and go into the restricted room. Depending on what they read in there they rearrange the pile of non-restricted books into a particular order. A guard comes along and sees them, they are thrown out of the restricted room and their pile of non-restricted books is put on the issue desk ready to be put back into circulation.
Their conspirator looks at the order of the books on the issue desk and decodes a piece of information about the book in the restricted room. They repeat this process about 500000 times a second until they have transcribed the secret book.
I don't understand how this info can be used for getting what was inside the book? If my understanding of your explanation is correct, book name is analogous to memory address. When the victim (legit process) returned the book with name X (called free on the mem block X), the librarian (OS) erased all pages of the book and repurposed it for printing another book before handing it out to the evil dude(snoopy process).
Fantastic explanation of cache timing attacks. This morning I was explaining spectre to non-technical people and let me tell you, "leaking L1 CPU cache memory," is a real party starter. So I'm using there librarian example going forward.
>As a proof-of-concept, JavaScript code was written
that, when run in the Google Chrome browser, allows
JavaScript to read private memory from the process
in which it runs (cf. Listing 2).
"Spectre" is very bad news and affects all modern CPUs. Mitigation is to insert mfence instructions throughout jit generated sandboxed code making it very slow, ugh. Otherwise assume that the entire process with jit generated code is open to reading by that code.
Any system which keeps data from multiple customers (or whatever) in the same process is going to be highly vulnerable.
This is so incredibly bad. Spectre is basically unpatchable. We can do better than we are now with patches but it's all just turd polishing, essentially. A proper fix will require new CPU hardware. And as a kicker? Leaks are basically undetectable.
"As a proof-of-concept, JavaScript code was written that, when run in the Google Chrome browser, allows JavaScript to read private memory from the process in which it runs"
I am not sure what "the process in which it runs" means here ... do they mean private memory from within chrome ? Or within the child process spawned from chrome, or within the spawned JS sandbox or ... what ?
Practically speaking, I worry about a browser pageview that can read memory from my terminal process. Or from my 'screen' or 'sshd' process.
Will it be nontrivial to detect or at least identify these types of exploits as they occur in the wild? Can protection software see these when they happen, assuming a best case scenario where the attack is carried out but doesn't specifically use these methods to hide or disable detection? Is there a general sense yet of whether this exploit is already being leveraged?
Thanks for the links. As an undergrad with limited knowledge of this subject, I would love to see these annotated on Fermat's Library (https://fermatslibrary.com)
Guys, can't we just detect a program doing spectre-like behavior and just kill it instead of having every other application suffer a performance hit by the proposed changes? Antivirus software already does similar stuff
"AMD chips are affected by some but not all of the vulnerabilities. AMD said that there is a "near zero risk to AMD processors at this time." British chipmaker ARM told news site Axios prior to this report that some of its processors, including its Cortex-A chips, are affected."
"Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.
Which systems are affected by Spectre?
Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors."
Hard to find a good spot for this, but: Thanks to anyone involved! From grasping the magnitude of this vulnerability to coordinating it with all major OS vendors, including Open Source ones that do all of their stuff more or less „in the open“, it was almost a miracle that the flaw was leaked „only“ a few days before the embargo - and we‘ll all have patches to protect our infrastructure just in time.
Interestingly, it also put the LKML developers into an ethical grey zone, as they had to deceive the public the patch was actually fixing something else (they did a good and right thing there IMHO).
Despite all the slight problems along the way, kudos to any of the White Hats dealing with this mess over the last months and handling it super graceful!
>Current stable versions of Chrome include an optional feature called Site Isolation which can be enabled to provide mitigation by isolating websites into separate address spaces. Learn more about Site Isolation and how to take action to enable it.
>Chrome 64, due to be released on January 23, will contain mitigations to protect against exploitation.
>Additional mitigations are planned for future versions of Chrome. Learn more about Chrome's response.
>Desktop (all platforms), Chrome 63:
> Full Site Isolation can be turned on by enabling a flag found at chrome://flags/#enable-site-per-process.
> Enterprise policies are available to turn on Site Isolation for all sites, or just those in a specified list. Learn more about Site Isolation by policy.
Does that mean if I don't enable this feature using chrome://flags and tell my grandma to do this complicated procedure I (or she) will be susceptible to getting our passwords stolen?
Subject: Avoid speculative indirect calls in kernel
Any speculative indirect calls in the kernel can be tricked
to execute any kernel code, which may allow side channel
attacks that can leak arbitrary kernel data.
So we want to avoid speculative indirect calls in the kernel.
There's a special code sequence called a retpoline that can
do indirect calls without speculation. We use a new compiler
option -mindirect-branch=thunk-extern (gcc patch will be released
separately) to recompile the kernel with this new sequence.
We also patch all the assembler code in the kernel to use
the new sequence.
"Before the issues described here were publicly disclosed, Daniel Gruss, Moritz Lipp, Yuval Yarom, Paul Kocher, Daniel Genkin, Michael Schwarz, Mike Hamburg, Stefan Mangard, Thomas Prescher and Werner Haas also reported them; their [writeups/blogposts/paper drafts] are at"
Does anyone have any color/details on how this came to be? A major fundamental flaw exists that affects all chips for ~10 years, and multiple independent groups discovered them roughly around the same time this past summer?
My hunch is that someone published some sort of speculative paper / gave a talk ("this flaw could exist in theory") and then everyone was off to the races.
But would be curious if anyone knows the real version?
This part is interesting considering the performance concerns:
"The majority of Azure customers should not see a noticeable performance impact with this update. We’ve worked to optimize the CPU and disk I/O path and are not seeing noticeable performance impact after the fix has been applied. A small set of customers may experience some networking performance impact. This can be addressed by turning on Azure Accelerated Networking (Windows, Linux), which is a free capability available to all Azure customers."
Someone correct me if I understood this wrong. The way they are exploiting speculative execution is to load values from memory regions which they don't have permission to a cache line, and when the speculation is found to be false, the processor does not undo the write to the cache line?
The question is, how is the speculative write going to the cache in the first place? Only retired instructions should be able to modify cache lines AFAIK. What am I missing?
Edit: Figured it out. The speculatively accessed memory value is used to compute the address of a load from a memory location which the attacker has access to. Once the mis-speculation is detected, the attacker will time accesses to the memory which was speculatively loaded and figure out what the secret key is. Brilliant!
Important to note that at this point they're only reading one bit at a time from kernel memory, but it could probably be changed to read more--exactly how many branches it could compare before the mis-speculation is detected is not discussed, and that could be an area for large speedups in the attack.
Has Google the best security team in the world? It seems like Google security is in a complete different league. I cannot imagine how this impacts companies handling fiat money or cryptocurrencies in the cloud like Coinbase in AWS.
Project Zero is very well known for things exactly like this. Partially, it's because they are incredibly talented, but there are also talented people in academia and in other security consultancies. The biggest difference with Project Zero is that their primary [0] goal is altruistic: find vulnerabilities, and let people who can fix them know (vs publishing papers, securing paying clients, auctioning zero-days, etc), in the interests of making the internet and computing as a whole a safer place.
[0] Their secondary goals are to protect Google products and services, and to provide excellent PR in line with what we're discussing right here.
I don't know how you would evaluate such a thing as "best security team," but Project Zero certainly attracts a high calibre of security expert. If you're into breaking things, why wouldn't you want to break things with other bright people and the support of a massive corporation?
I can't imagine better marketing for cloud services than making it as clear as you can that the world is a very dangerous place for computers and if you don't have a crack team of hundreds of battle-hardened security engineers then you have no business hooking your computers up to the internet.
I wonder how much of it relates to their mastery in data science.
I keep wondering if they got some “””AI””” fuzzer that helps them a ton? Plus tons of compute power to spend (remember SHA-256 clash they found “just because”?)
So, as I gather, one of the main culprits is that unwinding of speculatively executed commands is done incompletely. That is something that the people doing the unwinding must have noticed and known. Somewhere the decision must have been made to unwind incompletely for some reasons (performance/power/cost/time).
As for the difference between AMD and intel. (From other posts here, not this one.) The speculative execution can access arbitrary memory locations on intel processors while this is not possible on AMD. This means that on intel processors you can probe any memory location with only limited privileges.
As for the affected AMD and ARM processors I'm none the wiser. How are they affected? Which models are affected? Does it allow some kind of privilege escalation? The next days will surely stay interesting.
You can't unwind completely. Once the cache is full, to load something on the cache, it has to evict something else. You might be able to evict what you just loaded, but you can't undo the earlier eviction.
Both domains were registered on 2017-12-22. Given the planned disclosure on 9th January that Google mentions and MS and others coding patches silently [1], do the early reports [2] of kernel patches, does this mean that due to coding in the open the whole disclosure procedure has been vastly accelerated?
I wonder how the timing relates to New Year and many companies having holidays in CW1.
It seems that Richard Stallman is not so paranoid after all:
> I am careful in how I use the Internet.
> I generally do not connect to web sites from my own machine, aside from a few sites I have some special relationship with. I usually fetch web pages from other sites by sending mail to a program (see https://git.savannah.gnu.org/git/womb/hacks.git) that fetches them, much like wget, and then mails them back to me. Then I look at them using a web browser, unless it is easy to see the text in the HTML page directly. I usually try lynx first, then a graphical browser if the page needs it (using konqueror, which won't fetch from other sites in such a situation).
Speculative execution seems like something that would be very intuitively insecure even to a layperson(relative to the field of course).
I'm wondering, was this vulnerability theorized first and later found out to be an actual vulnerability? Or was this something that nobody had any clue about?
I'm only saying this, because from a security perspective, I imagine somewhere at some point very early on someone had to have pointed out the potential for something like speculative execution to eventually cause security problems.
I just don't understand how chip designers assumed speculative execution wouldn't eventually cause security problems. Is it because chip designers were prioritizing performance above security?
I don't think this is the last we have seen of side-channels, it's just a ridicolously hard problem to get right. And for that reason I can't feel too angry at the procesor makers.
And I certainly expect to see more things like this (but at least hopefully with lower bandwidth).
Wow so intel comes and says what is all the panic about there is nothing wrong (despite knowing this) and then amazon drops the we are updating everything right now bomb and then google drops the mother of all cpu bugs. In a previous thread someone was asking if it really is all that bad and at this point I think it’s safe to say that yea, it is.
[+] [-] hyperion2010|8 years ago|reply
Imagine that you want to know whether someone has checked out a particular library book. The library refuses to give you access to their records and does not keep a slip inside the front cover. You can only see the record of which books you have checked out.
What you do is follow the person of interest into the library whenever they return a book. You then ask the librarian for a copy of the books you want to know whether the person has checked out. If the librarian looks down and says "You are in luck, I have a copy right here!" then you know the person had checked out that book. If the librarian has to go look in the stacks and comes back 5 minutes later with the book, you know that the person didn't check out that book (this time).
The way to make the library secure against this kind of attack is to require that all books be reshelved before they can be lent out again, unless the current borrower is requesting an extension.
There are many other ways to use the behavior of the librarian and the time it takes to retrieve a book to figure out which books a person is reading.
edit: A closer variant. Call the library pretending to be the person and ask for a book to be put on hold. Then watch how long it takes them in the library. If they got that book they will be in and out in a minute (and perhaps a bit confused), if they didn't take that book it will take 5 minutes.
[+] [-] 314|8 years ago|reply
A library has two rooms, one for general books and one for restricted books. The restricted books are not allowed out of the library, and no notes or recordings are allowed to be taken out of the restricted room.
An attacker wants to sneak information out of the restricted room. To do this the pick up a pile of non-restricted books and go into the restricted room. Depending on what they read in there they rearrange the pile of non-restricted books into a particular order. A guard comes along and sees them, they are thrown out of the restricted room and their pile of non-restricted books is put on the issue desk ready to be put back into circulation.
Their conspirator looks at the order of the books on the issue desk and decodes a piece of information about the book in the restricted room. They repeat this process about 500000 times a second until they have transcribed the secret book.
[+] [-] prab97|8 years ago|reply
[+] [-] pgt|8 years ago|reply
[+] [-] technics256|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] jotux|8 years ago|reply
https://meltdownattack.com/meltdown.pdf
https://spectreattack.com/spectre.pdf
From the spectre paper:
>As a proof-of-concept, JavaScript code was written that, when run in the Google Chrome browser, allows JavaScript to read private memory from the process in which it runs (cf. Listing 2).
Scary stuff.
[+] [-] jhallenworld|8 years ago|reply
"Spectre" is very bad news and affects all modern CPUs. Mitigation is to insert mfence instructions throughout jit generated sandboxed code making it very slow, ugh. Otherwise assume that the entire process with jit generated code is open to reading by that code.
Any system which keeps data from multiple customers (or whatever) in the same process is going to be highly vulnerable.
[+] [-] ErikAugust|8 years ago|reply
[+] [-] theptip|8 years ago|reply
Looks like any session token/state could be exfiltrated from your Gmail tab to a malicious JS app running in-process, for example.
Am I overreacting here?
[+] [-] InclinedPlane|8 years ago|reply
[+] [-] minxomat|8 years ago|reply
Edit: Also, PoCs for unpatched Windows by pwnallthethings: https://github.com/turbo/KPTI-PoC-Collection
[+] [-] rsync|8 years ago|reply
I am not sure what "the process in which it runs" means here ... do they mean private memory from within chrome ? Or within the child process spawned from chrome, or within the spawned JS sandbox or ... what ?
Practically speaking, I worry about a browser pageview that can read memory from my terminal process. Or from my 'screen' or 'sshd' process.
I think that is not a risk here, yes ?
[+] [-] marzell|8 years ago|reply
[+] [-] pogba101|8 years ago|reply
[+] [-] guftagu|8 years ago|reply
[+] [-] boltzmann_brain|8 years ago|reply
[deleted]
[+] [-] mrmondo|8 years ago|reply
- http://www.zdnet.com/article/security-flaws-affect-every-int...
* Edit:
From https://meltdownattack.com/
Which systems are affected by Meltdown?
"Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.
Which systems are affected by Spectre?
Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors."
[+] [-] endymi0n|8 years ago|reply
Interestingly, it also put the LKML developers into an ethical grey zone, as they had to deceive the public the patch was actually fixing something else (they did a good and right thing there IMHO).
Despite all the slight problems along the way, kudos to any of the White Hats dealing with this mess over the last months and handling it super graceful!
[+] [-] tonmoy|8 years ago|reply
> Google Chrome
> Some user or customer action needed. More information here (https://support.google.com/faqs/answer/7622138#chrome).
And the "here" link says:
>Google Chrome Browser
>Current stable versions of Chrome include an optional feature called Site Isolation which can be enabled to provide mitigation by isolating websites into separate address spaces. Learn more about Site Isolation and how to take action to enable it.
>Chrome 64, due to be released on January 23, will contain mitigations to protect against exploitation.
>Additional mitigations are planned for future versions of Chrome. Learn more about Chrome's response.
>Desktop (all platforms), Chrome 63:
> Full Site Isolation can be turned on by enabling a flag found at chrome://flags/#enable-site-per-process. > Enterprise policies are available to turn on Site Isolation for all sites, or just those in a specified list. Learn more about Site Isolation by policy.
Does that mean if I don't enable this feature using chrome://flags and tell my grandma to do this complicated procedure I (or she) will be susceptible to getting our passwords stolen?
[+] [-] tytso|8 years ago|reply
Subject: Avoid speculative indirect calls in kernel
Any speculative indirect calls in the kernel can be tricked to execute any kernel code, which may allow side channel attacks that can leak arbitrary kernel data.
So we want to avoid speculative indirect calls in the kernel.
There's a special code sequence called a retpoline that can do indirect calls without speculation. We use a new compiler option -mindirect-branch=thunk-extern (gcc patch will be released separately) to recompile the kernel with this new sequence.
We also patch all the assembler code in the kernel to use the new sequence.
[+] [-] nlh|8 years ago|reply
Does anyone have any color/details on how this came to be? A major fundamental flaw exists that affects all chips for ~10 years, and multiple independent groups discovered them roughly around the same time this past summer?
My hunch is that someone published some sort of speculative paper / gave a talk ("this flaw could exist in theory") and then everyone was off to the races.
But would be curious if anyone knows the real version?
[+] [-] rarudduck|8 years ago|reply
This part is interesting considering the performance concerns:
"The majority of Azure customers should not see a noticeable performance impact with this update. We’ve worked to optimize the CPU and disk I/O path and are not seeing noticeable performance impact after the fix has been applied. A small set of customers may experience some networking performance impact. This can be addressed by turning on Azure Accelerated Networking (Windows, Linux), which is a free capability available to all Azure customers."
[+] [-] webaholic|8 years ago|reply
The question is, how is the speculative write going to the cache in the first place? Only retired instructions should be able to modify cache lines AFAIK. What am I missing?
Edit: Figured it out. The speculatively accessed memory value is used to compute the address of a load from a memory location which the attacker has access to. Once the mis-speculation is detected, the attacker will time accesses to the memory which was speculatively loaded and figure out what the secret key is. Brilliant!
[+] [-] violinist|8 years ago|reply
[+] [-] adriancooney|8 years ago|reply
[+] [-] chrisb|8 years ago|reply
Curious. All other reports I've read state that AMD CPUs are not vulnerable.
[+] [-] MBCook|8 years ago|reply
(Edit: there are 9 posts total, go to her user page to see them all)
Seems there are two issues. One, called Meltdown, only effects Intel and is REALLY bad, but the kernel page table changes everyone is making fixes it.
The other, dubbed Spectre, is apparently common to the way all processors handle speculative execution and is unfixable without new hardware.
I’d like to know more about that but I haven’t seen anything yet.
Whoever discovered this stuff on Google’s team deserves some sort of computer security Nobel prize.
[+] [-] azurezyq|8 years ago|reply
https://googleprojectzero.blogspot.com/2018/01/reading-privi...
[+] [-] noncoml|8 years ago|reply
But the sentence you quote adds AMD back into play. Maybe some of its ARM processors? e.g. AMD Opteron A1100?
[+] [-] wslh|8 years ago|reply
[+] [-] gervase|8 years ago|reply
[0] Their secondary goals are to protect Google products and services, and to provide excellent PR in line with what we're discussing right here.
[+] [-] enneff|8 years ago|reply
[+] [-] ebikelaw|8 years ago|reply
[+] [-] oh-kumudo|8 years ago|reply
Spectre occurs no matter you are in cloud or not, while cloud companies can advertise themselves to help customers proactively to mitigate such risks.
[+] [-] rurban|8 years ago|reply
[+] [-] dzhiurgis|8 years ago|reply
I keep wondering if they got some “””AI””” fuzzer that helps them a ton? Plus tons of compute power to spend (remember SHA-256 clash they found “just because”?)
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] static_noise|8 years ago|reply
As for the difference between AMD and intel. (From other posts here, not this one.) The speculative execution can access arbitrary memory locations on intel processors while this is not possible on AMD. This means that on intel processors you can probe any memory location with only limited privileges.
As for the affected AMD and ARM processors I'm none the wiser. How are they affected? Which models are affected? Does it allow some kind of privilege escalation? The next days will surely stay interesting.
[+] [-] cesarb|8 years ago|reply
[+] [-] richadams|8 years ago|reply
Information site with some more information, and links to papers on the two vulnerabilities, called "Meltdown" and "Spectre" (with logos, of course).
(https://meltdownattack.com/ goes to the same site)
[+] [-] hrpnk|8 years ago|reply
I wonder how the timing relates to New Year and many companies having holidays in CW1.
[1] https://lists.freebsd.org/pipermail/freebsd-security/2018-Ja...
[2] https://news.ycombinator.com/item?id=16046636
[+] [-] partiallypro|8 years ago|reply
[+] [-] tarruda|8 years ago|reply
> I am careful in how I use the Internet.
> I generally do not connect to web sites from my own machine, aside from a few sites I have some special relationship with. I usually fetch web pages from other sites by sending mail to a program (see https://git.savannah.gnu.org/git/womb/hacks.git) that fetches them, much like wget, and then mails them back to me. Then I look at them using a web browser, unless it is easy to see the text in the HTML page directly. I usually try lynx first, then a graphical browser if the page needs it (using konqueror, which won't fetch from other sites in such a situation).
Ref: https://stallman.org/stallman-computing.html
[+] [-] debt|8 years ago|reply
I'm wondering, was this vulnerability theorized first and later found out to be an actual vulnerability? Or was this something that nobody had any clue about?
I'm only saying this, because from a security perspective, I imagine somewhere at some point very early on someone had to have pointed out the potential for something like speculative execution to eventually cause security problems.
I just don't understand how chip designers assumed speculative execution wouldn't eventually cause security problems. Is it because chip designers were prioritizing performance above security?
[+] [-] im3w1l|8 years ago|reply
And I certainly expect to see more things like this (but at least hopefully with lower bandwidth).
[+] [-] anonfunction|8 years ago|reply
https://www.amd.com/en/corporate/speculative-execution
[+] [-] aeleos|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]