If you need clarification on the nature of the attacks and their scope. I would advise contacting to authors of the white papers as they may help you for free.
-
Competitor rules
Please remember that any mention of competitors, hinting at competitors or offering to provide details of competitors will result in an account suspension. The full rules can be found under the 'Terms and Rules' link in the bottom right corner of your screen. Just don't mention competitors in any way, shape or form and you'll be OK.
Yet another Intel CPU security vulnerability!
- Thread starter Selekt0r
- Start date
If you need clarification on the nature of the attacks and their scope. I would advise contacting to authors of the white papers as they may help you for free.
It isn't my opinion it is backed up in the whitepapers that have been linked to in black and white if you have even a fundamental understanding of malware and security.
There is no clarification needed they mention in the whitepaper limitations such as the availability of the appropriate timers and feedback channel, etc.
Simple ad hominem.
Simple ad hominem. Everything I am posting is from their website and the while papers. How can you be using the white papers if you think I am wrong when I am cutting and pasting from them.
I have given examples where you've demonstrated your hands on experience of the subject is lacking - that isn't simple ad homnem.
Just copy and pasting information doesn't mean you are right - as I've shown you don't really understand what you are copy and pasting and just pulling snippets that seem like they fit at face value.
Did you read past the introduction paragraph to page 10 and the actual detail of the research? The people who discovered the vulnerability explain why they couldn’t make it work in a browser. That is the research I present to you. Are you saying that part of their research is wrong?
Its the nature of the security whole. It's not like you can run javascript in a VM.
Run some JavaScript code in a "virtual machine":
https://www.w3schools.com/nodejs/ref_vm.asp
Then the attack allows you to break out of the VM and steal secrets. From the website,
As shown in the RIDL paper, an attacker can exploit hardware security vulnerabilities inside the processor to break VM and SGX boundaries. So if you can create and run java code in a VM?
From the white paper,
This primitive by itself is useful in sandbox (e.g., JavaScript) escape scenarios
In particular, by snooping on in-flight data in the CPU, attackers running arbitrary unprivileged code (including JavaScript in the browser) may leak information across arbitrary security boundaries
we presenta number of practical exploits that leak data across many common security boundaries (JavaScript sandbox, process,kernel, VM, SGX, etc.)
we assume the attacker can only run unprivilegedcode on the victim system (e.g., JavaScript sandbox, userprocess, VM, or SGX enclave), but seeks to leak informa-tion across arbitrary privilege levels and address spaces.
as we will show, can also be implemented in managed languages such as JavaScript.
Not to mention that such attacks canbe built even from a sandboxed environment such asJavaScript in the browser
This bypasses side-channel mitigations deployedon all the major operating systems and extends the threatsurface of prior cross-address space speculative executionattacks to managed sandboxes (e.g., JavaScript).
G. JavaScript attacksTo further demonstrate the implications of RIDL, weshow that RIDL can be exploited even within restricted sandboxed environments such as JavaScript
Building a RIDL attack from the browser requires ahigh level of control over the instructions executed by theJavaScript engine. Conveniently,WebAssemblyallows usto generate code which meets these requirements and isavailable as a standard feature in modern browsers. Wefound that we can use WebAssembly in both Firefox andChrome to generate machine code which we can use toperform RIDL-based attacks.
Generating the correct machine code and triggeringthe page fault are relatively straightforward.
Despite these challenges, we successfully implementeda proof-of-concept exploit on top of Firefox’ SpiderMonkeyJavaScript engine to reliably leak data from a victimprocess running on the same system.
So you are wrong, what a surprise. That's you discredited.
Last edited:
No that is you simply not understanding what you've copy and pasted - you are mixing up different bits of information some relevant to a desktop environment, some relevant to a server environment, other bits unique to a web-browser and presenting them as if they all apply the same across all scenarios, when they don't.
You also clearly don't understand the difference between proof of concept and something viable as malware - if what you were claiming was true we'd be seeing mass hacking and mass data collection on a level we simply aren't (and mitigations would be rushing into play).
That's you de-credited as well, this is very easy.
The only person discredited here is you. Copy and pasting information from a whitepaper you clearly don't understand and are struggling with the basic concepts doesn't mean anything.
When quoting you seem to have missed some important parts from that section.
“high-resolution timers have been disabled as part of browser mitigations against side-channel attacks”
“For simplicity, our exploit uses an old-style built-in high-resolution timer in SpiderMonkey to measure cache evictions”
“we do not currently have a reliable RIDL exploit running inside unmodified Chrome”
“high-resolution timers have been disabled as part of browser mitigations against side-channel attacks”
“For simplicity, our exploit uses an old-style built-in high-resolution timer in SpiderMonkey to measure cache evictions”
“we do not currently have a reliable RIDL exploit running inside unmodified Chrome”
Deleted member 651465
D
Deleted member 651465
If I have to delete any more bickering, there will be thread bans handed out. Please feel free to debate a subject by all means, but calling "harassment" because someone disagrees with your viewpoint is childish.
At the same time, if you continue to push a point and it is clear that the other person isn't going to accept your view then you may be best agreeing to disagree and using the ignore feature.
At the same time, if you continue to push a point and it is clear that the other person isn't going to accept your view then you may be best agreeing to disagree and using the ignore feature.
Thanks to EVH for cleaning up the childish posts.
Whilst these research vulnerabilities are technically interesting and make for great headlines, people need to remember that we are yet to see a single example of them being weaponised and used in the wild. Spectre was one of the first of these headline grabbing vulnerabilities and 18 months on, the only “malware” which has been detected is the original example code (detecting these cache attacks is simple for AV software).
The latest NetCAT research uses timers to deduce human keystrokes during an SSH session. This is ingenious but difficult to turn into a real world attack. The researcher himself says, “NetCAT is a complex attack and is likely not the low-hanging fruit for the attackers”. If you want to steal someone’s password a much simpler and more effective approach is to simply ask them for it...
If you are running server infrastructure which could theoretically be susceptible to these attacks then you absolutely need to be taking action. After all, the security of your user’s data is your responsibility. But the average home user should instead be concerned about more fundamental O/S and browser vulnerabilities than any of this side-channel stuff. Claiming a home user is going to be attacked whilst casually browsing the web is simply untrue and just alarmist scaremongering - no such malware exists.
Whilst these research vulnerabilities are technically interesting and make for great headlines, people need to remember that we are yet to see a single example of them being weaponised and used in the wild. Spectre was one of the first of these headline grabbing vulnerabilities and 18 months on, the only “malware” which has been detected is the original example code (detecting these cache attacks is simple for AV software).
The latest NetCAT research uses timers to deduce human keystrokes during an SSH session. This is ingenious but difficult to turn into a real world attack. The researcher himself says, “NetCAT is a complex attack and is likely not the low-hanging fruit for the attackers”. If you want to steal someone’s password a much simpler and more effective approach is to simply ask them for it...
If you are running server infrastructure which could theoretically be susceptible to these attacks then you absolutely need to be taking action. After all, the security of your user’s data is your responsibility. But the average home user should instead be concerned about more fundamental O/S and browser vulnerabilities than any of this side-channel stuff. Claiming a home user is going to be attacked whilst casually browsing the web is simply untrue and just alarmist scaremongering - no such malware exists.
Caporegime
People have their data stolen from their computers on a daily basis, my guess is you would argue none of that is via Intel's security holes, how do you know?
Also, you do realise it comes down to who to trust, you or the experts, what do you think the experts motives are for "scaremongering" ?
I don't think the researchers are scaremongering, they are very clear what is and isn't possible with the vulnerabilities they have discovered. It is some of the tabloid journalism and causal reader interpretations which can run rather wild.
Caporegime
As is usual from all journalists, i agree its undoubtedly blown out of proportion by them however i don't see anything in the source documents that makes any exceptions to the vulnerabilities of domestic users.
You have to turn off HT and not use JavaScript in your browser. Then hope for the best. Security in Intel CPU's are dead and even Intel states you have to replace the CPU. If you leave HT on, you have to accept the fact you will never be safe. It's 100% clear in the white papers, you are not safe with HT on. There is no way to fix it, its a hardware issue. Only a new CPU without the hardware issues can fix it. Patches are just band aids, there is no guarantee that the security holes will not be used in another way or more will not be found.
The older Intel CPU's are hit the hardest when HT is turned off. Current ones don't CPU bottleneck the graphics card and hit fps hard. This will become an issue as the 9900k ages and every man and his dog has access to developed tools to use the security holes. There is example code available at the moment to develop from and test the new attacks.
"That’s where the good news ends, as BitDefender notes that a general fix is “impossible,” as the issue derives from a hardware design flaw. To conclusively protect against this attack, customers would have to replace their Intel silicon with a redesigned chip."
https://thenextweb.com/security/201...rifying-security-vulnerability-in-intel-cpus/
Google has pushed out a Chrome OS update (version 74) with a quick fix for the new MDS vulnerabilities that can let a bad actor read privileged portions of memory. That's the good news; the bad is that to make sure any exploits can't affect Chrome users, Hyper-Threading is now disabled by default.
Because this flaw exists in the actual CPU hardware and not in the software, the best way to secure your Chromebook is to disable Hyper-Threading. This changes how the processor schedules its jobs and the fill and store buffer in the CPU cache won't be able to be read by outside software.
https://www.androidcentral.com/mds-vulnerability-chrome-os
Should you enable Hyper-Threading?
Probably not.
If you have to ask ...
This is a classic case of "if you have to ask, the answer is no." If you're unsure of what Hyper-Threading is or why Google disabled it to mitigate a side-channel data vulnerability, then you should leave things alone and trust the pros. You might notice some slow down in your normal work, but unless you're really pushing things with Linux applications or running heavy web apps, you'll be fine.
The older Intel CPU's are hit the hardest when HT is turned off. Current ones don't CPU bottleneck the graphics card and hit fps hard. This will become an issue as the 9900k ages and every man and his dog has access to developed tools to use the security holes. There is example code available at the moment to develop from and test the new attacks.
"That’s where the good news ends, as BitDefender notes that a general fix is “impossible,” as the issue derives from a hardware design flaw. To conclusively protect against this attack, customers would have to replace their Intel silicon with a redesigned chip."
https://thenextweb.com/security/201...rifying-security-vulnerability-in-intel-cpus/
Google has pushed out a Chrome OS update (version 74) with a quick fix for the new MDS vulnerabilities that can let a bad actor read privileged portions of memory. That's the good news; the bad is that to make sure any exploits can't affect Chrome users, Hyper-Threading is now disabled by default.
Because this flaw exists in the actual CPU hardware and not in the software, the best way to secure your Chromebook is to disable Hyper-Threading. This changes how the processor schedules its jobs and the fill and store buffer in the CPU cache won't be able to be read by outside software.
https://www.androidcentral.com/mds-vulnerability-chrome-os
Should you enable Hyper-Threading?
Probably not.
If you have to ask ...
This is a classic case of "if you have to ask, the answer is no." If you're unsure of what Hyper-Threading is or why Google disabled it to mitigate a side-channel data vulnerability, then you should leave things alone and trust the pros. You might notice some slow down in your normal work, but unless you're really pushing things with Linux applications or running heavy web apps, you'll be fine.
Last edited:
Yeah take this one for instance:
It seems particularly nasty to the layperson and in many ways is quite ingenious - however normally an SSHd such as one of their potential suggested targets for such an attack would be configured with mitigations against brute force attacks - usually slowing down any one client connection after a small number of invalid logins and blacklisting them after a few more requiring a would be attacker to utilise a huge botnet to stand a chance. Entry points like passwd would normally be protected in a properly setup environment by things like fail2ban (which obviously haven't been implemented in their test environment).
So while MDS attacks for instance shows how these attacks "can" work what they don't include is a full commentary on what is needed for them to work in the real world - most of their proof of concepts being idealised circumstances with for instance everything else cleared out except the target process so they can easily find traces of it within the inner workings of the CPU without having prohibitive amounts of "noise" as you would in a real environment and so on.
The same applies in one form or another for all the other examples - which means that as things stand the threat from these vectors to the average home user is largely non-existent though concerning while in specific cases in server type environments a significant concern. Which is why for the most part we are highly unlikely to see the example code put to practical use as widespread malware though may see some application in targetted attacks against infrastructure or individual businesses.
Last edited:
We don't fully know the extent of Intels **** up, but we do know is Intel arn't addressing the problem. Luckily we have advise from experts on how to best mitigate the problems with Intel systems but his mess will roll on for decades, it isn't a trivial problem. As someone mentioned it requires various levels of security or extra security to address what Intels hardware fails to do with hardware.
Goes back to what I said awhile back in the thread - if this concerns people enough they are taking steps like disabling HT then they really should consider moving away from an Intel platform.
Disabling HT realistically does zero for the average consumer as no attack that hasn't already penetrated your system can utilise the vulnerabilities there today and who knows what might happen tomorrow if someone does find a viable way to use these attacks then they might even find a way to trick the CPU/manipulate BIOS into re-enabling some or all HT functionality any way and as Intel said disabling HT doesn't alone provide protection against MDS if such an attack does penetrate your system.
Last edited: