Intel Flaw Impact on VMS / NVRs Examined

By: Brian Karas, Published on Jan 05, 2018

A flaw has been found in Intel processors that exposes protected memory to unauthorized access. The flaw requires fundamental changes to operating system memory handling to correct, which comes at the cost of performance impacts.

Several technology publications have been covering this flaw, and anticipated impacts, including:

Due to the nature and severity of this flaw, Intel is still in process of releasing details, though much has been discovered by researchers analyzing the patches.

In this note we examine what is known, what is still not disclosed by Intel, and the potential impact on VMS systems or other high-demand applications using these processors.

* **** *** **** found ** ***** ********** that ******* ********* ****** to ************ ******. *** flaw ******** *********** ******* ** operating ****** ****** ******** to *******, ***** ***** at *** **** ** performance *******.

******* ********** ************ **** been ******** **** ****, and *********** *******, *********:

*** ********: ****’* ****** the ***** ****** **** forcing ******** *******?
*********: ***** ********* ********* ‘PR *********’ **** ******** Chip ****
*** ********: ******-******-******* ***** processor ****** **** ****** *****, Windows ********
*******: *** * ********** hacked *** *** ******** and ***** '*****' **** flaw
***: ***** ******** **** Chip **** *** ******

*** ** *** ****** and ******** ** **** flaw, ***** ** ***** ** process ** ********* *******, though much *** **** ********** by *********** ********* *** patches.

** **** **** ** examine **** ** *****, what ** ***** *** disclosed ** *****, *** the ********* ****** ** VMS ******* ** ***** high-demand ************ ***** ***** processors.

[***************]

Virtual ****** ********** ****

* **** *** ********** where **** ** ********* kernel ******* ****** ***** be discovered ** ************ **** software, ********* **** *** processor ****** *** ******** to ******* *******. ******** of ******** ******* ** experts *** ******** **** these ******* ******* *** way *** ********* ******* handle ******* ****** ***********. In *****, ****** ********* systems *** * ******* memory ********** ****** ***** memory ** ******* ********* into "******" ** ********* system *****, *** "****" or ******* *****. *** idea ****** **** ************ was ** ******** ****** performance, *** ******* ******** from ********* ****** **** by *** ******, ***** often ******** ********* **** or *** ******* ** manipulate **** ********** ** how *** ****** ******* tasks.

All ***** ********** ****** ********

*** ******* ** ********* with ** ***** ********* is ****** ********, ********** of ********* ******. ***** has *** ******** * list ** ******** **********, but *** ******* ****** management ******* **** ****** to ** ******** **** been **** ** *** ***** *** processors ******* *** *** last ****** ** ****, with *********** ** *********************** ** ***** ********** as *** **** ** 2007.

Moderate ****

***** **** **** **** not ***** **** ** be ******** ** *******, it ***** ** ********* to ****** ****** ***************, which ***** ****** ** significant **** **** ** disclosure. ***** ** ******* exploits have ******* **** ********* ** researchers, **** ** ***** can ** ******** ** a *** ******* ********* a ********* ****. *******, there *** *********** **** flaw *** ** **** to ***** * ********* program ******** ****** * virtual ******* ** *********** break *** ** *** VM *** ****** **** in ****** **** ***** normally ** ********** *********.

*** **** ******** * ********* program ** ** ****** and ******** ** * machine **** ** ******** processor, ******* **** ** takes **** **** **** remote ************* ** ****** a ****. ******** **** are ******** *******, *** are ********* **** ********* unknown **** *** ************* safe, ******* **** ** environment ** **** ********* to ******** ** ********, particularly **** *** *** used *** ******* ** different *********** ** ******** (e.g.: ****** *********, ** corporate ******* ****** ** a ******* ** ***********), and **** ***** ****** consider **** ** ******* ****** on ******* ***** **** lack **** *******.

Significant *********** ****** **** *******

*********** ******* ** ** 50% *** ***** **** on ******* *******, **** a ******* ********* ** ~30% *********** ****** *** many *****. ****** ****** ****** they **** ********* * patch *** ***** ******* that ************ *********** ******. ******* ****** ******* on ********** ********* *** specific ********* ****. *******, it ****** ** ***** that **** ******* *** run ** *** **** than ***% ** ********* load, ** ***** *********** impacts *** *** ************* slow **** ******* ********* of ******* **** *******.

*** ******* ***** ****** out ** ******* ********* systems primarily ****** ********** **** **** significant ******* ** ********** I/O, ** ** ****** in *** *******. ***** patches ********** *** *** processors ********* ** ***** protect *** ****** ****** space **** ***** ******** by **** ********. *** methodology **** ** ** this ******* ** * significant ******** ** ****** "swapping", ** *** ******* memory ********* *** *********** been *** ** ****, as ******* **** ** kept ** *** ******* half ** *** ******* memory ***** ** ** effort ** ****** *** amount ** **** **** could ** ******* ** probing ******* **** ********* user ****. *** ******** to *** ******* ****** and ********* ******** ** a *********** ******.

Core ******* *** **** ****** ***

*********** *** ***** ** release **** ******* *** additional ***********, **** **** *** made **** ******* ** the **** ****** ***, releasing ***** ******* ***** embargo ** ********* ****** developers ** ****** **** to ****** *** ********** patches ** ******* ** full **********. ** ** expected **** ***** **** release **** ******* ** the ****, *** ******* vulnerabilities, ******** ** ******* 2018. ******* ** **** information *** **** ***********, and ******** **********, ****** understand *** ***** *** how ** ******** *********** impacts.

AMD ********** **** ********

***, ***** ******* ********** designed ** ** ** alternative ** ***** ********, ****** to *** ** ******** to *** **** ****** as ***** [**** ** longer *********]. *** *** variant ** ****** ***** they *** ********, **** anticipate ***** *********** *******, though ***** ********** **** not **** ***** ******** by *********** ***.

Video ************ *** ** *****

***** ** ****** ******** as *** ******** ********* company ** *** ****** and *********** ********* *****, and **** ***** ******** are ******* ******** ** computers ******** *** ******** and ************ ************.

* ****** ** ******* and ************ ********* **** Avigilon, *****, *******, *********, and ****** *** ****** ********* use ** ***** **********.

Impact ** *** *******

*********** ******** **** ******** VMS ************* ********* **** performance ******* *** ******, with *** ********* * 20% ****** ** ********* performance, *** ************* **** not *** ***** *********** the ****** ** ***** impacts, ** ******** ****-*******. Most ****** **** **** in *** ******* ** applying *** ******* ** test ******* *** ********* impact, **** ***** ** release ********** *********** ** the ****** *****. ** will ****** **** ******* accordingly ** ** ******* feedback **** *************.

Embedded **** *** ****

******** **** **** ** not ******* *** ******* to **** ******** ********, such ** *******'* **** *** ** *********, ** units **** *****, *********, IDIS, ***. ****** *** be ******** ** ****. These ***** ** *** have ********** *** ***** to **** *** ******* arbitrary ********. *********-***** *****, such ** ********'* ** ***** *********, ** *******'* ** **********, *** ******* ***-****** systems ***** ***** *** access ******* ** ***** consoles, **** * **** risk.

Benchmark *********** ****** ********

***** ****** ********* *********** of ******* *** ************, particularly ***** **** *****, before ********** ********* ****** updates. **** **** **** determine *** ****** ** performance ******* ***********, *** may **** ** *********** mitigation ********** ** *********** degrades ***** ********** ******.

***************

*** ** *** ****** of **** *************, ***** should **** ** ******* OS ******* ** *********** by ***** ** ********, as ****** ******* **** likely **** ** ******* contained ** *** *******. Due ** *** ****** of *** *******, *** how ****** ****** ******** is ********, ******* ** other ******** *** **** need ** ** ******* to ****** *** ****** functionality ** **********. ******** updates ******** **** ** dependent ** *** ** and *********, *** **** most ****** ** *********** of *** ****.

Comments (55)

Undisclosed Integrator #1

01/05/18 02:37pm

The flaw requires a malicious program to be loaded and executed on a machine with an affected processor

Other than patches, is there anything we can do to help protect against this? Most of the servers we install are never interacted with so I am not sure what the level of risk is for us. Performance decrease is a major concern for me. While we typically allow for some wiggle room a potential for up to 20% decrease in performance is entirely unacceptable.

So the real question is, on small systems is it even worth patching? This is way outside of my skill set so I am mostly in the dark here.

Brian Karas

IPVM | In reply to Undisclosed Integrator #1 | 01/05/18 02:56pm

Other than patches, is there anything we can do to help protect against this?

Do everything you can to ensure no new/unknown code gets on the servers. This also means limiting or strictly controlling things like RDP access, or even plugging USB devices in that could be used for attacks as a method to install malicious programs.

So the real question is, on small systems is it even worth patching?

In a pre-internet era, where you could reasonably expect to keep devices sandboxed away from the rest of the world, I would probably say "don't bother". But in modern setups, where remote access to video is common and expected, it seems potentially risky.

A good compromise might be to delay patches for a while until the full extent of the performance impacts, and updates from VMS manufacturers are known. This trades some exposure risk for better potential to minimize performance hits. You may find that initial performance hits are somewhat large, but then things improve and settle out to something like 5% that could be more easily absorbed.

Undisclosed Integrator #1

In reply to Brian Karas | 01/05/18 03:49pm

A good compromise might be to delay patches for a while until the full extent of the performance impacts, and updates from VMS manufacturers are known.

I think you might be onto something there, I will wait it out a week or two and see what news comes out of all this. I don't like the idea of jumping when everyone else jumps.

Undisclosed Integrator #7

In reply to Undisclosed Integrator #1 | 01/05/18 10:56pm

Just as an FYI. Even if you do patch your servers there is a very high likelihood that the first few patches are going to be targeted by hackers because Microsoft is currently just putting a band-aid on a gaping wound. I would do a lot more research before planning which part of the ship you want to jump from...

Undisclosed #4

IPVMU Certified | In reply to Undisclosed Integrator #1 | 01/06/18 10:39pm

I think you might be onto something there... I don't like the idea of jumping when everyone else jumps.

Convinced me too. I don’t mind the idea of not jumping when everyone else doesn’t.

Undisclosed Integrator #6

In reply to Undisclosed Integrator #1 | 01/05/18 08:42pm

What VMS do you utilize? Are you using edge motion detection or is motion detection occurring at the server?

Undisclosed End User #2

01/05/18 02:50pm

Y2K Redux...

Brian Karas

IPVM | In reply to Undisclosed End User #2 | 01/05/18 03:40pm

How so? Do you think the panic is overhyped, or something else?

Undisclosed End User #2

In reply to Brian Karas | 01/05/18 04:11pm

No, the opposite, server replacements or additional servers to handle the new load.

Busy PACS systems and VMS servers especially....

Back in 1999, I swapped many F/W chips in Schlage(Westinghouse) 808 Panels

Undisclosed Integrator #3

01/05/18 05:19pm

What about Hikvision? Should they not be the target as usual? Or the Chinese? What happened Hikvison is soo soo bad and does all these evil things, and every other American or South Korean manufacturer is solid as a rock, never makes mistakes like this, no way.... how could this even come under consideration? Engineering flaw my ass ....that was not acceptable from Hikvision why now believable from Intel without question?.....Maybe it's the NSA planting something to see you remotely?....maybe Intel made a mistake? Hikvision has been claimed to make these type flaws from such "poor engineering standards" and done intentionally on there part, remember?

Where is secret agent Bashis? He must missed this one....

We reap what you sow.... Just saying!

Brian Karas

IPVM | In reply to Undisclosed Integrator #3 | 01/05/18 05:56pm

It is unfortunate that you claim to install surveillance systems in sensitive areas, and cannot understand the basic differences between a flaw buried deep in the nuances of how microprocessors handle virtual memory allocations, and a wide-open backdoor that a manufacturer incorporates into their products.

Undisclosed Integrator #3

In reply to Brian Karas | 01/05/18 10:38pm

Once again you attempt to override what I said with attitude and a feeble attempt to insult another commenter.

Did you notice I said 'engineering flaw' My comment was not about technology, or Hikvision per se it was a comparison of the difference in reporting between anything Hikvision and Intel, you missed it.

Its unfortunate that you believe understanding a"flaw buried deep in the nuances of how microprocessors handle virtual memory allocations" is a major requirement for being a leading Integrator, your belief holds no water.

I would ponder just how many integrators rise to level of your wizardry and would venture to say they can actually, really, technically explain the above? Only problem IPVM only has 10-11,000 members, quite a minor audience to get a real world opinion from.

Undisclosed Integrator #6

In reply to Undisclosed Integrator #3 | 01/05/18 11:11pm

being a leading Integrator

LOL

Your reality distortion field must have a 1' radius.

Brian Karas

IPVM | In reply to Undisclosed Integrator #3 | 01/05/18 11:30pm

Did you notice I said 'engineering flaw' My comment was not about technology, or Hikvision per se it was a comparison of the difference in reporting between anything Hikvision and Intel, you missed it.

Your first words were: "What about Hikvision? Should they not be the target as usual?" This shows either an extremely poor attempt at sarcasm, or a lack of understanding of the basic concepts being conveyed in reports on vulnerabilities. Since you are a very adamant Hikvision supporter, I interpreted your opening words as genuine concern, not sarcasm. Further, I think that was the right interpretation, based on your response above.

Its unfortunate that you believe understanding a"flaw buried deep in the nuances of how microprocessors handle virtual memory allocations" is a major requirement for being a leading Integrator, your belief holds no water.

I do not think it is a major requirement. I do believe you should be able to tell the differences at least to the extent you are able understand that a flaw in a processor, which is a component complete systems are built around, is fundamentally different than a glaring flaw in the software developed and shipped by a "finished goods" manufacturer. Hikvision cannot be held accountable for using Intel processors, as they, like others, had no real way to be aware of this flaw. Hikvision can, and should, be held accountable for their own errors, which provide a highly exploitable flaw in their products that can be leveraged with cut-and-paste simplicity.

I would ponder just how many integrators rise to level of your wizardry and would venture to say they can actually, really, technically explain the above?

No idea. But hopefully after reading this post today, that number is a little higher than it was yesterday, as one of my overarching goals in joining IPVM was to share knowledge and help people understand new concepts. While I have certainly made some inroads in that regard, I clearly have more work to do.

Undisclosed #4

IPVMU Certified | In reply to Undisclosed Integrator #3 | 01/05/18 07:12pm

Is it definitely a fact that “Unhelpfuls” subtract from ones Top Commenter totals? If so, that’s impressive!

Armando Perez

IPVMU Certified | In reply to Undisclosed Integrator #3 | 01/05/18 08:23pm

wat?

Undisclosed #9

In reply to Undisclosed Integrator #3 | 01/08/18 01:04pm

Hikvision has its own demons... and tons of analysis about. And “fake news” claims is all we had from them.

Intel screwed it up and ADMITTED IT. They didn’t call anyone lier, as far as I know.

Sean Nelson

Nelly's Security
In reply to Undisclosed Integrator #3 | 01/08/18 03:16pm

First the Genetec Hack, Now this? PC's are obviously a hack fest waiting to happen.

VMS Manufacturers, please update your hardening guides: Do Not Install Software on PC's

Undisclosed Manufacturer #11

In reply to Sean Nelson | 01/08/18 04:17pm

The DC hack was not a Genetec hack. The PC that Genetec was installed on was hacked due to RDP being installed by the integrator. If they followed Genetec's hardening guide and best practices, they would not have been hacked.

Sean Nelson

Nelly's Security
In reply to Undisclosed Manufacturer #11 | 01/08/18 04:19pm

Did Genetec ship the NVR with default usernames and passwords?

Undisclosed Manufacturer #11

In reply to Sean Nelson | 01/08/18 04:26pm

Genetec software was installed on integrator provided PCs. During installation, a password must be entered. There is no default, IIRC.

Sean Nelson

Nelly's Security
In reply to Undisclosed Manufacturer #11 | 01/08/18 04:28pm

Not on this machine it wasnt.

Brian Karas

IPVM | In reply to Undisclosed Manufacturer #11 | 01/08/18 04:41pm

For the DC MPD case, the integrator provided units containing Genetec appliances. Those appliances at the time shipped with default credentials, which were recommended to be changed per Genetec's hardening guide.

In this case, while the Genetec software itself was not hacked, the appliance at the OS-level had default settings that made it vulnerable.

Brian Karas

IPVM | In reply to Sean Nelson | 01/08/18 04:28pm

Sean -

Do you honestly believe you are making yourself and/or Hikvision look better with comments like this in topics related to vulnerabilities?

Sean Nelson

Nelly's Security
In reply to Brian Karas | 01/08/18 04:46pm

Brian-

Where did I mention Hikvision? I think this has become a major problem for you. You are so mentally entrenched in trying to find an angle to demean Hikvision that you blurt it out of nowhere.

In the name of research, Could you please make a Genetec Hack Map which shows all the "still vulnerable" machines out there that was shipped with default usernames and passwords?

You have to ask yourself the question, do you think you are making yourself look good by saying that you offer fair and balanced reporting when give such powder puff criticism no the Genetec article (where you pretty much were not critical at all) and on the other hand you are beating a dead horse to a pulp on your Hikvision and China reporting.

I'm sure I will get tons of dislikes and frowny faces on this post and you will get applauded and smiley faces will abound for you. What you are failing to understand and why its hard for you to grasp this and answer this question, is that you have marketed so effectively towards this particular type of reader base so of course they are going to support you.

John Honovich

IPVM | In reply to Sean Nelson | 01/08/18 05:40pm

Where did I mention Hikvision?... you blurt it out of nowhere.

Sean, you are too smart to play dumb.

Not only do you sell / OEM Hikvision, you defend and promote Hikvision all the time on IPVM. Just last week you declared: "I think your going to find out that even if you pay more, you wont get better quality than Hikvision, and sometimes you will even get worse." Or your classic, "I Dont Really See Hikvision Competing With Anyone. They Are So Far Ahead Of Everyone Else." The overwhelming majority of your comments are about Hikvision so you know when you attack Genetec or others it's because you are promoting Hikvision.

And that's fine, as we have said many times before we welcome debate and diverging viewpoints.

And we are not going to try to convince you because you evidently can't distinguish default passwords (which Hikvision did for years as well) vs backdoors, sending admin passwords in plain text, cracked security codes, etc.

Let me close with two quotes:

It is difficult to get a man to understand something, when his salary depends on his not understanding it.

And to quote you:

Turns out I was crazy for thinking like this because i failed to understand my brain doesn't work like another guys brain.

Sean Nelson

Nelly's Security
In reply to John Honovich | 01/08/18 06:10pm

It is difficult to get a man to understand something, when his salary depends on his not understanding it.

I am so glad that you are admitting what I have been saying all along. This is why I shrug off some of your articles and am still a subscriber of IPVM. I understand that reporting on Hikvision in a scandelous manner is part of your business plan. All I am saying is that you should be careful about over doing it, or worse, making it so utterly one sided where it affects your believability rating.

At any rate, I hate to drift away from the point of the article and I wont anymore. Similar to you suggesting that all of the hundreds of thousands of Hikvision (maybe millions) of users set up a VPN for remote access, I suggested something similar: That VMS manufacturers should suggest not using PC's in their hardening guide.

The conversation drifted off because Brian asked me if I looked good, and then mentioned something about Hikvision.

John Honovich

IPVM | In reply to Sean Nelson | 01/08/18 06:17pm

Sean,

Another quote is in order:

first take the plank out of your own eye, and then you will see clearly to remove the speck from your brother's eye.

Here's the difference: you sell Hikvision. We don't sell any video surveillance products, ergo your 'salary' depends on Hikvision, ours depends on no manufacturer.

And as for your contention that IPVM "reporting on Hikvision in a scandelous manner", I need go no further than today's test post to disprove your allegation - Hikvision IR Bullet Camera Shootout.

You are upset that our independent reporting undermines what you sell.

Sean Nelson

Nelly's Security
In reply to John Honovich | 01/08/18 06:22pm

We both sell Hikvision my friend....We both do.....

Perhaps you can understand it this way. You know how you criticize Hikvision for always posting sales?

I will leave it at that...

John Honovich

IPVM | In reply to Sean Nelson | 01/08/18 09:47pm

We both sell Hikvision my friend

Sean, two lies in one sentence, that's an accomplishment of a sort!

This is your tactic when you know you lost. You claimed that we cover Hikvision in a scandalous manner. I retorted, disproving your claim, that just today we published a factual in-depth report - Hikvision IR Bullet Camera Shootout. Since you cannot overcome that, you resort to a lie and hand waving. That's fine as I am sure most can see through it.

Sean Nelson

Nelly's Security
In reply to John Honovich | 01/08/18 10:09pm

John, you and Brian are "racing to the bottom" with your continual comments

you lost

i surrender. I sell actual Hikvision products. You sell Hikvision scandal. I cant outsell you at your own game. You win!!

John Honovich

IPVM | In reply to Sean Nelson | 01/08/18 10:16pm

Sean, the fact that you keep ignoring my counter-evidence to your 'scandal' claim, including the numerous factual Hikvision tests we do, like today's Hikvision IR Bullet Camera Shootout just reinforce's that you are not discussing in good faith or with an intention to face the facts of the situation.

Sean Nelson

Nelly's Security
In reply to John Honovich | 01/08/18 10:43pm

John, i have grown bored of this conversation and its far too easy for me (but i dont have time and certainly dont care to) to go copy and paste all your negatively biased articles, discussion posts, comments on articles on Hikvision and how they far outweigh any other manufacturer by 100 miles. I've peppered in my facts enough during the times they were discussed.

John Honovich

IPVM | In reply to Sean Nelson | 01/09/18 12:36am

Sean, another sophist debating tactic. You claim it's so easy and there are so many but then you provide none. You still, after me asking 3 times about today's Hikvision test, cannot offer any coherent attempt at a response to that.

And we criticize Dahua frequently and harshly (e.g., 1, 2, 3) but you never object to that. Why? Because as you bragged in late 2017:

I made alot of money when we i was riding the Dahua horse. I was smart enough to put that horse to pasture late last year though.

Toot Toot! Now im on the Hikvision train and making a great living doing it.

One day you will be off the Hikvision train and then magically you will no longer see IPVM as being biased against Hikvision. Until then, we will patiently suffer your poor attempts at debating.

Undisclosed #4

IPVMU Certified | In reply to John Honovich | 01/08/18 10:25pm

first take the plank out of your own eye, and then you will see clearly to remove the speck from your brother's eye.

Jesus, that’s good!

Undisclosed #12

In reply to Undisclosed #4 | 01/08/18 10:31pm

Jesus, that’s good!

Close. Matthew 7:5.

Marty Major

FLIR Security
In reply to Undisclosed #12 | 01/13/18 06:00am

To explain perspective, I prefer the more secular quote from Alexander Pope:

"All seems infected that the infected spy, As all looks yellow to the jaundiced eye."

This concept was also depicted in the 1971 classic animated film "The Point" - narrated by Ringo Starr and featuring the main character Oblio, voiced by Mike Lookinland, known for his role in the Brady Bunch as the youngest male child, Bobby Brady.

If you have never seen this film, I highly recommend it - and your kids will like it too.

John Honovich

IPVM | In reply to Undisclosed Integrator #3 | 01/08/18 06:05pm

#3, I gave you both an informative and a funny. The 28 unhelpfuls, which may be some sort of record, misses a critical point, in my opinion.

This is great news for Hikvision salespeople because they can now use this for their favorite defense - everyone is terrible so buy us because we are cheaper and will throw more money at you in sales and marketing events.

It goes like this: "The Chinese government is bad but so is the US government!" "Hikvision is bad but so is Intel!"

And it is going to work on the many unsophisticated Hikvision dealers who think a kernel is part of popcorn and that Hikvision's backdoor is no different nor worse than anything else.

At least we should thank #3 for giving us a preview of this tactic.

Undisclosed End User #2

01/05/18 05:41pm

"Intel" NSA back doors probably built in on purpose.

Maybe Oracles stock will go up?:

http://www.oracle.com/technetwork/systems/opensparc/index.html

Open Source 64 bit CPU

Undisclosed #5

01/05/18 07:14pm

You sort of mixed both released issues together here.

Meltdown is the vulnerability that allows attackers to read arbitrary memory from a non privileged process including kernel memory. This can allow escalated privileges and control of the system. Interestingly, the patches for this cannot actually "fix" it, because there is no practical way to change the way modern existing CPUs work. The reason for this is it exploits out of order instruction executions on the CPU. The patches address this by removing the protected memory address mapping in user space so it makes the attack not practical anymore. The side effect of that is the performance hit.

AWS, Azure etc were already patched before disclosure. Smaller clouds, maybe not so much because they were not in on the embargoed information. If you are using a smaller cloud provider YOU NEED TO ASK if you are using one!

This vulnerability is especially bad for multi-tenant environments. When people ask why you don't want to share severs, this is why! Both Xen and Docker may have Hypervisor escapes. It hasn't been seen yet on VMware, but that is certainly no guarantee it's immune and I would not bet on that.

Spectre only affects the current process not kernel or other processes. Branch prediction and speculative execution algorithms are what Spectre attacks. Is is mostly going to affect browsers by leaking data between tabs. Java can get outside the sandbox and read other tabs. Although this really isn't Java's fault, Peal and Python have the same problems because this is a CPU issue not a software issue.

The biggest deal though is leaking of addresses out of user space modules breaks Address space layout randomization (ASLR) which opens up a lot of other remote code execution vulnerabilities that previously had been impractical because of ASLR. The other thing is session keys are vulnerable in the browser if the session is not ended and logged out. This can make multi factor authentication ineffective if the session keys get stolen. Remind users to ALWAYS log out of sessions, don't just close the tab.

The other bad news here is this has been embargoed for almost a year, so the chances a nation state has exploited this are not insignificant. The paper also left open a number of other areas that future research needs to be done on that may lead to other exploits like these being found.

Brian Karas

IPVM | In reply to Undisclosed #5 | 01/05/18 07:25pm

You sort of mixed both released issues together here.

That was done on purpose. There are a lot of IT-centric publications that are covering this in depth and getting deep into technical details. We wanted to publish something that gave IPVM members enough working knowledge of the issue, and an understanding of how to evaluate their risks and options as it relates to security/surveillance equipment specifically (which is not covered anywhere else, including other industry publications).

Your comment above is very informative about some of the details/differences of the two main issues.

For people who want a deeper technical dive without getting too much in the weeds, this blog post explains things pretty well: Why Raspberry Pi Isn't Vulnerable to Spectre Or Meltfdown.

Undisclosed #5

In reply to Brian Karas | 01/05/18 07:47pm

Thanks! I hope that didn't come off snarky, that was not my intent. I just wanted to make sure people knew there are two very distinct issues here and they both have different threat vectors and exploitation potentials.

Brian Karas

IPVM | In reply to Undisclosed #5 | 01/05/18 07:54pm

Thanks! I hope that didn't come off snarky, that was not my intent.

Was not taken that way. I appreciate you taking the time to add some additional helpful comments.

Undisclosed Integrator #6

01/05/18 09:42pm

This looks like it goes all the way back to the Core Duo and Core 2 era based on the link referring to 2007 processors. Is there a list of which processors are not affected? I am hopeful the Xeon E5 series and up are exempted, as unlikely as it seems.

Ought to be interesting to watch how significantly the Passmark scores decline on Intel in the coming weeks.

Brian Karas

IPVM | In reply to Undisclosed #6 | 01/05/18 09:51pm

'486 processors are known to not use this architecture. Pentium processors, which were first introduced in 1995, are where this architecture was implemented. Fundamentally, every Intel processor is vulnerable, though many cannot be reasonably tested if they are not readily available. Because the vulnerability is dependent on precision timing, there is the slight possibility that older processors, and their supporting motherboards and components, would not enable this attack vector, but I would not hang my hopes on that.

If it says "Intel Inside", you are most likely going to be doing some patching.

Undisclosed Integrator #8

01/06/18 12:40pm

I think the performance hit is being overblown. Watch this video from the Naked Security team (Sophos)

https://nakedsecurity.sophos.com/2018/01/04/fckwit-the-video/

Brian Karas

IPVM | In reply to Undisclosed Integrator #8 | 01/06/18 03:29pm

I think it is too early to say for sure, and very dependent on what kinds of I/O are involved, and potentially on some of the efficiencies of the code being executed.

Here is a post gaming company claiming a large hit on performance, showing a large spike in CPU after patching (no details given on processor or OS, seems to be an app that streams a lot of data over UDP):

Undisclosed Integrator #7

In reply to Undisclosed Integrator #8 | 01/07/18 12:43pm

In my option it doesn't really matter how overblown the issue is. If you are running a system at redline a 1-2% margin is the difference between the system being stable and the system crashing multiple times a day. The issue goes a lot further than the security industry.

Undisclosed Manufacturer #10

01/08/18 01:27pm

Intel just posted the list of CPUs affected:

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr

Undisclosed Manufacturer #10

01/08/18 01:28pm

The following Intel-based platforms are impacted by this issue. Intel may modify this list at a later time. Please check with your system vendor or equipment manufacturer for more information regarding updates for your system.

Intel® Core™ i3 processor (45nm and 32nm)
Intel® Core™ i5 processor (45nm and 32nm)
Intel® Core™ i7 processor (45nm and 32nm)
Intel® Core™ M processor family (45nm and 32nm)
2nd generation Intel® Core™ processors
3rd generation Intel® Core™ processors
4th generation Intel® Core™ processors
5th generation Intel® Core™ processors
6th generation Intel® Core™ processors
7th generation Intel® Core™ processors
8th generation Intel® Core™ processors
Intel® Core™ X-series Processor Family for Intel® X99 platforms
Intel® Core™ X-series Processor Family for Intel® X299 platforms
Intel® Xeon® processor 3400 series
Intel® Xeon® processor 3600 series
Intel® Xeon® processor 5500 series
Intel® Xeon® processor 5600 series
Intel® Xeon® processor 6500 series
Intel® Xeon® processor 7500 series
Intel® Xeon® Processor E3 Family
Intel® Xeon® Processor E3 v2 Family
Intel® Xeon® Processor E3 v3 Family
Intel® Xeon® Processor E3 v4 Family
Intel® Xeon® Processor E3 v5 Family
Intel® Xeon® Processor E3 v6 Family
Intel® Xeon® Processor E5 Family
Intel® Xeon® Processor E5 v2 Family
Intel® Xeon® Processor E5 v3 Family
Intel® Xeon® Processor E5 v4 Family
Intel® Xeon® Processor E7 Family
Intel® Xeon® Processor E7 v2 Family
Intel® Xeon® Processor E7 v3 Family
Intel® Xeon® Processor E7 v4 Family
Intel® Xeon® Processor Scalable Family
Intel® Xeon Phi™ Processor 3200, 5200, 7200 Series
Intel® Atom™ Processor C Series
Intel® Atom™ Processor E Series
Intel® Atom™ Processor A Series
Intel® Atom™ Processor x3 Series
Intel® Atom™ Processor Z Series
Intel® Celeron® Processor J Series
Intel® Celeron® Processor N Series
Intel® Pentium® Processor J Series
Intel® Pentium® Processor N Series

Truman HW

01/13/18 11:34am

Anyone know if this affects the

i7-7700 (Kaby Lake - with native H.265)

and the...

i7-8700 (Coffee Lake (Kaby successor, from 4-core to 6-core) also with H.265.

I'm hoping not given how recent they came out. :-0

Undisclosed Integrator #6

In reply to Truman HW | 01/13/18 02:23pm

Yes, they are impacted. They are 7th and 8th generation Core processors.

Peter Thompson

01/13/18 07:14pm

I have a more basic question about updates to VMS systems vs. operating system upgrades: When we install a VMS server that was pre-configured by the manufacturer the assumption is that the OS provided has been tuned for optimum system performance. Presumably OS components that could impact performance have been removed or disabled, and the overall system has been tested rigorously under the specific OS installed. Automatic OS upgrades are often disabled as delivered.

In addition to the likelihood of system performance reduction following patching for these particular flaws should we be expecting specific instructions from manufacturers detailing exact patches to apply, or should we just allow the OS update tool to apply ALL available patches?

Obviously it is always important to have a clean backup of the system prior to patching, but some problems may not appear until specific conditions are met days or weeks later.

Brian Karas

IPVM | 01/13/18 08:25pm

In addition to the likelihood of system performance reduction following patching for these particular flaws should we be expecting specific instructions from manufacturers detailing exact patches to apply, or should we just allow the OS update tool to apply ALL available patches?

In this case, you should really talk to your VMS manufacturer for specifics. Because the performance impacts often revolve around I/O operations (which is a big part of what a VMS does, move bits from the NIC to the HDD), and because each VMS handles this in slightly different ways (how data is cached, indexed, etc.) it is very likely that some may be more impacted than others.

John Honovich

IPVM | 01/28/18 07:24pm

Interesting new disclosure: Intel Warned Chinese Companies of Chip Flaws Before U.S. Government:

Because the flaws can be leveraged to sneak sensitive data out of the cloud, information about them would be of great interest to any intelligence-gathering agency....

It is a “near certainty” Beijing was aware of the conversations between Intel and its Chinese tech partners, because authorities there routinely monitor all such communications

Intel Flaw Impact on VMS / NVRs Examined

Comments (55)

Undisclosed Integrator #1

Brian Karas

Undisclosed Integrator #1

Undisclosed Integrator #7

Undisclosed #4

Undisclosed Integrator #6

Undisclosed End User #2

Brian Karas

Undisclosed End User #2

Undisclosed Integrator #3

Brian Karas

Undisclosed Integrator #3

Undisclosed Integrator #6

Brian Karas

Undisclosed #4

Armando Perez

Undisclosed #9

Sean Nelson

Undisclosed Manufacturer #11

Sean Nelson

Undisclosed Manufacturer #11

Sean Nelson

Brian Karas

Brian Karas

Sean Nelson

John Honovich

Sean Nelson

John Honovich

Sean Nelson

John Honovich

Sean Nelson

John Honovich

Sean Nelson

John Honovich

Undisclosed #4

Undisclosed #12

Marty Major

John Honovich

Undisclosed End User #2

Undisclosed #5

Brian Karas

Undisclosed #5

Brian Karas

Undisclosed Integrator #6

Brian Karas

Undisclosed Integrator #8

Brian Karas

Undisclosed Integrator #7

Undisclosed Manufacturer #10

Undisclosed Manufacturer #10

Truman HW

Undisclosed Integrator #6

Peter Thompson

Brian Karas

John Honovich

Login to read this IPVM report.

Member Login

Related Reports

Recent Reports