It would be the only fair test.
-
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
It would be the only fair test.
Caporegime
If you're looking for some magic gains Coffeelake vs Ryzen 3000 because you think the security mitigations are hampering Intel's "true?" performance you're going to be disappointed, the only thing affected is IO throughput like high speed storage, application performance is pretty much identical.
https://www.anandtech.com/show/1365...ith-spectre-and-meltdown-hardware-mitigations
Soldato
Zx128k won't listen. Intel bad.
I mean just look at all the millions of compromised computers hacked on a daily basis....oh wait.
Problem is a lot of the information needs interpreting to fully appreciate what it means in a given context and the advisories are often generic advice in a catch all manner but some posters aren't interested in the details only using the information in a crude way to sling mud at Intel. I'm not saying my interpretation is always correct but some posters don't seem to realise that I'm already working off of the information they are re-producing and what I'm saying isn't in conflict with it.
Personally I try to at least have some idea of the reasoning as otherwise that is how injustices are done.
As an aside also funny the filter some have - literally my first post in the thread said things like:
"I'd have serious reservations now about running VPSes, etc. on an Intel system patched or otherwise"
"Intel needs a complete architecture revamp"
Yet it is obvious some posters have convinced themselves I'm running damage control for Intel based off myopically only seeing certain parts of my later posts.
Straight out of the white paper: - The implications are worrisome. First, RIDL attacks can be implemented even from linear execution with no invalid page faults, eliminating the need for exception suppression mechanisms and enabling system wide attacks from arbitrary unprivileged code (including JavaScript in the browser).
Basically this affects everyone with an Intel processor.
We place RIDL in the context of state-of-the-art attacks and mitigation efforts. Our analysis shows that, unlike existing attacks, RIDL is ill-suited to practical mitigations in software and more fundamental mitigations are necessary moving forward.
Last edited:
Just because you (a hacker) can do this doesn't mean an attacker can indiscrimantly make use of it in a useful way though. Amongst other factors some areas will only ever be academic curiosities other times there will be far easier approaches and so on. Otherwise we'd have already seen massive malware impact from these side-channel vulnerabilities - that isn't intended to diminish how concerning they are as often they are powerful tools (albeit for no good) in the appropriate application.
Once you have managed to run untrusted code on a system there are much easier and effective payloads to deploy. A keylogger or some crypto ransomware is going to produce better results for the lazy hacker and work on a much wider range of machines.
Trying to deduce secrets from a side channel attack is only going to be worth the effort in a very targeted attack.
Trying to deduce secrets from a side channel attack is only going to be worth the effort in a very targeted attack.
I'm surprised in a way some of the recent Windows 10 security updates haven't had the same exposure - albeit the problems are now fixed if you have the latest updates and seemingly ahead of anyone exploiting them but there is a long long list of privilege elevation and remote code execution vulnerabilities patched with some recent Windows 10 security updates that are much easier for malware to make use of.
EDIT: Infact another two fairly serious ones since I last checked even: https://www.zdnet.com/article/micro...days-in-massive-september-2019-patch-tuesday/
EDIT2: Infact Windows 10 seems to be far more of a security hole than the CPU in your system :s such as https://news.sophos.com/en-us/2019/...-targets-remote-desktop-and-active-directory/
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/adv190013
To be fully protected, customers may also need to disable Hyper-Threading (also known as Simultaneous Multi Threading (SMT)). That would be the Intel customers.
So looking at your web link, we are looking for: https://www.zdnet.com/article/micro...days-in-massive-september-2019-patch-tuesday/
- CVE-2018-12126 - Microarchitectural Store Buffer Data Sampling (MSBDS)
- CVE-2018-12130 - Microarchitectural Fill Buffer Data Sampling (MFBDS)
- CVE-2018-12127 - Microarchitectural Load Port Data Sampling (MLPDS)
- CVE-2019-11091 - Microarchitectural Data Sampling Uncacheable Memory (MDSUM)
CVE-2018-12130 found 0 times.
CVE-2018-12127 found 0 times.
CVE-2019-11091 found 0 times.
Good job completely off topic. Operation smoke screen is in affect.
Last edited:
I posted about that back along - it is a catch all because for instance if people are running things like VPS then HT is a serious vulnerability in that context.
Further down that article:
"Some customers may have to disable Hyper-Threading (SMT) to fully address the risk from MDS vulnerabilities."
The people disabling HT will be doing so because if you have HT on you can steal secrets from any thread at 100% success but if you turn HT off then you can only steal from the same thread and it does not always works. This means that HT off greatly reduces the impact of the mds attack but cannot stop it completely. Straight from the white paper and posted above.
The point is, whilst side-channel attacks are a concern in some scenarios, there are much easier and likely attack vectors for the home user which affect all CPUs. But I guess that doesn’t fit your agenda.
Again though it is about context and understanding when that situation is and isn't applicable. On your average consumer desktop realistically that isn't much of a threat because it only comes into play once someone has hands on access to your system (side-channel attacks not being very useful for fire and forget malware that is typically targetted at consumer desktops) having somehow got code running on it and by that point all bets are off anyhow - while on servers or systems doing server like tasks where someone can be for instanced logged into a VPS where they have permissions to run executable files it is a massive threat because it easily gives them the ability to snoop outside of secure boundaries - an environment where people are far more likely to be invested in a targetted attack.
Yeah absolutely. For the average home user by the time (or before) a would be attacker has got to the point of making use of vulnerabilities in HT you have much more serious security concerns already. Obviously this is different in cases where the attacker has access to services running on the machine in some way where they more directly can access these vulnerabilities and use them to cross boundaries in a way that isn't applicable to the average consumer setup.
Again as stated in the white paper these attacks can be launched via the users internet browser. This means everyone is at risk and at threat. The only way to fix the issue, as intel stated, is to buy a CPU that is not affected. If I was a malware designer I would 100% use this to prevent the anti virus software from finding my software. https://www.trendmicro.com/vinfo/id...e-from-av-solutions-via-intel-s-sgx-enclaves/
https://www.bleepingcomputer.com/ne...fallout-attacks-impact-all-modern-intel-cpus/
All three attacks are feasible in real-life scenarios. An attacker running malicious code on a vulnerable machine, or pointing the victim to a webpage with malicious JavaScript can steal sensitive information on the system, like passwords and cryptographic keys.
VUSec shows in the sped-up video below how they obtained information from the /etc/shadow file - where a Linux machine keeps encrypted password, account or expiration values.
They were able to do this by continuously trying to authenticate via an SSH connection. For now, the entire process takes about 24 hours.
This is because small pieces of info are extracted each time an SSH connection initiates. The duration depends on the type of data targeted and in some cases it could take less than a minute to extract it.
In another demo video, the researchers show that they were able to use RIDL to leak recent kernel data.
After first reading 0 bytes from /proc/version, the team could leak the full contents of /proc/version, even if the data was never present in the userspace.
"If you disable hyperthreading and at the same time you use Intel’s proposed mitigation (that is, using the very instruction) the MDS vulnerabilities are mitigated on old Intel processors," VUSec's Pietro Frigo told BleepingComputer.
Last edited:
You are ignoring the nature of that can - side-channel attacks of this nature aren't particularly useful to the kind of fire and forget malware that targets consumer desktops. (These kind of attacks are a lot of feeling about in the dark until you have enough information to piece together a picture - so ideally you need to know quite a bit about the environment you are trying to exploit so as to be able to filter out "noise" - which makes them a lot less useful than other avenues against a typical desktop system which in this context is potentially a high "noise" environment).
These specific browser based exploits as talked about in the whitepaper are more about data snooping (hence the use of a feedback channel) rather than a dropper to plant malware on an infected system so not quite sure what you mean with the last bit.
You aren't really understanding what you are posting - I'm already posting an interpretation of that information (and other info). Nothing in it conflicts with what I'm saying. Note for instance the bit where they describe the process of feeling about in the dark until they have enough information to start piecing together enough information for a picture to emerge - not a very useful technique for the kind of malware that attacks a consumer desktop - but much more potent against a more static target like a server when you already have executable (not JavaScript) persistent inside or a service persistently responding outside.
Last edited:
You can steal passwords.
Fallout – Stealing Confidential Data from Store Buffers
This exploit attacks the buffers that a CPU uses every time it needs to store data for any purpose. Even worse, once the exploit is successfully implemented, it can be tasked to steal specific data instead of random data in the buffer. It specifically breaks through countermeasures designed to make this type of exploit harder to usefully execute by bypassing Kernel Address Space Layout Randomization (KASLR). This means that credentials, keys, and any information that you would need to escalate access to the machine are vulnerable.
The results of their experiment speak for themselves.
Experimental Setup.
We evaluate Fallout on two Intel machines, a Kaby Lake i7-7600U and a Coffee Lake R i9-9900K. Both machines run a fully up-dated Ubuntu 16.04 system, with all countermeasures in their default configuration. On both systems, we empirically test the possible locations on the kernel in its address space obtaining about 490 locations,implying about 9 bits of entropy.
Experimental Results.
We run the attack 1000 times each, on both the Kaby Lake and the Coffee Lake machines. Our attack can recover the kernel location with 100% accuracy on both machines, within about 0.27 seconds.
https://www.privateinternetaccess.c...over-introducing-ridl-zombieload-and-fallout/ & https://mdsattacks.com/files/fallout.pdf
ZombieLoad – Pulling Data from Store Buffers that Belongs to Other CPUs
In the proof-of-concept build used to demonstrate the vulnerability, ZombieLoad was used to pull AES-128 encryption keys from a server in less than 10 seconds.
Mitigation of Fallout:
Additional patches will have to come in the form of OS and microcode updates, but for now, the best mitigation is to disable SMT (aka HyperThreading) on all affected Intel CPUs.
If you have the ability to execute arbitrary untrusted code on the target machine. Doing this in a browser is not trivial. From the RIDL white paper:
Their JavaScript proof of concept is not running in a browser and uses a timer which has been disabled as part of browser mitigations.
Whilst it might in theory be possible to develop something, the effort required to do so would be disproportionate to the reward. In reality, malware in the wild is going to use much simpler O/S vulnerabilities which are more effective and apply to all CPUs.
There is a video on one of the website of them doing the attack via the browser as you well know and understand. You also well know and understand that having an Intel CPU means no security because software is just a band aid. It cant replace hardware being secure. Please stop wasting my time with your drivel.
If you are referring to the MDS one the video shows a simulated browser environment (under ideal circumstances) and uses a timer that in all updated mainstream browsers currently has mitigations against such an attack under the assumption that because people found substitutes for a high res timer in the first round of browser mitigations that another substitute will be found in future.
They also note there are other challenges currently in making the exploit work in updated mainstream browsers due to the fact you need to not only get in but also somehow set up a feedback channel to do anything useful which can't as things stand be done reliably (hence why they used a simulated environment).
It does represent the inherent insecurity of the current architecture (both hardware and software approach) but it doesn't represent something that is currently viable "in the wild" as is or hackers would already be mass using it.
They also note there are other challenges currently in making the exploit work in updated mainstream browsers due to the fact you need to not only get in but also somehow set up a feedback channel to do anything useful which can't as things stand be done reliably (hence why they used a simulated environment).
It does represent the inherent insecurity of the current architecture (both hardware and software approach) but it doesn't represent something that is currently viable "in the wild" as is or hackers would already be mass using it.