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
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.
73 Comments on New "Spectre" Variant Hits Intel CPUs, Company Promises Quarterly Microcode Updates
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.
Lets get back on please.
Now my deal is with these flaws is OUCH!
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).
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.
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.
And the fixes.. barely affect performance for most users. This whole thing seems vastly misunderstood. Oh well.
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.
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.
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.
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.
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?