Wednesday, July 11th 2018

New "Spectre" Variant Hits Intel CPUs, Company Promises Quarterly Microcode Updates

A new variant of the "Spectre" CPU vulnerability was discovered affecting Intel processors, by security researchers Vladimir Kiriansky and Carl Waldspurger, who are eligible to bag a USD $100,000 bounty by Intel, inviting researchers to sniff out vulnerabilities from its processors. This discovery, chronicled under CVE-2018-3693, is among 12 new CVEs Intel will publish later this week. The company is also expected to announce quarterly CPU microcode updates to allay fears of its enterprise customers.

The new vulnerability, like most other "Spectre" variants, targets the speculative execution engine of the processor, in a bounds-check bypass store attack. A malicious program already running on the affected machine can alter function pointers and return addresses in the speculative execution engine, thereby redirecting the flow of data out of protected memory address-spaces, making it visible to malware. This data could be anything, including cryptographic keys, passwords, and other sensitive information, according to "The Register." Intel chronicled this vulnerability in section 2.2.1 of its revised speculative execution side-channel attacks whitepaper. You can also catch a more detailed whitepaper from the researchers themselves.
Source: The Register
Add your own comment

73 Comments on New "Spectre" Variant Hits Intel CPUs, Company Promises Quarterly Microcode Updates

#26
R0H1T
cucker tarlsonWhy then would I buy a 6/8 core CPU if I don't want to run +4 core tasks ?
There's always the possibility that the next revision/iteration of CCX will have 6/8 native cores, without it how do you suppose they'll get to 48/64 EPYC cores? In fact it's virtually certain atm, hence the biggest threat in a gen to Intel will be coming as Zen2 or whatever it's called. Say buh-bye to inter CCX latency, though you'll probably have to buy an APU for that.
Posted on Reply
#27
trparky
cucker tarlsonWhy then would I buy a 6/8 core CPU if I don't want to run +4 core tasks ?
Huh? Why wouldn't you? Moar power! Moar bragging rights!
Posted on Reply
#28
cucker tarlson
R0H1TThere's always the possibility that the next revision/iteration of CCX will have 6/8 native cores, without it how do you suppose they'll get to 48/64 EPYC cores? In fact it's virtually certain atm, hence the biggest threat in a gen to Intel will be coming as Zen2 or whatever it's called. Say buh-bye to inter CCX latency, though you'll probably have to buy an APU for that.
The way they make those is disable 1/2 cores on the ccx, 4 core ryzens still have 2 ccx units.
Posted on Reply
#29
R0H1T
cucker tarlsonThe way they make those is disable 1/2 cores on the ccx, 4 core ryzens still have 2 ccx units.
Yes but I'm saying, presumably with the APU, that inter CCX latency could soon be a thing of the past with 6/8 core CCX come Zen2, so it isn't that big of a deal anymore.
Posted on Reply
#30
GlacierNine
cucker tarlsonThe way they make those is disable 1/2 cores on the ccx, 4 core ryzens still have 2 ccx units.
That isn't even slightly what he suggested, don't be obtuse.

What he said was it is possible that EACH CCX on subsequent Ryzen CPUs could easily have 6 or 8 cores, in which case all of those cores would have lower latency than Intel's current architecture does.

Now with that cleared up - the INTER-CCX latency on Ryzen is not an impediment in any practical terms. Yes, when communicating between core 5 and core 4, a Ryzen chip is a number of nanoseconds slower. However so is a higher corecount Intel CPU.

What you are trying to argue is that somehow AMDs use of 4 Core CCXs, two per die, is somehow crippling their performance.

That is an emphatically untrue statement. Benchmark after benchmark after benchmark proves just how fast Ryzen actually is. More to the point - in gaming benchmarks (Which are the ones where this might matter), its already been shown in every benchmark for the last year that AMD simply aren't that far behind Intel. If CCX design was the issue then AMD would not be as close as they are to Intel's single threaded IPC and they also would not be absolutely killing them in multithreaded workloads.

Once again, you are blowing a tiny, completely insignificant part of a much greater whole, well out of proportion in order to make a point that simply isn't backed up by the real world performance of these chips in real world tasks.
Posted on Reply
#31
eidairaman1
The Exiled Airman
MT66Glofo is claiming 5ghz-ish with their 7nm process so I don't see why the tsmc 7nm process should not enable 5ghz-ish for ryzen 3000. I think an overlooked aspect of what AMD has been using process node wise is that its a 14nm samsung node used by Glofo, as far as I know samsung only make mobile centric processors where power efficiency is a premium and clock speed tend to be in the 1ghz to maybe 3ghz range, I dont believe there is a high performance variant of a samsung node just low power, TSMC and Glofo both state they will have both a high performance and low power verison of their 7nm process. This is why I believe the ryzen clock speeds have been lacking but power efficiency has been pretty good. Either way in time it will be revealed.
I support AMD but what does this have to do with Intel? It's off topic.

Lets get back on please.

Now my deal is with these flaws is OUCH!
Posted on Reply
#32
TheGuruStud
lasWon't happen core vs core

I'd be very happy if Zen 2 reaches 4.5 GHz... The 1700 in my server can't even do 4 GHz stable
You bought a low binned part... And we all know the process target was 3 GHz for mobile. 4+ is quite a feat without huge power demands.
Posted on Reply
#33
Prima.Vera
rtwjunkieAt this rate, quarterly fixes should have us back to Northwood performance in no time. :rolleyes:
This. If this trend continues, my 3770K CPU will be much faster than the 8700K one, lol .
Posted on Reply
#34
Jism
Could people bench the i7 vs bulldozer again? I'm curious how far behind the vishera actually is now with all these patches and fixes that tamper performance one by one.
Posted on Reply
#35
Athlonite
Prima.VeraThis. If this trend continues, my 3770K CPU will be much faster than the 8700K one, lol .
Ah no it wont you'll get Cyrix 5x86 perf while the 8700K will be at Pentium MMX perf LOL
Posted on Reply
#36
Prima.Vera
AthloniteAh no it wont you'll get Cyrix 5x86 perf while the 8700K will be at Pentium MMX perf LOL
Well, I'm not silly enough to "patch" bost bios and Win10. Especially that nobody has access to my PC and I never go on shaddy sites. I prefer raw performance over 0.1% increase in Security Risk. Relax.
Posted on Reply
#37
RichF
GlacierNineYou don't hear about them because they're not actually AMD specific bugs - They're bugs in ASMedia products that Intel also uses extensively. AMD already patched them, it didn't require Zen 2, and the root of the vulnerability was ASMedia
That was one of the vulnerabilities.
GlacierNineThe only reason that they were ever phrased as being solely AMD-relevant was that the company that publicised them, was making an attempt to manipulate AMD stocks.
Ad hom against the messenger won't change the fact that those vulnerabilities existed nor is it a good idea to promote stifling the tech press. Keeping people in the dark about flaws in their products isn't good. It's particularly humorous for people to simultaneously argue that these flaws weren't a big deal and that it was really terrible for CTS to not give AMD executives and other insiders time to dump stock (as Intel's CEO apparently did during the Meltdown/Spectre Google-given period).
GlacierNineFortunately, most of the tech press spent their time talking about who the fuck CTS labs were, rather than focusing on the "flaws", such as they were.
That's a good idea, since it was clearly CTS that sold consumers products with security flaws.
Posted on Reply
#38
TheGuruStud
RichFThat was one of the vulnerabilities.


Ad hom against the messenger won't change the fact that those vulnerabilities existed nor is it a good idea to promote stifling the tech press. Keeping people in the dark about flaws in their products isn't good. It's particularly humorous for people to simultaneously argue that these flaws weren't a big deal and that it was really terrible for CTS to not give AMD executives and other insiders time to dump stock (as Intel's CEO apparently did during the Meltdown/Spectre Google-given period).


That's a good idea, since it was clearly CTS that sold consumers products with security flaws.
I found the guy on the new CTS labs payroll. You're terrible, ban yourself.
Posted on Reply
#39
nemesis.ie
@RichF IMO you are reading things into what @GlacierNine said, that he didn't say.

My reading of the comment was that the CTS's release was clearly biased (which it was), not defending AMD's actual issues (which appear to now be mitigated).
Posted on Reply
#40
cadaveca
My name is Dave
Love watching the blind lead the blind... and then argue about who sees less. Please continue.

This is but the tip of the iceberg of how these issues will affect users with current and older hardware for years to come. INtel isn't devoting resources like this (quarterly updates) for something that is a small problem. That's the real news here, and unfortunately for AMD fans, they will be just as problematic and anyone thinking that BIOS updates fix physical hardware flaws is hilarious.
Posted on Reply
#41
GlacierNine
RichFAd hom against the messenger won't change the fact that those vulnerabilities existed nor is it a good idea to promote stifling the tech press. Keeping people in the dark about flaws in their products isn't good. It's particularly humorous for people to simultaneously argue that these flaws weren't a big deal and that it was really terrible for CTS to not give AMD executives and other insiders time to dump stock (as Intel's CEO apparently did during the Meltdown/Spectre Google-given period).
You're displaying a massive non-understanding of why bugs are reported ahead of time to companies and whitepapers released later.

Firstly, it's not "Ad hom" to point out that a companies actions are intended to manipulate stock prices and are for personal benefit. CTS Labs are not a "Messenger" here as much as they are complicit in the actions of a saboteur (Viceroy Research).

Secondly, the reason vulnerabilities aren't released to the public immediately, and are instead given to the manufacturers to provide fixes for ahead of time, is to prevent flaws identified in research from being publicised and potentially exploited before a fix can be provided. It's a mechanism to keep consumers safe. If a fix isn't provided, the bugs are publicised anyway, in order to force complacent or lazy companies to address bugs that have been put into the public domain, rather than allowing them to rely on security-through-obscurity, which is an inherently unsafe practice.

Publishing results to the public immediately, without giving manufacturers time to provide patches or mitigations, makes everyone less safe, since it paints a target on specific products and software, with big red letters for any bad actor to read saying "This product has a vulnerability, can you find it before the vendor patches it?"

I mean, bear in mind here that the people whose practices you're criticising in terms of giving companies time to fix their bugs - those people are also known as "The computer security industry". The Spectre and Meltdown bugs were made public by Project Zero for example - who are part of Google.

Project Zero regularly publishes new research - Including research on NEW security measures implemented by OS vendors, chip makers and software developers, assessing the effectiveness of those measures. - googleprojectzero.blogspot.com/

Note that their blog contains many examples of bugs that were fixed before they became public knowledge, due to those practices. This keeps consumers safer and means we're not all constantly panicking about the security vulnerabilities researchers discover.
Posted on Reply
#42
nemesis.ie
cadaveca... and anyone thinking that BIOS updates fix physical hardware flaws is hilarious.
Not fix, but they certainly should help mitigate them. Of course if someone has physical access to the machine and can install their own BIOS/UEFI then the machine can be compromised/returned to a flawed state anyway - if someone has that kind of access and is ,malicious then you have other problems too. ;)
Posted on Reply
#43
cadaveca
My name is Dave
nemesis.ieNot fix, but they certainly should help mitigate them. Of course if someone has physical access to the machine and can install their own BIOS/UEFI then the machine can be compromised/returned to a flawed state anyway - if someone has that kind of access and is ,malicious then you have other problems too. ;)
you don't need physical access to update a BIOS. Yeah, these bugs are easier to use if you have physical access, but there are far more ways to gain control over a machine FIRST, and then use these exploits, than most want to admit.

And the fixes.. barely affect performance for most users. This whole thing seems vastly misunderstood. Oh well.
Posted on Reply
#44
nemesis.ie
Perhaps not, but it's certainly much easier to do with physical access.
Posted on Reply
#45
RichF
GlacierNineYou're displaying a massive non-understanding of why bugs are reported ahead of time to companies and whitepapers released later.

Firstly, it's not "Ad hom" to point out that a companies actions are intended to manipulate stock prices and are for personal benefit. CTS Labs are not a "Messenger" here as much as they are complicit in the actions of a saboteur (Viceroy Research).

Secondly, the reason vulnerabilities aren't released to the public immediately, and are instead given to the manufacturers to provide fixes for ahead of time, is to prevent flaws identified in research from being publicised and potentially exploited before a fix can be provided. It's a mechanism to keep consumers safe. If a fix isn't provided, the bugs are publicised anyway, in order to force complacent or lazy companies to address bugs that have been put into the public domain, rather than allowing them to rely on security-through-obscurity, which is an inherently unsafe practice.

Publishing results to the public immediately, without giving manufacturers time to provide patches or mitigations, makes everyone less safe, since it paints a target on specific products and software, with big red letters for any bad actor to read saying "This product has a vulnerability, can you find it before the vendor patches it?"

I mean, bear in mind here that the people whose practices you're criticising in terms of giving companies time to fix their bugs - those people are also known as "The computer security industry". The Spectre and Meltdown bugs were made public by Project Zero for example - who are part of Google.

Project Zero regularly publishes new research - Including research on NEW security measures implemented by OS vendors, chip makers and software developers, assessing the effectiveness of those measures. - googleprojectzero.blogspot.com/

Note that their blog contains many examples of bugs that were fixed before they became public knowledge, due to those practices. This keeps consumers safer and means we're not all constantly panicking about the security vulnerabilities researchers discover.
1) The period of time Google gave Intel is a long one. Some, such as myself, think it is too long.

2) Regardless of the benefits of muzzling the tech press by withholding information about existing/known vulnerabilities, there are real drawbacks.

3) CTS' motives concerning stocks? How about Intel's CEO selling a lot of shares with insider information, prior to the public exposure of Meltdown and Spectre? One of the real drawbacks of concealing from the public knowledge of the vulnerabilities that are known, and which exist in the products they are using at that very moment, is that insiders can make money with stocks. The stock issue is far less important to me than the security issue, the press freedom issue, and the consumer rights issue.

Consumers have the right to know about the defects in the products they have been sold. Not two weeks from now. Not a month from now. Not two years from now. Immediately.

The responsibility for any fallout from exploitation of those defects rests on the company that sold the consumers the defective products.

CTS pointed out a fact, which is that corporations that are given a lot of time to secretly work on mitigating defects use that time not purely for fixing and working around those defects via technology but also use that time for things like propaganda.

4) "Publishing results to the public immediately, without giving manufacturers time to provide patches or mitigations, makes everyone less safe" This is a common assertion but I have yet to see hard data to support it. "Withholding knowledge from people makes them less safe" is the counterargument.

5) "the people whose practices you're criticising in terms of giving companies time to fix their bugs - those people are also known as 'The computer security industry'". Specific companies like Google are not "The" industry. They are specific corporations with specific profit-seeking practices. They don't own the tech press either.

Google was caught hacking into iOS and OS X to install a payload of spyware. We had better hope that Google does not own the security industry nor the tech press.
Posted on Reply
#46
GlacierNine
RichFA heap of bullshit
1 - You can think that, but deadlines of several months are not in any way unusual, and since the vulnerabilities were quite severe and required a lot of work to fix, it's absolutely sensible to give companies a reasonable amount of time within which to work and release fixes. As shown in that link, if the fixes are not provided, the details are published anyway, and Intel weren't given special treatment over Microsoft, to whom that example link refers. (Project Zero's standard period is 90 days, the same as given to MS and Intel)

2 - Please, by all means, point to the drawbacks you are blindly asserting exist in relation to this process. The only one I can personally think of is that, if a company were intentionally avoiding releasing patches and thus went over the deadline before being forced to make a patch, then the exploit would be patched slightly later than it otherwise would have been. However, this argument doesn't stand up to scrutiny, as a vulnerability NOT disclosed to the wider public is at substantially less risk of being exploited, so the net effect on consumers only even *exists* if a bad actor has already discovered the same vulnerability independently and begun to exploit it. (In which case, the company is solely responsible for not patching an exploit that is being used "in the wild" as it were, in order to protect their users - they should be doing so regardless of any security disclosure.) In such instances, it is the company's fault if, having been informed of the vulnerability, they have not taken steps to patch it. Project Zero would not be accountable for the hubris of a company that did not heed clear warnings, and in instances where a bad actor is not actively exploiting a vulnerability, this practice allows the vulnerability to be patched in advance of any bad actor being given even the slightest clue that it exists.

That practice absolutely keeps users safer, as it often takes more time to fix a vulnerability, than it does to exploit it after being informed of it.

3 - This is simply whataboutery. If anything it simply bolsters my point - CTS had reason to believe that by publishing this information they could force a movement in the stock market - the same one they'd seen Intel's CEO profit from earlier. The mechanics of their short position were slightly different, but this was absolutely their intention. Sure, Intel's CEO did that, and it's wrong that he did so or was able to. But I don't recall ever arguing that he was in the right to do so? If my memory fails me then by all means, point to where I defended his actions re: stock trading.

The second half of this point is simply you attempting, once again, to state (without any evidence to support you) that the industry standard practice of privately disclosing vulnerabilities to be patched before making them public, is somehow inherently flawed. If you genuinely believe that, then once again, you are taking issue with an entire industry's standard practice - A practice CTS labs wilfully ignored despite claiming to have many years of experience, and then defended ignoring with the shamefully ignorant argument of "We didn't think it was possible to patch these vulnerabilities in the time allotted so we went public straight away" - As if somehow that argument doesn't INCREASE the amount of time a bad actor has to find out about and abuse the issues raised, ahead of a fix being provided.

4) This is a stupid argument to be making. This is not difficult - Vulnerabilities are typically easier and quicker to exploit than they are to fix. By not giving manufacturers a headstart on mitigation, you are giving bad actors an extended window within which to work to exploit the issues. On the other hand, a user cannot patch their OS or programs by themselves - if they had the knowledge they were running unsafe software, it wouldn't do them any practical good, because they cannot fix the problems themselves unless they are developers themselves, running OSS they are free to modify themselves, and even then, most wouldn't have the time or skill to fix these issues themselves. What you just provided isn't a counterargument - It's simply a contrary assertion, and one that is contradicted by the practices of the entire InfoSec industry, to boot.

5 - Actually, it is "The industry". All I had to do to find a heap of examples of this happening was search the term "discloses vulnerability".

That brought me to Symantec for example, who followed this practice when helping apple to patch undisclosed vulnerabilities in iOS 11 - www.eweek.com/security/symantec-discloses-apple-ios-trustjacking-risks-at-rsa-conference

Duo security even published a table of vendors who they informed and when they subsequently updated after being informed Note that this article was published on 27th Feb, but the companies in the table were mostly notified 24 Jan. - www.kb.cert.org/vuls/id/475445

Check Point Software Technologies disclosed a vulnerability to WhatsApp and Telegram on March 7th, both companies developed patches for the issue before it was made public on March 15th. The same article mentions that they disclosed, and whatsapp fixed, another security vulnerability in the same way in 2015. blog.checkpoint.com/2017/03/15/check-point-discloses-vulnerability-whatsapp-telegram/

In fact, one of the major criticisms of the NSA after it's tools were leaked online (leading to WannaCry for example), was that these bugs could have been patched BEFORE they were exploited, if the NSA hadn't attempted to hide the vulnerabilities and keep them secret, rather than informing vendors - thehill.com/policy/cybersecurity/333928-nsa-warned-microsoft-about-vulnerability-connected-to-wanna-cry-report
www.wired.com/story/eternalblue-leaked-nsa-spy-tool-hacked-world/
www.wired.com/2016/08/shadow-brokers-mess-happens-nsa-hoards-zero-days/




You can dress this up all you like - At the end of the day, this is established practice for a reason - The EternalBlue and Wannacry ransomware attacks show exactly what can happen if this practice is disregarded. CTS Labs should have known this if they were anywhere near as experienced or "benevolent" as you are attempting to make out. The fact they disregarded it is proof of either their incompetence, their malice, or their vested interest.
Posted on Reply
#47
RichF
"A heap of bullshit"

When you start a post with insult you don't incentivize the person you're allegedly responding to bother to read your post. Instead, you're just showing off for others. That's not discourse. It starts with the letter t.
Posted on Reply
#48
GlacierNine
RichF"A heap of bullshit"

When you start a post with insult you don't incentivize the person you're allegedly responding to bother to read your post. Instead, you're just showing off for others. That's not discourse. It starts with the letter t.
Congratulations, you caught that I don't mind being rude to you.

Fortunately, that doesn't affect the substance of my post in the slightest - Nor does it affect the content of the multitude of links I included to back up my own points, wherein nobody is being rude to you.

If you could kindly stay on topic instead of engaging in your own ad hominem attacks about my attitude, that'd be nice. It'd also be a damn sight less hypocritical of you, considering you're accusing me of ad hominem only to engage in it yourself.
Posted on Reply
#49
RichF
GlacierNineinstead of engaging in your own ad hominem attacks
Citation needed.
Posted on Reply
#50
GlacierNine
RichFCitation needed.
RichF"A heap of bullshit"

When you start a post with insult you don't incentivize the person you're allegedly responding to bother to read your post. Instead, you're just showing off for others. That's not discourse. It starts with the letter t.
There you go, attempting to discredit my argument by taking issue with the manner in which it was delivered rather than the points I actually made.

Now that you've got your citation for that, perhaps you could trouble yourself to go back and deal with the other citations I made, in the post you're now avoiding addressing?
Posted on Reply
Add your own comment
Dec 22nd, 2024 20:11 EST change timezone

New Forum Posts

Popular Reviews

Controversial News Posts