Chip architecture vulnerability in pretty much everthing

Questions on how we spend our money and our time - consumer goods and services, home and vehicle, leisure and recreational activities
User avatar
tadamsmar
Posts: 7611
Joined: Mon May 07, 2007 12:33 pm

Chip architecture vulnerability in pretty much everthing

Post by tadamsmar » Thu Jan 04, 2018 1:55 am

I find it hard to get my head around this story. Pretty much everything is vulnerable. It is uncertain if there have been any exploits by hackers.

Reports seem to indicate that Microsoft issued a patch today, but reports say that other driver patches may be needed. And maybe it is not fully patchable!?

https://techcrunch.com/2018/01/03/kerne ... nd-device/

jalbert
Posts: 2745
Joined: Fri Apr 10, 2015 12:29 am

Re: Chip architecture vulnerability in pretty much everthing

Post by jalbert » Thu Jan 04, 2018 2:05 am

Direct source:

https://meltdownattack.com

The meltdown vulnerability seems to be a hardware flaw allowing direct access to operating system protected memory from outside the operating system, and seems to be fixable by software workarounds to prevent exploit of the flaw. The spectre vulnerability achieves a similar result by more esoteric means and is much more difficult to address.
Risk is not a guarantor of return.

User avatar
tadamsmar
Posts: 7611
Joined: Mon May 07, 2007 12:33 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by tadamsmar » Thu Jan 04, 2018 2:08 am

Reports of a post-fix 30% reduction in computer performance. But Intel seems to be saying that is only for certain applications.

jalbert
Posts: 2745
Joined: Fri Apr 10, 2015 12:29 am

Re: Chip architecture vulnerability in pretty much everthing

Post by jalbert » Thu Jan 04, 2018 2:22 am

Seems to not just be OS protected memory but protected memory in other user processes as well— enables a process running in one virtual address space to read memory items of a different process running in a different virtual address space.

As an example, you type in the master password for a password safe, and software running in a completely different process can read the password safe memory, compromising the password safe.
Risk is not a guarantor of return.

User avatar
alpine_boglehead
Posts: 160
Joined: Fri Feb 17, 2017 9:51 am
Location: Austria

Re: Chip architecture vulnerability in pretty much everthing

Post by alpine_boglehead » Thu Jan 04, 2018 2:22 am

tadamsmar wrote:
Thu Jan 04, 2018 2:08 am
Reports of a post-fix 30% reduction in computer performance. But Intel seems to be saying that is only for certain applications.
Yes, the magnitude of the slowdown seems to depend on the kind of application. According to this source the patch (in Linux) essentially slows down all system calls, so an application which just crunches numbers would be little impacted compared to ones which has heavy interaction with the operating system:

"In a benchmark, a program that does virtually nothing other than call into the kernel saw its performance drop by about 50 percent; in other words, each call into the kernel took twice as long with the patch than it did without. Benchmarks that use Linux's loopback networking also see a big hit, such as 17 percent in this Postgres benchmark."

Gray
Posts: 598
Joined: Sat Apr 16, 2011 5:33 am

Re: Chip architecture vulnerability in pretty much everthing

Post by Gray » Thu Jan 04, 2018 2:27 am

The solution (since this type of thing is an ongoing reality) is defense in depth (layered defensive practices). Firewalls, antivirus, intrusion detection/prevention, common sense, active patching, minimal rights for normal computing use, encrypting data, two factor authentication, and buying from trusted vendors that provide robust after-sale support, etc.

You could also use a ARM-based chromebook with an Amazon hosted workspace as your PC. I’ve been thinking about doing that before this arose so I can access my same PC from every computer, phone, or tablet.

https://docs.aws.amazon.com/workspaces/ ... lient.html

lazydavid
Posts: 1489
Joined: Wed Apr 06, 2016 1:37 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by lazydavid » Thu Jan 04, 2018 5:57 am

Gray wrote:
Thu Jan 04, 2018 2:27 am
The solution (since this type of thing is an ongoing reality) is defense in depth (layered defensive practices). Firewalls, antivirus, intrusion detection/prevention, common sense, active patching, minimal rights for normal computing use, encrypting data, two factor authentication, and buying from trusted vendors that provide robust after-sale support, etc.

You could also use a ARM-based chromebook with an Amazon hosted workspace as your PC. I’ve been thinking about doing that before this arose so I can access my same PC from every computer, phone, or tablet.
All good advice, except possibly for the last section. ARM processors share these vulnerabilities, so chromebooks, phones, and tablets are still potential attack vectors. Same with the hardware underlying AWS. So go that route if it makes sense for your workflow, but don't do so thinking you're avoiding these vulnerabilities.

Gray
Posts: 598
Joined: Sat Apr 16, 2011 5:33 am

Re: Chip architecture vulnerability in pretty much everthing

Post by Gray » Thu Jan 04, 2018 10:19 am

That’s why I suggested a chromebook with a limited attack surface (vs a full PC OS) using a PC VM hosted in the cloud without the chip-based vulnerability.

https://www.google.com/amp/s/www.cnbc.c ... ility.html

lazydavid
Posts: 1489
Joined: Wed Apr 06, 2016 1:37 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by lazydavid » Thu Jan 04, 2018 11:37 am

Gray wrote:
Thu Jan 04, 2018 10:19 am
That’s why I suggested a chromebook with a limited attack surface (vs a full PC OS) using a PC VM hosted in the cloud without the chip-based vulnerability.

https://www.google.com/amp/s/www.cnbc.c ... ility.html
You still need to patch both the Chromebook (should be automatic) and the cloud VM. From that article:
Google said it has updated its public cloud service to prevent attacks related to Meltdown and Spectre. "We used our VM Live Migration technology to perform the updates with no user impact, no forced maintenance windows and no required restarts," Google engineering vice president Ben Treynor Sloss wrote in a blog post. But customers will still need to update the operating systems they use on the Google cloud.

btenny
Posts: 4395
Joined: Sun Oct 07, 2007 6:47 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by btenny » Thu Jan 04, 2018 11:48 am

Maybe we need to back track to human speed and human interaction for some processes!!!!! And maybe we need to install big air gaps between other processes. Just thinking.

azurekep
Posts: 1179
Joined: Tue Jun 16, 2015 7:16 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by azurekep » Thu Jan 04, 2018 12:13 pm

From what I've read, it's limited to 64-bit processors.

It continues to be an advantage to hang onto old computers. :)

User avatar
jabberwockOG
Posts: 1204
Joined: Thu May 28, 2015 7:23 am

Re: Chip architecture vulnerability in pretty much everthing

Post by jabberwockOG » Thu Jan 04, 2018 12:43 pm

On the surface it would seem that defeating the predictive branching in the processor would completely cure one of the holes. Hard to imagine that decreases 30-50% of application processing speed - I'd believe 10%. Likely engineering problem/solution is more complicated than it seems once you get into it.

jebmke
Posts: 7628
Joined: Thu Apr 05, 2007 2:44 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by jebmke » Thu Jan 04, 2018 12:44 pm

jabberwockOG wrote:
Thu Jan 04, 2018 12:43 pm
On the surface it would seem that defeating the predictive branching in the processor would completely cure one of the holes. Hard to imagine that decreases 30-50% of application processing speed - I'd believe 10%. Likely engineering problem/solution is more complicated than it seems once you get into it.
I recall seeing a piece that said typical decrease ~3-5% but 30% under specific circumstances.
When you discover that you are riding a dead horse, the best strategy is to dismount.

squirm
Posts: 1256
Joined: Sat Mar 19, 2011 11:53 am

Re: Chip architecture vulnerability in pretty much everthing

Post by squirm » Thu Jan 04, 2018 2:04 pm

Gray wrote:
Thu Jan 04, 2018 10:19 am
That’s why I suggested a chromebook with a limited attack surface (vs a full PC OS) using a PC VM hosted in the cloud without the chip-based vulnerability.

https://www.google.com/amp/s/www.cnbc.c ... ility.html
Huh? This hits Intel x86, not AMD, and only the Cortex 73.
Intel is aggressive with their out of order speculation. That's the main issue. Mixing kernel access with user access isn't good... hope any patches checks CPU manufacture.
Security checks on Android doesn't even use the Android os.
Why would chromium/chrome be immune? Makes no sense.

User avatar
tadamsmar
Posts: 7611
Joined: Mon May 07, 2007 12:33 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by tadamsmar » Thu Jan 04, 2018 2:43 pm

squirm wrote:
Thu Jan 04, 2018 2:04 pm
Gray wrote:
Thu Jan 04, 2018 10:19 am
That’s why I suggested a chromebook with a limited attack surface (vs a full PC OS) using a PC VM hosted in the cloud without the chip-based vulnerability.

https://www.google.com/amp/s/www.cnbc.c ... ility.html
Huh? This hits Intel x86, not AMD, and only the Cortex 73.
Intel is aggressive with their out of order speculation. That's the main issue. Mixing kernel access with user access isn't good... hope any patches checks CPU manufacture.
Security checks on Android doesn't even use the Android os.
Why would chromium/chrome be immune? Makes no sense.
Google seems to be reporting that they found the vulnerability last year and addressed it in their own systems. But this explainer is so technical that I am not sure exactly what they are claiming:

https://blog.google/topics/google-cloud ... erability/

User avatar
tadamsmar
Posts: 7611
Joined: Mon May 07, 2007 12:33 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by tadamsmar » Thu Jan 04, 2018 2:56 pm

People need to check that their anti-virus software is compatible with the Windows upgrades related to the vulnerability. Here's a spreadsheet that provides some info:

https://docs.google.com/spreadsheets/d/ ... true#gid=0

Not sure what the symptoms of incompatibility are. Some sites indicate a failure to apply the upgrade, others seem to indicate the blue screen of death.

squirm
Posts: 1256
Joined: Sat Mar 19, 2011 11:53 am

Re: Chip architecture vulnerability in pretty much everthing

Post by squirm » Thu Jan 04, 2018 3:53 pm

The operating system update is one thing, but it's still an incomplete security update. Intel needs to release updated microcode update. The bigger issue is accessing kernel memory with speculation. Undoing this optimization will hit performance.

a5ehren
Posts: 52
Joined: Fri May 26, 2017 7:48 am

Re: Chip architecture vulnerability in pretty much everthing

Post by a5ehren » Thu Jan 04, 2018 4:41 pm

azurekep wrote:
Thu Jan 04, 2018 12:13 pm
From what I've read, it's limited to 64-bit processors.

It continues to be an advantage to hang onto old computers. :)
This is true on ARM, but not x86. ARM was not vulnerable until the Cortex-A57 because their older chips did not have that sophisticated of a branch predictor.

The Intel-specific vulnerability affects pretty much anything since the Pentium Pro, and only newer processors (4xxx series and up) have new features to mitigate the performance impacts of the fix.

There is a related (but harder to exploit) issue that applies to basically every modern processor.


azurekep
Posts: 1179
Joined: Tue Jun 16, 2015 7:16 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by azurekep » Thu Jan 04, 2018 9:05 pm

a5ehren wrote:
Thu Jan 04, 2018 4:41 pm
azurekep wrote:
Thu Jan 04, 2018 12:13 pm
From what I've read, it's limited to 64-bit processors.

It continues to be an advantage to hang onto old computers. :)
This is true on ARM, but not x86.
Dang. :annoyed

I have a couple of questions regarding some of the current reporting.

1. Does anyone know whether web browsers qualify as the type of program that would suffer signficantly by the patch's performance hit?

2. What other types of programs/applications might suffer significantly?

3. How much protection does disabling javascript provide? Many of the news reports say javascript would be one of the ways for an attacker to read the passwords, etc. in memory, but don't indicate how many other vectors of attack there may be.

Mudpuppy
Posts: 5865
Joined: Sat Aug 27, 2011 2:26 am
Location: Sunny California

Re: Chip architecture vulnerability in pretty much everthing

Post by Mudpuppy » Fri Jan 05, 2018 3:29 am

Gray wrote:
Thu Jan 04, 2018 10:19 am
That’s why I suggested a chromebook with a limited attack surface (vs a full PC OS) using a PC VM hosted in the cloud without the chip-based vulnerability.

https://www.google.com/amp/s/www.cnbc.c ... ility.html
Cloud VMs hosted on Linux-based servers are probably the most vulnerable to the Meltdown portion of this suite of vulnerabilities. On the other hand, for an issue of this magnitude, major cloud providers like Amazon will be updating their servers as quickly as OS and firmware patches are available.

I'm going to put on my Computer Science Ph.D. hat for the rest of this post. And I taught a computer architecture class in the past, so let me see if I can break this down for the general public. My apologies if this is still too technical. As I already said, this is actually a suite of vulnerabilities in the design of the microprocessor due primarily to the focus on optimizing the throughput of the processor (maximize the number of instructions processed and minimize the delay running a set of instructions). There is a whole realm of design features intended to run instructions through the processor as quickly as possible while still ensuring accurate results.

The classic visualization used in textbooks is to imagine two different ways of doing laundry. In the first method, you wash and dry one load of laundry before starting the next load, such as if you used a combination washer/dryer that can only do one load at a time. That's the archaic processor. It can only do one thing at a time. In the second method, which is probably how most people wash multiple loads of laundry, when you move a load from the washer to the dryer, you then put the next load in the washer. So you are simultaneously washing the second load while the first load is drying. This is much faster than the first method. This is how modern processors work in something called the "pipeline". There are multiple instructions running through the processor at a time, each one at a different stage of processing, similar to doing laundry in stages or running a manufacturing line in stages.

The downside of pipelining a processor is that you may need the results of an instruction that is still in the pipeline in order to start the current instruction. This is common with "branches", which is just fancy architecture-speak for if-else decisions. These branches often depend on the results of a previous calculation, but if that calculation is still in the pipeline, you won't have the results yet. You then have two options: you can wait for the results ("stalling") or you can guess the results ("speculative execution" or "branch prediction"). If your design goal is to maximize the throughput of instructions, guess which option you're going to choose.... speculative execution of course. If you guess correctly, you're already on the right path. If you guess incorrectly, you "unwind" the erroneous instructions and go down the other path instead.

Similarly, for accessing data in memory there is another set of design features designed to make the memory accesses as quick as possible. There are special memory structures called "caches" located on the chip, where they can be accessed quickly from the pipeline. Caches are much smaller than main memory, but since a processor is rarely processing as much data as it can store in main memory, caches can help speed up execution immensely by storing the recently used data. There are many types of caches on the chip: some for program data, some for instructions, and some for virtual memory management.

These vulnerabilities are an intersection of caches and speculative execution. When the processor guesses a path to take for a branch, instructions on that path may also start to fetch data from main memory. That loads the data into the cache. When the processor realizes it made a wrong guess, it "unwinds" the wrong path by clearing the instructions out of the pipeline, but it doesn't clear the memory that was loaded into the cache. That causes something called a "side effect". And side effects can lead to vulnerabilities.

In the least serious vulnerability in this suite, which also affects the widest range of processors, you can test if data was fetched into the cache during an "unwound" speculative execution by testing how long a subsequent memory access takes. If the second access is "fast", the data is in the cache. Now, it's always possible it was there before the branch, but there's a few other tricks to use to see if speculative execution was in play.

For the more serious vulnerabilities, this intersection of "unwound" paths and caches can be used to read memory that the process doesn't have proper permission to access. This includes VMs being able to read memory assigned to the host OS or other VMs. It also includes normal user processes reading kernel (privileged) memory. The proof-of-concepts for these vulnerabilities is primarily for Intel chips and AMD says their chips are not vulnerable to the most severe of these issues.

As for the performance hit after applying patches, that has to do with the caches. The primary software fix to keep information from leaking between instructions running with different permissions is to flush the caches before running instructions with a different set of permissions. But you are figuratively throwing the baby out with the bath water. This gets rid of anything in the cache that might be part of an exploit attempt, but it also gets rid of all the cached data that wasn't part of the exploit. Now your memory loads will take longer as the cache is repopulated for the new set of instructions. If you don't switch often between instructions with different permissions, you won't see much of a slow down. But the more you switch, the slower the memory operations will be as the cache gets reloaded over and over again.

TL;DR - This is the CPU equivalent of the famous I Love Lucy candy factory scene. Someone really should have pushed the emergency stop button (stalled the processor), but in the quest for speed, "hilarity" ensued.

User avatar
tadamsmar
Posts: 7611
Joined: Mon May 07, 2007 12:33 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by tadamsmar » Fri Jan 05, 2018 6:50 am

Mudpuppy wrote:
Fri Jan 05, 2018 3:29 am
Gray wrote:
Thu Jan 04, 2018 10:19 am
That’s why I suggested a chromebook with a limited attack surface (vs a full PC OS) using a PC VM hosted in the cloud without the chip-based vulnerability.

https://www.google.com/amp/s/www.cnbc.c ... ility.html
Cloud VMs hosted on Linux-based servers are probably the most vulnerable to the Meltdown portion of this suite of vulnerabilities. On the other hand, for an issue of this magnitude, major cloud providers like Amazon will be updating their servers as quickly as OS and firmware patches are available.
Is there really a firmware fix for Spectre?
The [Software Engineering Institute] said that "fully removing the vulnerability requires replacing vulnerable [processor] hardware."
http://money.cnn.com/2018/01/03/technol ... index.html

The Software Engineering Institute indicates that "software mitigation" of Spectre is an "Unknown":

https://www.kb.cert.org/vuls/id/584653

But they do rate the difficulty of using Spectre for an attack as "High".

Spectre can be exploited by sandboxed Javascript. I wonder if the whole idea of running a program in your browser is a bad idea without a hardware fix.

User avatar
tadamsmar
Posts: 7611
Joined: Mon May 07, 2007 12:33 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by tadamsmar » Fri Jan 05, 2018 7:57 am

Cert has backed down on recommending CPU replacement.

But the researcher who discovered the Meltdown flaw says otherwise:

On the change in recommendation from CERT, Gruss said, however, that there were no replacements yet that could address the flaws in processors that he and other researchers have found.

"All CPUs are affected, also very recent ones," Gruss said. "Furthermore, software updates can fix most of the problems, leaving only a small remaining attack surface."
http://news.trust.org/item/20180105113731-wb5kp

wrongfunds
Posts: 1349
Joined: Tue Dec 21, 2010 3:55 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by wrongfunds » Fri Jan 05, 2018 9:52 am

Very nice explanation MudPuppy!

The thing which does bother me is that this speculative fetches have been common for decades on high performance processors. Are we to believe that literally millions of computer graduates, computer engineers and professors never realized this vulnerability until today?

Mudpuppy
Posts: 5865
Joined: Sat Aug 27, 2011 2:26 am
Location: Sunny California

Re: Chip architecture vulnerability in pretty much everthing

Post by Mudpuppy » Fri Jan 05, 2018 11:43 am

tadamsmar wrote:
Fri Jan 05, 2018 6:50 am
Mudpuppy wrote:
Fri Jan 05, 2018 3:29 am
Gray wrote:
Thu Jan 04, 2018 10:19 am
That’s why I suggested a chromebook with a limited attack surface (vs a full PC OS) using a PC VM hosted in the cloud without the chip-based vulnerability.

https://www.google.com/amp/s/www.cnbc.c ... ility.html
Cloud VMs hosted on Linux-based servers are probably the most vulnerable to the Meltdown portion of this suite of vulnerabilities. On the other hand, for an issue of this magnitude, major cloud providers like Amazon will be updating their servers as quickly as OS and firmware patches are available.
Is there really a firmware fix for Spectre?
The [Software Engineering Institute] said that "fully removing the vulnerability requires replacing vulnerable [processor] hardware."
http://money.cnn.com/2018/01/03/technol ... index.html

The Software Engineering Institute indicates that "software mitigation" of Spectre is an "Unknown":

https://www.kb.cert.org/vuls/id/584653

But they do rate the difficulty of using Spectre for an attack as "High".

Spectre can be exploited by sandboxed Javascript. I wonder if the whole idea of running a program in your browser is a bad idea without a hardware fix.
The issue that makes the problem so severe on Intel, but not on AMD, is that Intel processors allow speculative execution for memory reads between privilege levels and no processor clears the cache after a wrong guess during branch prediction. Theoretically, one could add microcode to mitigate this, since microcode can change the way the processor executes program instructions. So one could alter the way processors handle branch instructions, even if it's something as simple as inserting nops to stall the processor between calculating where the branch needs to go and actually taking the branch. The practicality of implementing such microcode is above my pay grade though. I didn't specialize in computer architecture in graduate school.

Of course, there will be some people who will not trust the microcode produced by a company which has had multiple hardware-level security vulnerabilities released in recent years. Remember that this issue follows up on the truly newbie string-handling mistake Intel coders made with the authentication module for their remote management engine that let anyone log in to the remote management engine without the proper password. Intel also had some pretty massive goofs in the past at the accuracy and efficiency level (the floating point bug or the horribly bad pipeline and branch predictors of one of the Pentium revisions). So those people would recommend replacement with AMD processors, whether or not a firmware fix via microcode is actually feasible. They've essentially lost trust in Intel to do things properly.
wrongfunds wrote:
Fri Jan 05, 2018 9:52 am
Very nice explanation MudPuppy!

The thing which does bother me is that this speculative fetches have been common for decades on high performance processors. Are we to believe that literally millions of computer graduates, computer engineers and professors never realized this vulnerability until today?
Knowing that there's a side effect and knowing that there's an exploitable side effect are two very different things. Very few graduate programs specialized in hardware-level cybersecurity until the past decade or so. Even then, the level of machine-level programming knowledge needed to really figure out how to do these things is highly specialized. There just aren't many computer science security researchers who possess the required background knowledge and skills to figure this out.

The computer engineers would be most likely to possess the knowledge, but they would also be most likely to be focused on "faster faster faster" than on security. The level of blinders some engineers wear about the security implications of their projects is astounding... and it still propagates at the university level. Professors often operate in a silo where they don't always look outside of their discipline for solutions. I was at an event and a civil engineering professor asked me how to solve a problem for a traffic control system where the solution had existed in the computer science realm for well over a decade. He'd never bothered to talk to the computer scientists at his university, but he just happened to be at my table at this event and suddenly it occurred to him that CS might have the answer he seeks. Now imagine all the engineering projects where the engineers don't ask.

The pessimist in me says all of these long-lasting vulnerabilities being reported recently are just symptoms of a more pervasive, underlying problem in technology: security was not considered at the beginning and was instead shoe-horned onto existing solutions in retrospect. That is a general recipe for disaster, but it's how much (dare I say all?) of the hardware and software we use today is designed. We can keep whacking at the proverbial moles every time they pop up, but it's just delaying the inevitable. Without a fundamental redesign from the bottom-up with security as the primary motivation, it's just going to keep happening.

jebmke
Posts: 7628
Joined: Thu Apr 05, 2007 2:44 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by jebmke » Fri Jan 05, 2018 11:46 am

The technical side of this is beyond me for now. One question I have is what this means for data that is internal to a VM on a Windows host and in particular, data that is provided to a browser for log-in such as password or other credentials? Is that data exposed here?
When you discover that you are riding a dead horse, the best strategy is to dismount.

User avatar
tadamsmar
Posts: 7611
Joined: Mon May 07, 2007 12:33 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by tadamsmar » Fri Jan 05, 2018 11:58 am

jebmke wrote:
Fri Jan 05, 2018 11:46 am
The technical side of this is beyond me for now. One question I have is what this means for data that is internal to a VM on a Windows host and in particular, data that is provided to a browser for log-in such as password or other credentials? Is that data exposed here?
My understanding is that the plain text of passwords that you are typing in are potentially exposed. But it's not clear if anyone has developed an exploit. A exploit requires gaining access to your computer. But Javascript (for instance) running in a browser has access. The problem relates to internal security that keeps programs running on your computer from accessing all information available on your computer. This internal security is compromised.

There are some Javascript proof of concept programs that have been developed and reported by the good guys. One would think that the bad guys are working hard to exploit this including nation states and well-funded crime rings.

I think that one can disable Javascript and other active agents in browsers, but I don't know if that is an important level of protection after you get the available software patches.


azurekep
Posts: 1179
Joined: Tue Jun 16, 2015 7:16 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by azurekep » Fri Jan 05, 2018 12:40 pm

Mudpuppy wrote:
Fri Jan 05, 2018 3:29 am
As for the performance hit after applying patches, that has to do with the caches. The primary software fix to keep information from leaking between instructions running with different permissions is to flush the caches before running instructions with a different set of permissions. But you are figuratively throwing the baby out with the bath water. This gets rid of anything in the cache that might be part of an exploit attempt, but it also gets rid of all the cached data that wasn't part of the exploit. Now your memory loads will take longer as the cache is repopulated for the new set of instructions. If you don't switch often between instructions with different permissions, you won't see much of a slow down. But the more you switch, the slower the memory operations will be as the cache gets reloaded over and over again.
Nice explanation. The above excerpt gets to a question I raised earlier. Intel is apparently disputing the degree of slowdown that will come from the patches and says it is dependent on the type of program. From what I understand of your explanation, it would seem to be programs that heavily use the cache. What programs would heavily use the cache? Browsers? Text editors? Tax programs? MP3 tag editing? Photoshop?

We will all be forced to apply patches to internet-facing computers, whether we want to or not, but it would be useful to have some idea of the degree of performance hit we may experience, especially from workhorse tasks like web browsing. It may force people on slow broadband connections, for instance, to upgrade to faster connections to compensate for the slowed processor/cache-related performance.

azurekep
Posts: 1179
Joined: Tue Jun 16, 2015 7:16 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by azurekep » Fri Jan 05, 2018 12:44 pm

tadamsmar wrote:
Fri Jan 05, 2018 11:58 am
A exploit requires gaining access to your computer. But Javascript (for instance) running in a browser has access.
If javascript is disabled, what next could the attackers use to access the cache? This is primarily a rhetorical question because those of use who routinely turn off javascript, must turn it back on to access most financial sites. But it's good to understand how this all works.

User avatar
Phineas J. Whoopee
Posts: 7062
Joined: Sun Dec 18, 2011 6:18 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by Phineas J. Whoopee » Fri Jan 05, 2018 1:33 pm

Speaking of ARM, here's their list of processors affected. Ones not on the list aren't. You may have to look up the spec for your device, then for your CPU, to find out whether it uses one of these ARM processor types.

I'm lucky. My cheap-o (relatively speaking, $100) smartphone uses a less sophisticated processor, Snapdragon 410 based on the Cortex-A53, which doesn't even have the optimization feature that creates the vulnerability.

PJW

wrongfunds
Posts: 1349
Joined: Tue Dec 21, 2010 3:55 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by wrongfunds » Fri Jan 05, 2018 1:35 pm

One of the principle behind "good" guys finding this type of issues and reporting this privately to the "powers to be" is that the vulnerability is publicly disclosed only after the patch has been in place for a while. From reading the current news, it seems as if the patches have not been yet widely available.

I expect scramble when bad guys find something like this exploit it first but I would have expected Intel/MS/LinuxKernel on top of this. May be I am wearing rose colored glasses.

User avatar
tadamsmar
Posts: 7611
Joined: Mon May 07, 2007 12:33 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by tadamsmar » Fri Jan 05, 2018 1:45 pm

azurekep wrote:
Fri Jan 05, 2018 12:44 pm
tadamsmar wrote:
Fri Jan 05, 2018 11:58 am
A exploit requires gaining access to your computer. But Javascript (for instance) running in a browser has access.
If javascript is disabled, what next could the attackers use to access the cache? This is primarily a rhetorical question because those of use who routinely turn off javascript, must turn it back on to access most financial sites. But it's good to understand how this all works.
For chrome, go here:

chrome://settings/content

Some setting govern active content. My settings are at default and they all indicate "ask first" except javascript.

There is a recommendation to enable Chrome site isolation. This will be default on Chrome 64 which is currently in beta.

User avatar
tadamsmar
Posts: 7611
Joined: Mon May 07, 2007 12:33 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by tadamsmar » Fri Jan 05, 2018 1:48 pm

wrongfunds wrote:
Fri Jan 05, 2018 1:35 pm
One of the principle behind "good" guys finding this type of issues and reporting this privately to the "powers to be" is that the vulnerability is publicly disclosed only after the patch has been in place for a while. From reading the current news, it seems as if the patches have not been yet widely available.

I expect scramble when bad guys find something like this exploit it first but I would have expected Intel/MS/LinuxKernel on top of this. May be I am wearing rose colored glasses.
I read that Spectre and Meltdown somehow leaked to the media and that they were discovered sometime last year.

Whakamole
Posts: 574
Joined: Wed Jan 13, 2016 9:59 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by Whakamole » Fri Jan 05, 2018 1:51 pm

tadamsmar wrote:
Fri Jan 05, 2018 1:48 pm
wrongfunds wrote:
Fri Jan 05, 2018 1:35 pm
One of the principle behind "good" guys finding this type of issues and reporting this privately to the "powers to be" is that the vulnerability is publicly disclosed only after the patch has been in place for a while. From reading the current news, it seems as if the patches have not been yet widely available.

I expect scramble when bad guys find something like this exploit it first but I would have expected Intel/MS/LinuxKernel on top of this. May be I am wearing rose colored glasses.
I read that Spectre and Meltdown somehow leaked to the media and that they were discovered sometime last year.
That is my impression as well though I don't know for sure.

The problem with releasing security patches is that the "black hats" can look at what is being fixed and so what the security issue is. So a patch is in effect an announcement of the security issue.

FactualFran
Posts: 593
Joined: Sat Feb 21, 2015 2:29 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by FactualFran » Fri Jan 05, 2018 2:21 pm

Mudpuppy wrote:
Fri Jan 05, 2018 3:29 am
For the more serious vulnerabilities, this intersection of "unwound" paths and caches can be used to read memory that the process doesn't have proper permission to access. This includes VMs being able to read memory assigned to the host OS or other VMs. It also includes normal user processes reading kernel (privileged) memory. The proof-of-concepts for these vulnerabilities is primarily for Intel chips and AMD says their chips are not vulnerable to the most severe of these issues.
Thank you for posting the technical details. I have a question. How it is possible for one process to access data that was fetched into a cache due the speculative execution of another process unless the two processes share the part of the address space where the data is stored?

It sounds like a software issue rather than a hardware issue. Software should not put sensitive data at a location in its address space that is shared with other processes. An operating system should put sensitive data at a location in its address space that is shared with the processes running under the operating system or shared with the hypervisor.

btenny
Posts: 4395
Joined: Sun Oct 07, 2007 6:47 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by btenny » Fri Jan 05, 2018 2:52 pm

Intel bought McAfee security in August of 2010 with the specific plan to improve security. They announced at that time the merger would help them improve their chip architecture and software security. See here.

https://www.reuters.com/article/idUS372474677420100819

So the way I see it Intel has had SEVEN YEARS to improve their CPU security. However not much has changed or improved on the security front. Security at the CPU level still seems to be a after thought. Responsibility for good security is still the OS and software peoples responsibility. Microsoft and all the other software firms are still over run regularly with security bugs due to bad hardware architectures.

And worse is my view that Intel has mostly given up on security. They sold McAfee in 2016. And until the market demands AMD or Intel or one of the small chip houses take security seriously this situation will only get worse. In fact the cost to secure the internet may overrun the usefulness of many applications.....

Just Thinking......

User avatar
Epsilon Delta
Posts: 7263
Joined: Thu Apr 28, 2011 7:00 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by Epsilon Delta » Fri Jan 05, 2018 3:17 pm

azurekep wrote:
Fri Jan 05, 2018 12:40 pm
Mudpuppy wrote:
Fri Jan 05, 2018 3:29 am
As for the performance hit after applying patches, that has to do with the caches. The primary software fix to keep information from leaking between instructions running with different permissions is to flush the caches before running instructions with a different set of permissions. But you are figuratively throwing the baby out with the bath water. This gets rid of anything in the cache that might be part of an exploit attempt, but it also gets rid of all the cached data that wasn't part of the exploit. Now your memory loads will take longer as the cache is repopulated for the new set of instructions. If you don't switch often between instructions with different permissions, you won't see much of a slow down. But the more you switch, the slower the memory operations will be as the cache gets reloaded over and over again.
Nice explanation. The above excerpt gets to a question I raised earlier. Intel is apparently disputing the degree of slowdown that will come from the patches and says it is dependent on the type of program. From what I understand of your explanation, it would seem to be programs that heavily use the cache. What programs would heavily use the cache?
In most architectures all access to memory is through caches. So all programs heavily use the caches. The ones that would slow down are the ones that make system calls that require caches to be flushed. So if your program is sitting there calculating pi to a billion decimals it won't slow down, but if it polls the keyboard every digit so see if the user has pressed the any key it might.

User avatar
Epsilon Delta
Posts: 7263
Joined: Thu Apr 28, 2011 7:00 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by Epsilon Delta » Fri Jan 05, 2018 3:23 pm

FactualFran wrote:
Fri Jan 05, 2018 2:21 pm
It sounds like a software issue rather than a hardware issue. Software should not put sensitive data at a location in its address space that is shared with other processes. An operating system should put sensitive data at a location in its address space that is shared with the processes running under the operating system or shared with the hypervisor.
No it's not a software issue. The problem is that software (malware) can read data that is not in the processes memory map.

AlwaysBeClimbing
Posts: 143
Joined: Fri Mar 31, 2017 10:39 am

Re: Chip architecture vulnerability in pretty much everthing

Post by AlwaysBeClimbing » Fri Jan 05, 2018 3:38 pm

My own effort at security/mitigation( which I’ve been doing for some time prior to this latest event) is as follows:

-use a dedicated system (I use an old laptop) running Linux for all sessions with my important banking/investment institutions
-on that system only have a single session running in the browser at a time(ie. no sharing between websites)
-auto clear cache,cookies(lone exception is Vanguard) after each session

I haven't resorted to rebooting between sessions. Would that be worthwhile? I don't know.


I’ve been around too long to ever feel “safe”, but short of going back to the telephone and snail mail(will it come to that?) to do business transactions, I believe it’s about the best I can do.

AlwaysBeClimbing
Posts: 143
Joined: Fri Mar 31, 2017 10:39 am

Re: Chip architecture vulnerability in pretty much everthing

Post by AlwaysBeClimbing » Fri Jan 05, 2018 3:42 pm

Mudpuppy wrote:
Fri Jan 05, 2018 11:43 am



The pessimist in me says all of these long-lasting vulnerabilities being reported recently are just symptoms of a more pervasive, underlying problem in technology: security was not considered at the beginning and was instead shoe-horned onto existing solutions in retrospect. That is a general recipe for disaster, but it's how much (dare I say all?) of the hardware and software we use today is designed. We can keep whacking at the proverbial moles every time they pop up, but it's just delaying the inevitable. Without a fundamental redesign from the bottom-up with security as the primary motivation, it's just going to keep happening.

This has been my feeling as well. We've built on a foundation of sand and are continually 'shoring up' using the equivalent of rotten timbers. As you say a delay of the inevitable.

wow!howmuch?
Posts: 27
Joined: Thu Jan 22, 2015 4:45 am

Re: Chip architecture vulnerability in pretty much everthing

Post by wow!howmuch? » Fri Jan 05, 2018 3:54 pm

This story is just another reason why I have 10% of our wealth in physical Gold.
"Gold is warm and contains something of the sun". --Saint Hildegard of Bingen (1098-1179)

FactualFran
Posts: 593
Joined: Sat Feb 21, 2015 2:29 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by FactualFran » Fri Jan 05, 2018 3:57 pm

Epsilon Delta wrote:
Fri Jan 05, 2018 3:23 pm
No it's not a software issue. The problem is that software (malware) can read data that is not in the processes memory map.
Is there a URL that describes that in detail? If the hardware is allowing a process to access memory outside of the address space of the process, then the problem does not depend on speculative instruction execution.

a5ehren
Posts: 52
Joined: Fri May 26, 2017 7:48 am

Re: Chip architecture vulnerability in pretty much everthing

Post by a5ehren » Fri Jan 05, 2018 4:19 pm

FactualFran wrote:
Fri Jan 05, 2018 3:57 pm
Epsilon Delta wrote:
Fri Jan 05, 2018 3:23 pm
No it's not a software issue. The problem is that software (malware) can read data that is not in the processes memory map.
Is there a URL that describes that in detail? If the hardware is allowing a process to access memory outside of the address space of the process, then the problem does not depend on speculative instruction execution.
It's a cache-timing attack combined with the speculative execution feature. Boiled down, you use the branch predictor to jump into kernel space, make two reads and figure out which one is in cache based on how long it takes.

The POCs I've seen reported on are able to extract kernel memory at a rate of a few hundred KB/s, which would require persistent access to get anything useful. Obviously refined versions later on may be able to do better, but for now it isn't too much to be worried about. Especially with the OS patches.

FactualFran
Posts: 593
Joined: Sat Feb 21, 2015 2:29 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by FactualFran » Fri Jan 05, 2018 6:36 pm

a5ehren wrote:
Fri Jan 05, 2018 4:19 pm
It's a cache-timing attack combined with the speculative execution feature. Boiled down, you use the branch predictor to jump into kernel space, make two reads and figure out which one is in cache based on how long it takes.
I understand how it is possible for a process to determine whether data was already in cache. I don't understand how branch prediction can result in a "jump into kernel space". The word "jump" implies that the process goes from executing in application mode to executing in supervisor mode. Is such a mode change is being allowed during speculative execution?

From what has been posted here, it appears that the hardware is allowing a process to access an address outside the address space of the process if the data at that address is in cache as a result of speculative execution. If the data were not in cache or were in cache due to non-speculative execution, then the hardware would detect the access violation. That leaves the question of how the address outside of the address space of the process is being mapped to data that is in cache as a result of speculative execution.

patrick
Posts: 1549
Joined: Fri Sep 04, 2009 3:39 am
Location: Mega-City One

Re: Chip architecture vulnerability in pretty much everthing

Post by patrick » Fri Jan 05, 2018 7:12 pm

FactualFran wrote:
Fri Jan 05, 2018 6:36 pm
From what has been posted here, it appears that the hardware is allowing a process to access an address outside the address space of the process if the data at that address is in cache as a result of speculative execution. If the data were not in cache or were in cache due to non-speculative execution, then the hardware would detect the access violation. That leaves the question of how the address outside of the address space of the process is being mapped to data that is in cache as a result of speculative execution.
As best I can understand the paper (regarding Meltdown):

Operating systems traditionally had user and kernel data in the same address space, with permissions flags preventing user code from accessing the kernel address space. This has the advantage that whenever a system call is made, the kernel code has an address space with access to all of its data, plus the user data at the user's usual address, without having the overhead of changing the address space mapping. The recent software fixes change this, adding back the switching overhead, and thus cause performance losses in applications that make a lot of system calls.

The speculative execution won't directly commit inaccessible data into anywhere the user code can read it (not even a cache line the user code can read). Rather, the attack involves speculatively executing multiple steps:

1) Read in a byte of data from the kernel memory
2) Read in some data from normal memory using this byte as an array index

The second step will then reload one of the cache lines, and which one it is depends on the secret data from the kernel. The speculative execution will be unwound and does not commit the result of either read into any register. But afterwards you can use the cache timing check to determine which part of the array was speculatively read in step 2, which then tells you what secret data was read in step 1.

MindBogler
Posts: 595
Joined: Wed Apr 17, 2013 12:05 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by MindBogler » Fri Jan 05, 2018 7:35 pm

Mudpuppy wrote:
Fri Jan 05, 2018 11:43 am
Without a fundamental redesign from the bottom-up with security as the primary motivation, it's just going to keep happening.
The problem is that many of these exploits only seem obvious in hindsight. You could have a whole team of engineers building something with security in mind and they'd still miss potential attack vectors.

User avatar
Watty
Posts: 13092
Joined: Wed Oct 10, 2007 3:55 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by Watty » Fri Jan 05, 2018 7:48 pm

I can see what these would be a potential problem on a server where multiple people are using the the same computer but I don't understand why this is a problem on a standalone PC that only has one user.

For someone to exploit this this on your home PC I would assume that there would need to be malicious software running on your home PC.

The part I don't understand is if you have malicious software running on your PC then you would be in trouble even without the newly found vulnerabilities.

Why do these vulnerabilities make things a lot worse?

patrick
Posts: 1549
Joined: Fri Sep 04, 2009 3:39 am
Location: Mega-City One

Re: Chip architecture vulnerability in pretty much everthing

Post by patrick » Fri Jan 05, 2018 8:26 pm

Watty wrote:
Fri Jan 05, 2018 7:48 pm
I can see what these would be a potential problem on a server where multiple people are using the the same computer but I don't understand why this is a problem on a standalone PC that only has one user.

For someone to exploit this this on your home PC I would assume that there would need to be malicious software running on your home PC.

The part I don't understand is if you have malicious software running on your PC then you would be in trouble even without the newly found vulnerabilities.

Why do these vulnerabilities make things a lot worse?
When you browse the web you usually run JavaScript from a variety of sources. Even legitimate web sites can have malicious JavaScript if they are hacked or ad space is purchased (using stolen credit cards of course).

JavaScript is a memory-safe language so it won't actually execute any instruction that accesses forbidden memory. But the instructions past a bounds check could get speculatively executed and thus impact which addresses get cached.

azurekep
Posts: 1179
Joined: Tue Jun 16, 2015 7:16 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by azurekep » Fri Jan 05, 2018 10:51 pm

patrick wrote:
Fri Jan 05, 2018 8:26 pm

When you browse the web you usually run JavaScript from a variety of sources. Even legitimate web sites can have malicious JavaScript if they are hacked or ad space is purchased (using stolen credit cards of course).

JavaScript is a memory-safe language so it won't actually execute any instruction that accesses forbidden memory. But the instructions past a bounds check could get speculatively executed and thus impact which addresses get cached.
I would love to see javascript go away. It would get rid of a lot of vulnerabilities. It would seem an easier fix than fixing hardware.

But all those poor retailers would lose ad revenue, and alas, it would be harder to track us around the web. ;)

Post Reply