Intel CPUs Hit by NetCAT Security Vulnerability, AMD Not Impacted

[Markfw]

for the record i am not saying that there aren't any exploits, i am saying id like to see any credible proofs that intel skimped on said security because of profit issues which was mentioned.

So your saying with all the exploits left open Intel is Faster?
I highly don't think so, Ryzen has a strong performance point, and i don't think intel even left with the exploits would be that much faster if any at all.

So again, id like to see someone specifically write a technical article in regard to intel deliberately allowing said exploits to increase performance on there processors.

I doubt that such an article exists, but to me its plain, there are two ways to do what I mentioned in post 12, one is faster, but less secure. The other is more secure. Intel choose the faster one, AMD chose the more secure one. Those are facts. Why did Intel choose the faster less secure one ? logically to be faster. Got any other ideas ?

 

[aigomorla]

Im gonna play the black sheep and say it could be that intel didnt expect a back door like this to exist.
Honestly this is intel and enterprise, do you think they would honestly knowingly allow for such a thing to exist and impliment it regardless?
Its hands down open door to a major class action lawsuit.

Its like meltdown.
Its not known if anyone would of found out the expliot had it not been google that tackled the issue in every level possible.
Maybe someone did know and was exploiting it, but who knows.

Im honestly not fully supporting Intel, dont get me wrong, i have a TR2 machine also, im go after whats better and not by what color if you know what i mean.

But saying intel deliberately allowed said exploits in instructions knowingly, is going a bit overboard in paranoia.

 

[Markfw]

Are you being serious? The irony of you typing about bias is most likely lost on 99% of this board.

So you think I am AMD biased ? Even though I echo what virtually every review site says ? Most notably that the 9900k is the fastest gaming CPU by a few percent on most games. But does not come with a heatsik. Runs on a dead platform. and is far less better at mutithreaded apps than a 3900x.

Do you have a problem with that ? Care to back up your bias claim ?

 

[Markfw]

Im gonna play the black sheep and say it could be that intel didnt expect a back door like this to exist.
Honestly this is intel and enterprise, do you think they would honestly knowingly allow for such a thing to exist and impliment it regardless?
Its hands down open door to a major class action lawsuit.

Its like meltdown.
Its not known if anyone would of found out the expliot had it not been google that tackled the issue in every level possible.
Maybe someone did know and was exploiting it, but who knows.

Im honestly not fully supporting Intel, dont get me wrong, i have a TR2 machine also, im go after whats better and not by what color if you know what i mean.

But saying intel deliberately allowed said exploits in instructions knowingly, is going a bit overboard in paranoia.

Again, I say, its faste,r they chose it. Bad idea. I won't speculate on the rest, but I do know higher management in all companies (including the one I retired from) are clueless, and bake bad choices, sometimes knowingly for money. I would not even defend AMD if I could find a reason. But this latest 25 mhz thing is a joke.

 

[aigomorla]

But this latest 25 mhz thing is a joke.

trust me intel has done a lot worse...
*chilled liquid cooled Xeon* fiasco to me honestly was digging there own grave.
But i am still bias'd they knowing allowed said exploit for performance gains.

 

[bbhaag]

So you think I am AMD biased ? Even though I echo what virtually every review site says ? Most notably that the 9900k is the fastest gaming CPU by a few percent on most games. But does not come with a heatsik. Runs on a dead platform. and is far less better at mutithreaded apps than a 3900x.

Do you have a problem with that ? Care to back up your bias claim ?

No I don't. I learned my lesson back in 2017 when Esquared and Perknose put me in my place. You're right and I apologize if I insinuated that you have a bias toward any cpu manufacturer.

 

[DrMrLordX]

for the record i am not saying that there aren't any exploits, i am saying id like to see any credible proofs that intel skimped on said security because of profit issues which was mentioned.

Someone at Intel thought it was a good idea to let another computer on the network read and write directly to/from L3. That is a security nightmare. I hadn't even heard of DDIO, and now that I know about it, I'm shocked that it took this long for anyone to exploit it. There's almost no way to secure such a feature. It definitely improves cluster performance. But who in their right mind green-lit such a feature? That's crazy.

NetCAT - vusec

NetCAT shows that network-based cache side-channel attacks are a realistic threat. Cache attacks have been traditionally used to leak sensitive data on a local setting (e.g., from an attacker-controlled virtual machine to a victim virtual machine that share the CPU cache on a cloud platform)...

www.vusec.net

That's an in-depth review of the NetCAT vulnerability. It's actually quite clever how it works. It's possible that Intel could address the prime+probe element of the attack without forcing anyone to completely disable DDIO:

If the connecting user couldn't successfully evict anything from the RDMA server's L3, then prime+probe wouldn't work. You'd still have the attacker flooding the RDMA server's last-level cache with crap, though. That's not exactly desirable.

 

[Markfw]

" But who in their right mind green-lit such a feature? That's crazy. ". Exacly my point on all the security things I have seen Get data and cache it without checking security ? then trash it when they don't hav e access ? but the cat is already out of the bag ? The internet reviewer (not sure the name) said almost exactly that "why would anyone in their right mind allow this ?".

Answer, some idiot in upper management who is clueless technically.

 

[DrMrLordX]

Answer, some idiot in upper management who is clueless technically.

Possibly. We may never know. If it got them some procurement wins then it was probably worth it, at least in the short term.

 

[therealmongo]

I won't touch that with a 10 foot pole.

Well played, well played

for the record i am not saying that there aren't any exploits, i am saying id like to see any credible proofs that intel skimped on said security because of profit issues which was mentioned.

So your saying with all the exploits left open Intel is Faster?
I highly don't think so, Ryzen has a strong performance point, and i don't think intel even left with the exploits would be that much faster if any at all.

So again, id like to see someone specifically write a technical article in regard to intel deliberately allowing said exploits to increase performance on there processors.

I highly doubt any such 'proofs' will ever come to light.

Instead, as with most things we can only go by past history and 'character' of said entity,

together with the incessant drive of the 'more profits' society we currently reside in,

and as with others,

you can see why many people would garner that a key reason for these issues is the drive of getting something to the market that is better than its competitors as this would give said company a sunstantial advantage in the 'more profit' stakes.......

 

[moinmoin]

Its because more people business, servers, happen to use intel processors, that more people have access to them in hacking them to find exploits.
Its that simple.

Intel has repeatedly shown that they don't bother with permission checks in their caches, which enabled Meltdown and its can of endless worms, which is apparently the same school of engineering that brought us DDIO that enables unfettered outside access to the CPU caches, and so on.

The miserable implementation of the MMU in Core2 responsible of starting all of this was called out back in 2007, and many of the Spectre exploits affect Intel chips since from that time.

The whole point of DDIO is to allow CPUs in a cluster to write directly to another CPU's cache, even if the CPU isn't local to the machine. It certainly is a nice feature for large clusters, but . . .

The common use case is that the NIC has such access to enable what you describe, so that's what the proof of concept exploit is using.

But it's actually worse, DDIO essentially gives any device on the system the ability to directly mess with the CPUs cache. Which means with DDIO enabled driver bugs could allow access to the CPU cache, and with Intel and its insistence that no strong separation between kernel and user data is "as by design" such access will allow privilege escalation.

 

[DrMrLordX]

But it's actually worse, DDIO essentially gives any device on the system the ability to directly mess with the CPUs cache. Which means with DDIO enabled driver bugs could allow access to the CPU cache, and with Intel and its insistence that no strong separation between kernel and user data is "as by design" such access will allow privilege escalation.

I hadn't thought of that. Good thing only some Xeons feature DDIO. Imagine if all Intel CPUs supported it?

 

[nicalandia]

are you being serious?

Please dont pass FUD.
AMD's RnD team had less then 1/10 of the funding intel had.

Wow, I've never seen such Biased Moderator. I gave you Thumbs Up because there is no Thumbs Down option.


You cannot use a moderator's title against them on this board. This is the second warning for this on this thread. Read our rules.

AT Moderator ElFenix

 

[nicalandia]

So again, id like to see someone specifically write a technical article in regard to intel deliberately allowing said exploits to increase performance on there processors.

You don't have to, the fact that each patch for each vulnerability lower the CPU performance it's proof enough.

 

[nicalandia]

I also would like to point out that way back in 2005 Intel was warned about the security flaws of HyperThreading, Intel did not heed the warning , but AMD did and accordingly.

So Intel was negligent and AMD Diligent.

 

[jpiniero]

I still wonder if Spectre/Meltdown was an intentional US Gov backdoor.

 

[IEC]

id like to see an actual tech paper written about this or some form of real credible proof.

Its a number game larry, you have 10,000 people using the same product, your bound to find issues with it faster then a product which has 1000 users.
And in the IT world, Intel has that much more market share still to date.

This is why exploits are being found for intel processors, because it pays that much better to find exploits for them.

Soon i predict were going to start finding exploits for ARM, as we are starting to get there with that many ARM Devices handling and controlling sensitive information.

Spectre is here to stay: An analysis of side-channels and speculative execution

These attacks leak information through micro-architectural side-channels which we show are not mere bugs, but in fact lie at the foundation of optimization.

The majority of new and related bugs (such as the one in OP) affect Intel and not other chip makers. Sure, there is more Intel hardware out there to potentially exploit. But it's pretty clear that any fixes for their nth derivative of their Core architecture are simply bandaids that don't fix the underlying problem. They chose performance over security. That was the right decision at the time, but now they are paying for it. Without a fundamental redesign of the architecture, Core is simply unacceptable from a security perspective. Doesn't matter to gamers, but it does matter in a *lot* of industries.

 

[nicalandia]

For those of you that believed that AMD Lucked Out and Intel didn't see the Big Picture.

http://www.daemonology.net/papers/htt.pdf

Cache Missing for Fun and Profit by Colin Percival


"We demonstrate that this shared access to memory caches provides
not only an easily used high bandwidth covert channel between
threads, but also permits a malicious thread (operating, in
theory, with limited privileges) to monitor the execution of another
thread, allowing in many cases for theft of cryptographic keys.


Finally, we provide some suggestions to processor designers, operating
system vendors, and the authors of cryptographic software,
of how this attack could be mitigated or eliminated entirely."


"We further recommend that “x86” processors implementing HyperThreading
should use a bit in the processor feature flags register to indicate
whether the caches have been designed to close these covert and
side channels, in order that operating systems can determine whether
countermeasures are necessary"



AMD: AMD processors access the TLB and use the valid bit and the protection
attributes to decide whether to access the caches. If the protection check fails, AMD processors operate as if the
memory address is invalid and no data is accessed from either the cache or memory

https://www.amd.com/system/files/documents/security-whitepaper.pdf

Intel: Since Nehalem CPU uArch added a second level TLB to encrease performance but no checks and bounds.


In the research paper there is a "Proof Of Concept" exploit one can still use in current Intel CPUs...

 

[dmens]

" But who in their right mind green-lit such a feature? That's crazy. ". Exacly my point on all the security things I have seen Get data and cache it without checking security ? then trash it when they don't hav e access ? but the cat is already out of the bag ? The internet reviewer (not sure the name) said almost exactly that "why would anyone in their right mind allow this ?".

Because not passing around security attributes in the memory system logic saves die area. Duh.

Answer, some idiot in upper management who is clueless technically.

And in middle management too.

Here's the scary thing, this "feature" came out of Intel circa 2010-2012, before the massive brain drain of 2015 onwards that saw anyone with a shred of talent either leave or get laid off. Just imagine the garbage coming out of Intel in the coming years.

 

[darkswordsman17]

I doubt that such an article exists, but to me its plain, there are two ways to do what I mentioned in post 12, one is faster, but less secure. The other is more secure. Intel choose the faster one, AMD chose the more secure one. Those are facts. Why did Intel choose the faster less secure one ? logically to be faster. Got any other ideas ?

I think several of the papers that were about Meltdown/Spectre went into detail about why they would've tried speculative execution when it had such clear security issues when done improperly, and it all pointed explicitly to the performance uptick possible.

Im gonna play the black sheep and say it could be that intel didnt expect a back door like this to exist.
Honestly this is intel and enterprise, do you think they would honestly knowingly allow for such a thing to exist and impliment it regardless?
Its hands down open door to a major class action lawsuit.

Its like meltdown.
Its not known if anyone would of found out the expliot had it not been google that tackled the issue in every level possible.
Maybe someone did know and was exploiting it, but who knows.

Im honestly not fully supporting Intel, dont get me wrong, i have a TR2 machine also, im go after whats better and not by what color if you know what i mean.

But saying intel deliberately allowed said exploits in instructions knowingly, is going a bit overboard in paranoia.

No you're playing blind sheep.

Weird since they've been told about this repeatedly, I think from basically the moment they implemented a lot of it (I think there's even some evidence they were told about beforehand - when they sent out engineering samples for instance before final products). And some was inherently known (which is why AMD took the steps to not follow suit).

Yes I absolutely do. This is the same company that put out chips with known defects before (was it Pentium 3?). Same with the chipset issue with Sandy Bridge era. They absolutely knew about it, and figured it wouldn't be a big enough deal and didn't want to delay their launch so they just pushed it through. Same company that perpetrated multiple anti-competitive practices over the years.

Not with people like you defending them at every turn. I have zero clue how Intel hasn't had to write off several billion dollars worth of server hardware over any single instance of most of this stuff. But now we see what lack of competition brings. AMD wasn't yet in a position to swoop in so companies had no choice but to just implement the software fixes (that's if they didn't already have woefully lacking security protocols themselves, which many places do sadly), and it sure seems like Intel's been trying to claim AMD's stuff is vulnerable (I personally think there's a decent chance that the "security researchers" that tried trashing AMD a couple of years back likely were funneled information from Intel - which it should be noted, Intel was also vulnerable to that security issue yet it all focused on AMD; those two guys ended up on stage at some Israeli security conference - which considering the current corrupt administration there and Intel's history and strong ties to the Israeli government, leaves me extra suspicious although no one in the tech industry seems to want to touch that, but then when trusted sites like Anandtech stop even simple reporting on the existence of security issues while posting every PR fluff piece they can, I think its telling; to be fair, its not just Intel they've decided to start ignoring, with the recent security vulnerability issue that Apple had being another notable story that got not even a peep, not sure if their fiasco with CTS Labs has made them decide to eschew the topic altogether or what, but its not a good look that they can't even just write an article about it existing and then linking to other sources that are doing better coverage if they feel they can't offer that).

You're woefully ignorant on this stuff. It wasn't just Google (I think multiple academics were working on this stuff at least at the same time, and I believe a lot of the later ones came from other academics researching some of the earlier work) and for both Spectre and Meltdown there was some research and discussion about potential security related issues were written before they were even implemented. It wasn't like that type of attack was unknown, and multiple people had raised the security issue about it prior to it being proven to be possible. Intel seemed to figure that either the software would advance, or their processors would, or they'd be in a position to tell people affected to just deal with it, who knows. But sorry they can't really play dumb on this.

On 8 May 1995, a paper called "The Intel 80x86 Processor Architecture: Pitfalls for Secure Systems" published at the 1995 IEEE Symposium on Security and Privacy warned against a covert timing channel in the CPU cache and translation lookaside buffer (TLB).

In 2002 and 2003, Yukiyasu Tsunoo and colleagues from NEC showed how to attack MISTY and DES symmetric key ciphers, respectively. In 2005, Daniel Bernstein from the University of Illinois, Chicago reported an extraction of an OpenSSL AES key via a cache timing attack, and Colin Percival had a working attack on the OpenSSL RSA key using the Intel processor's cache. In 2013 Yuval Yarom and Katrina Falkner from the University of Adelaide showed how measuring the access time to data lets a nefarious application determine if the information was read from the cache or not. If it was read from the cache the access time would be very short, meaning the data read could contain the private key of encryption algorithms.
This technique was used to successfully attack GnuPG, AES and other cryptographic implementations.[15][16][17][18][19][20] In January 2017, Anders Fogh gave a presentation at the Ruhruniversität Bochum about automatically finding covert channels, especially on processors with a pipeline used by more than one processor core.[21]
Spectre proper was discovered independently by Jann Horn from Google's Project Zero and Paul Kocher in collaboration with Daniel Genkin, Mike Hamburg, Moritz Lipp and Yuval Yarom.[when?] Microsoft Vulnerability Research extended it to browsers' JavaScript JIT engines.[4][22] It was made public in conjunction with another vulnerability, Meltdown, on 3 January 2018, after the affected hardware vendors had already been made aware of the issue on 1 June 2017.[23] The vulnerability was called Spectre because it was "based on the root cause, speculative execution. As it is not easy to fix, it will haunt us for quite some time."[24]

Oh so this is the tech equivalent of you have (own? ) a black friend? Is that a serious argument that flies? Perhaps you're just trying to show how someone can choose to be deliberately willfully ignorant while pushing nonsensical plausible deniability arguments by doing the full routine yourself? But if I were this blatantly ignorant on a topic, I'd probably stop posting instead of continuing to do exactly what I claim I'm not.

Its not paranoia if it turns out to be true. This particular one has been repeatedly explained to you and yet here you are continuing to try and dismiss that it was outright intentional design move on Intel's part that enabled it.

Now perhaps they assumed (incredibly wrongly) that the software security would render it a non-issue or would compensate or that they were going to improve it which would fix it (but then due to management changes and other stuff never got around to it). I 100% guarantee you that Intel engineers knew about these issues. They likely were told to ignore them by management (the same management known for stuff like Contra Revenue where they figure due to their market position and past examples where they could partake in anti-competitive behavior and benefit massively from it while effectively diminishing their competition they can pay companies to try and get their market dominant position where the companies are then forced to just accept any issues that arise later from that, like for instance say massive security vulnerabilities).

 

[dmens]

I 100% guarantee you that Intel engineers knew about these issues. They likely were told to ignore them by management

Bingo. Intel is an extraordinarily politicized workplace. This issue would have been identified by software researchers whose management have no motive to call out the hardware architects since there is no political gain to be extracted from slamming a different org. Persistent engineers would be shut down by being told to "disagree and commit" and excluded from meetings, which is the currency of Intel career advancement.

Lastly, the arrogant Intel management just don't care about anything other than extracting maximum value from the fabs and they genuinely believe their customers would come crawling back to them regardless of whatever security flaws are exposed because of their manufacturing dominance, which might have been true in the past, but is certainly not the case in 2019.

 

[Glo.]

Im gonna play the black sheep and say it could be that intel didnt expect a back door like this to exist.
Honestly this is intel and enterprise, do you think they would honestly knowingly allow for such a thing to exist and impliment it regardless?
Its hands down open door to a major class action lawsuit.

That would assume that Intel hired bunch of complete imbecils, that had no bloody idea, what they were doing, when designing uArch's.

Are you willing to suggest that, to anybody?

 

[DrMrLordX]

I have zero clue how Intel hasn't had to write off several billion dollars worth of server hardware over any single instance of most of this stuff.

It's been a case of inertia. Nobody wants to replace their Skylake-SP gear with, you know, something else. AMD gave them competition with EPYC but Intel probably wound up profiting from these security exploits anyway by selling "bugfixed" Cascade Lake products that required less testing and validation before being put into production. And let's not even speak of ARM which has even higher hurdles to clear than AMD. It'll catch up to Intel eventually.

Lastly, the arrogant Intel management just don't care about anything other than extracting maximum value from the fabs and they genuinely believe their customers would come crawling back to them regardless of whatever security flaws are exposed because of their manufacturing dominance, which might have been true in the past, but is certainly not the case in 2019.

Thus far, it has worked for them. Rome is probably the tipping point.

 

[nicalandia]

I think several of the papers that were about Meltdown/Spectre went into detail about why they would've tried speculative execution when it had such clear security issues when done improperly, and it all pointed explicitly to the performance uptick possible.

Thanks for the info I was able to find a research about HT poor security: http://www.daemonology.net/papers/htt.pdf

Do you know if it's possible to disable AMD hardware mitigations(what makes them more secure than Intel in recent times) and unlock the potential performance that Intel has enjoy due to their neglect in security? I mean perhaps to test Intel and AMD in even terms as far as security with the least secure OS available

 

[Ajay]

I also would like to point out that way back in 2005 Intel was warned about the security flaws of HyperThreading, Intel did not heed the warning , but AMD did and accordingly.

So Intel was negligent and AMD Diligent.

Too be fair, AMD didn't have SMT (hyperthreading). So far, it seems, AMD has learned from Intel's errors. Be assured of this though - security flaws will be found in AMD processors over time. There is no such thing as bulletproof in the security world. It's not a matter of if, but a matter of when - sadly that's the world we live in.