Yet another Intel CPU security vulnerability!

IT Troll · 18 Sep 2019 at 12:22

I don't think anyone in this thread is denying how RIDL leverages and benefits from HT. But the debate is under what circumstances that would that actually be a factor and when you might want to disable HT. In the datacentre you may want to disable HT now, as a precaution, if you have multi-tenant systems where arbitrary code could be run. Just in case an exploit is ever developed.

However, on a typical desktop PC, malware wouldn't need to employ such a complex method. If an attacker has manged to execute code they would deploy a much simpler payload which would apply to a wide range of systems. At which point it wouldn't matter if HT was on or off. It is not only a case of how complex this type of exploit is to weaponise, it is how effective and successful it would be in this scenario. In the burglary analogy, this is like the burglar putting on a blindfold and tying his hands behind his back once they are inside your house. How they got into the house is a separate matter.

If the researchers had managed to make the vulnerability work within a modern browser, on a common home operating system then there would be more cause for concern. As it stands, this and other side-channel vulnerabilities are very low on the long list of things that home users should be concerned about. Claiming that home users have to disable HT now (at a much exaggerated performance loss) because they can be attacked whilst browsing is very misleading and points to some other agenda.

chrcoluk · 18 Sep 2019 at 12:29

Excellent post IT-troll

In reality risks can be made almost zero just by the following really.

common sense
default block for javascript
default block for xhr
SRP/applocker to restrict executables to non writable locations only on windows OS

essentially the issue with all these theoretical exploits is the system has to be already under some degree of control by the attacker, if they already have that control then you have bigger problems and likely other avenues of the job been finished.

RavenXXX2 · 18 Sep 2019 at 13:41

chrcoluk said:
Excellent post IT-troll

In reality risks can be made almost zero just by the following really.

common sense
default block for javascript
default block for xhr
SRP/applocker to restrict executables to non writable locations only on windows OS
Buy an AMD CPU.

Fixed.

Rroff · 18 Sep 2019 at 13:50

zx128k said:
They cover all that on page 6 B. Synchronization. They can use Serialization, Contention and Eviction. They cover each method, what matters really is they are able to pull it off. You can just read it yourself. The commands they list.

That isn't what I mean there is a whole lot more needed to support using those commands which they don't talk about. The actual crucial bits that make the difference in terms of actually putting it into practice - like with the passwd example like I said where they don't mention the bits needed to make it work that don't represent something viable in a real environment.

chrcoluk said:
essentially the issue with all these theoretical exploits is the system has to be already under some degree of control by the attacker, if they already have that control then you have bigger problems and likely other avenues of the job been finished.

Something which is a bit frustrating with the RIDL whitepaper most of the time where they say something like "it was a bit difficult" they then gloss over that they had to do something which was enabled by already having some degree of control or behind the scenes knowledge of the system to make it work. The easy one to point out being the passwd example which they must have setup the environment without common mitigations against multple login attempts for it to work but the same apply in different forms to the other examples.

zx128k · 18 Sep 2019 at 14:05

Rroff said:
That isn't what I mean there is a whole lot more needed to support using those commands which they don't talk about. The actual crucial bits that make the difference in terms of actually putting it into practice - like with the passwd example like I said where they don't mention the bits needed to make it work that don't represent something viable in a real environment.

https://mdsattacks.com/slides/slides.html slide 29.

chrcoluk · 18 Sep 2019 at 14:10

Rroff said:
That isn't what I mean there is a whole lot more needed to support using those commands which they don't talk about. The actual crucial bits that make the difference in terms of actually putting it into practice - like with the passwd example like I said where they don't mention the bits needed to make it work that don't represent something viable in a real environment.

Something which is a bit frustrating with the RIDL whitepaper most of the time where they say something like "it was a bit difficult" they then gloss over that they had to do something which was enabled by already having some degree of control or behind the scenes knowledge of the system to make it work. The easy one to point out being the passwd example which they must have setup the environment without common mitigations against multple login attempts for it to work but the same apply in different forms to the other examples.

its probably like the 0 day malware tests that get done on youtube where the person has deliberately disabled UAC, and is double clicking payload's on the desktop to test them.

Rroff · 18 Sep 2019 at 14:25

zx128k said:
https://mdsattacks.com/slides/slides.html slide 29.

It is just a few block diagrams - it doesn't explain what they actually did and that for instance they had to target a process they'd crafted in a way to make it feasible and was possible because of their knowledge of it. Ask yourself why they demonstrated it using the core JS engine skipping normal browser interaction against a specially crafted process on the same system instead of demonstrating it as a remote intrusion through the browser into privileged browser data or against an already running process such as OS security routines, etc.

chrcoluk said:
its probably like the 0 day malware tests that get done on youtube where the person has deliberately disabled UAC, and is double clicking payload's on the desktop to test them.

It is kind of like that in terms of getting their proof of concepts to work but unlike that with these exploits there are a variety of situations where they are more or less viable - some of these exploits can be relatively easily leveraged inside a virtual machine for instance where you are much less limited in terms of targetting specific memory locations, feedback channel to see what you are actually snooping on, etc.

zx128k · 19 Sep 2019 at 02:21

Rroff said:
It is just a few block diagrams - it doesn't explain what they actually did and that for instance they had to target a process they'd crafted in a way to make it feasible and was possible because of their knowledge of it. Ask yourself why they demonstrated it using the core JS engine skipping normal browser interaction against a specially crafted process on the same system instead of demonstrating it as a remote intrusion through the browser into privileged browser data or against an already running process such as OS security routines, etc.

It is kind of like that in terms of getting their proof of concepts to work but unlike that with these exploits there are a variety of situations where they are more or less viable - some of these exploits can be relatively easily leveraged inside a virtual machine for instance where you are much less limited in terms of targetting specific memory locations, feedback channel to see what you are actually snooping on, etc.

You have to read the white paper, I can follow what they are doing. You don't have to understand every little detail, be a complete expert or know programming.

RIDL leaking root password hash
https://youtu.be/JXPebaGY8RA

ZombieLoad in action: leaking the root hash from /etc/shadow
https://youtu.be/rKncAFAShkQ

RIDL from JavaScript
https://youtu.be/KAgoDQmod1Y

RIDL leaking Linux kernel data
https://youtu.be/UV9GDcOWeeI

This is How Hackers Crack Passwords!
https://www.youtube.com/watch?v=YiRPt4vrSSw

So basically normally you get at most three attempts at login. By getting the hash of the password, you can attack the login without getting locked out or the victim knowing. Also you get infinite retries to get the password right. Normal PC users, normally use weak passwords. Remember the argument this is too hard to do?

Code from gitHub that everyone can download to test the attacks.

ZombieLoad
https://github.com/IAIK/ZombieLoad

RIDL
https://github.com/vusec/ridl

Spectre, Meltdown, Foreshadow, Fallout, RIDL, ZombieLoad vulnerability/mitigation checker for Linux & BSD
https://github.com/speed47/spectre-meltdown-checker

What can be done?
https://youtu.be/Oeb-O4yKK2c?t=157

Rroff · 19 Sep 2019 at 02:30

zx128k said:
RIDL leaking root password hash
https://www.youtube.com/watch?v=JXPebaGY8RA

This is How Hackers Crack Passwords!
https://www.youtube.com/watch?v=YiRPt4vrSSw

What is your point?

Rroff · 19 Sep 2019 at 02:44

zx128k said:
So basically normally you get at most three attempts at login. By getting the hash of the password, you can attack the login without getting locked out or the victim knowing. Also you get infinite retries to get the password right. Normal PC users, normally use weak passwords. Remember the argument this is too hard to do?

You are mixing up several different things to make a point which isn't correct - if you have something able to utilise Zombieload i.e. via a VM/VPS then that is something I've been cautioning against throughout the thread and if you have the hash and manage to match it back to a password you don't need to use the RIDL attack against passwd. The RIDL attack against passwd is an interesting concept but won't work due to things like fail2ban which would be utilised in a real world environment. None of that is applicable to the desktop environment you are just trying to put as much noise into the post to make it seem like it can.

zx128k · 19 Sep 2019 at 03:07

Rroff said:
You are mixing up several different things to make a point which isn't correct - if you have something able to utilise Zombieload i.e. via a VM/VPS then that is something I've been cautioning against throughout the thread and if you have the hash and manage to match it back to a password you don't need to use the RIDL attack against passwd. The RIDL attack against passwd is an interesting concept but won't work due to things like fail2ban which would be utilised in a real world environment. None of that is applicable to the desktop environment you are just trying to put as much noise into the post to make it seem like it can.

Zombieload does not work its patched, see the last video. RIDL cannot be patched, you have to turn off HT. It also works on newer Intel CPU's. I also don't mix up anything and the point is clear and correct. I also posted the information about how you can sync victim and attacker. Remember as this is hardware related with RIDL there is no software method to stop it, you have no choice but to turn off HT.

I have answered all your questions as best I can. The rest is up to you.

Rroff · 19 Sep 2019 at 03:15

zx128k said:
Zombieload does not work its patched, see the last video. RIDL cannot be patched, you have to turn off HT. It also works on newer Intel CPU's. I also don't mix up anything and the point is clear and correct. I also posted the information about how you can sync victim and attacker. Remember as this is hardware related with RIDL there is no software method to stop it, you have no choice but to turn off HT.

I have answered all your questions as best I can. The rest is up to you.

Well no you tried to conflate the way Zombieload can be used to get a password hash (when it already had a step in the door security wise) with the RIDL passwd attack and then tried to confuse the two to claim you'd get infinite attempts - which isn't true. You are drawing a lot of false equivalents or throwing likely sounding bites in there - being hardware related doesn't somehow magically override the fact you can't endlessly bash a protected passwd or SSH connection in a properly setup environment without invoking effective software counter-measures.

Besides which that is applicable to a server like environment or a Linux desktop where the attacker is already inside in some way - it doesn't apply to a general purpose desktop especially not Windows and if an attacker is already inside a Windows system they won't have to worry about trying to exploit things like passwd.

Your constantly circling back to

zx128k said:
you have no choice but to turn off HT.

with more and more convoluted attempts to confuse the security situation tends to indicate this is more about justifying your own CPU purchasing decisions in some way rather than a genuine interest in understanding the security situation.

EDIT: I only mentioned the passwd example as it is an easy example to show that there is more to understanding the application of these attacks than is mentioned in the whitepapers, etc. the same goes for all the examples and variants but some require extensive explanations of programming techniques and low level CPU/OS functionality which goes way beyond a post here. As I've always said disabling HT in a server type environment is a lot more critical.

zx128k · 19 Sep 2019 at 04:03

Rroff said:
Well no you tried to conflate the way Zombieload can be used to get a password hash (when it already had a step in the door security wise) with the RIDL passwd attack and then tried to confuse the two to claim you'd get infinite attempts - which isn't true. You are drawing a lot of false equivalents or throwing likely sounding bites in there - being hardware related doesn't somehow magically override the fact you can't endlessly bash a protected passwd or SSH connection in a properly setup environment without invoking effective software counter-measures.

Besides which that is applicable to a server like environment or a Linux desktop where the attacker is already inside in some way - it doesn't apply to a general purpose desktop especially not Windows and if an attacker is already inside a Windows system they won't have to worry about trying to exploit things like passwd.

Your constantly circling back to with more and more convoluted attempts to confuse the security situation tends to indicate this is more about justifying your own CPU purchasing decisions in some way rather than a genuine interest in understanding the security situation.

EDIT: I only mentioned the passwd example as it is an easy example to show that there is more to understanding the application of these attacks than is mentioned in the whitepapers, etc. the same goes for all the examples and variants but some require extensive explanations of programming techniques and low level CPU/OS functionality which goes way beyond a post here. As I've always said disabling HT in a server type environment is a lot more critical.

This is just ad hominem. Play with your own straw man.

Rroff · 19 Sep 2019 at 04:23

zx128k said:
This is just ad hominem. Play with your own straw man.

Well you have done a lot of hand waving to try and make snippets from different examples seem like they are saying something they don't and it leaves me wondering why.

For example you tried to portray the reverse engineering of a hash from a situation where you already have the hash and get infinite attempts because you would be doing that locally on your own system (or via some kind of data crunching setup) as being relevant to the RIDL attack which relies on repeatedly trying invalid credentials to leak the contents of etc/shadow where normally a properly configured environment will prevent endless attempts with invalid credentials and then tried to hand wave past that by saying it is a hardware thing and can't be prevented by software but RIDL can't prevent a software sentinel from detecting multiple invalid connection attempts and blacklisting the connection from future attempts as the hardware weakness is about its ability to snoop across boundaries not directly influence the operation of a system and then tried to use that to attack a completely separate argument about it being too hard to do which was related to a different environment.

zx128k · 19 Sep 2019 at 04:25

Rroff said:
Well you have done a lot of hand waving to try and make snippets from different examples seem like they are saying something they don't and it leaves me wondering why.

For example you tried to portray the reverse engineering of a hash from a situation where you already have the hash and get infinite attempts because you would be doing that locally on your own system (or via some kind of data crunching setup) as being relevant to the RIDL attack which relies on repeatedly trying invalid credentials to leak the contents of etc/shadow where normally a properly configured environment will prevent endless attempts with invalid credentials and then tried to hand wave past that by saying it is a hardware thing and can't be prevented by software but RIDL can't prevent a software sentinel from detecting multiple invalid connection attempts and blacklisting the connection from future attempts as the hardware weakness is about its ability to snoop across boundaries not directly influence the operation of a system and then tried to use that to attack a completely separate argument about it being too hard to do which was related to a different environment.

Another straw man.....

Rroff · 19 Sep 2019 at 04:28

zx128k said:
Another straw man.....

So the RIDL attack against passwd would have infinite chances on a properly configured system?

zx128k · 19 Sep 2019 at 05:24

Rroff said:
So the RIDL attack against passwd would have infinite chances on a properly configured system?

That's not whats implied. The hash is what the computer uses to check the password you enter. When you steal the hash, you can try endlessly to get the password. This attack to break the hash, can also take place on another computer, like a super computer for example. A quantum computer would complete this type of attack very quickly. So losing the hash of the password is a massive security breach. That's what RIDL does in the example video, it steals the root password hash when it should not be able to access the hash file. The computer does not store the password, just the hash of the password because people know that if a security hole like this happens. Then encrypting the password will still offer some protection.

One type on attack on the hash is called brute force attack, basically you just make attempts endlessly to find the password that matches the hash. If you tried doing a brute force attack at the login prompt, then you would have 3 or less guesses before a timed lockout happened. The the password hash you can try endlessly and if the password is weak. Then you will get into the target system very quickly. Home systems have weak passwords. The list of the most common passwords is here.

https://edition.cnn.com/2019/04/22/uk/most-common-passwords-scli-gbr-intl/index.html

The top 10 most common passwords were:

123456
123456789
qwerty
password
111111
12345678
abc123
1234567
password1
12345

These passwords will be broken in seconds, giving access to the victims computer.

Rroff · 19 Sep 2019 at 05:48

zx128k said:
That's not whats implied. The hash is what the computer uses to check the password you enter. When you steal the hash, you can try endlessly to get the password. This attack to break the hash, can also take place on another computer, like a super computer for example. A quantum computer would complete this type of attack very quickly. So losing the hash of the password is a massive security breach. That's what RIDL does in the example video, it steals the root password hash when it should not be able to access the hash file. The computer does not store the password, just the hash of the password because people know that if a security hole like this happens. Then encrypting the password will still offer some protection.

One type on attack on the hash is called brute force attack, basically you just make attempts endlessly to find the password that matches the hash.

You have things very mixed up.

Let me explain what the RIDL attack against passwd does - by attempting to authenticate with passwd it forces passwd to leak some of its backend file that stores account details into a buffer (LFB) that the RIDL attack can intercept passively but because it can't synchronize with that happening or precisely match the data format it does this over and over slowly piecing the details together by filtering for data that matches a known pattern which would fit with the stored account details. To achieve this it constantly invokes passwd with invalid credentials many many times repeatedly until after about 24 hours it has done it enough times it has all the data to filter out the valid hash from the rest of the noise. The problem here is and omitted from the whitepaper that on a properly configured system repeatedly invoking passwd or the other suggested route via SSH with invalid credentials will quickly get shutdown by systems designed to prevent brute force hacks and RIDL can do nothing to stop that happening - if it could (a) it would already have control over the system (b) synchronization wouldn't be an issue in the first place. While technically you could just wait on 3rd party login attempts which would dodge triggering a lockout you'd have no idea when they happened making the synchronization issue even worse and the rate of normal logins is so low it would take decades rather than 24 hours. The point being to make the proof of concept work requires something that doesn't represent a realworld scenario and more crucially to my point these are factors omitted from the whitepaper that are important to understanding the limits of application to each of these examples and the same is true of all the variants only the passwd one is a bit easier to explain.

And this is why their JavaScript attack for instance was done using just the JS engine core, on the same system against a specially crafted victim process because similarly limitations exist that they've omitted from the whitepaper that stand in the way of a realworld scenario and why they didn't demonstrate it as an intrusion through a real browser against arbitrary privileged information.

So talk of infinite attempts to break the hash is irrelevant here as you simply don't have infinite attempts to get the hash in the first place using the RIDL example they posted in a realworld scenario.

EDIT: That isn't to be dismissive of the fact that some approaches of using RIDL or similar side-channel attacks can be very powerful for an attacker who already has one foot in the door such as could be the case with a server type environment where being able to break out of a VM/VPS would be very useful.

zx128k · 19 Sep 2019 at 07:40

Rroff said:
You have things very mixed up.

Let me explain what the RIDL attack against passwd does - by attempting to authenticate with passwd it forces passwd to leak some of its backend file that stores account details into a buffer (LFB) that the RIDL attack can intercept passively but because it can't synchronize with that happening or precisely match the data format it does this over and over slowly piecing the details together by filtering for data that matches a known pattern which would fit with the stored account details. To achieve this it constantly invokes passwd with invalid credentials many many times repeatedly until after about 24 hours it has done it enough times it has all the data to filter out the valid hash from the rest of the noise. The problem here is and omitted from the whitepaper that on a properly configured system repeatedly invoking passwd or the other suggested route via SSH with invalid credentials will quickly get shutdown by systems designed to prevent brute force hacks and RIDL can do nothing to stop that happening - if it could (a) it would already have control over the system (b) synchronization wouldn't be an issue in the first place. While technically you could just wait on 3rd party login attempts which would dodge triggering a lockout you'd have no idea when they happened making the synchronization issue even worse and the rate of normal logins is so low it would take decades rather than 24 hours. The point being to make the proof of concept work requires something that doesn't represent a realworld scenario and more crucially to my point these are factors omitted from the whitepaper that are important to understanding the limits of application to each of these examples and the same is true of all the variants only the passwd one is a bit easier to explain.

And this is why their JavaScript attack for instance was done using just the JS engine core, on the same system against a specially crafted victim process because similarly limitations exist that they've omitted from the whitepaper that stand in the way of a realworld scenario and why they didn't demonstrate it as an intrusion through a real browser against arbitrary privileged information.

So talk of infinite attempts to break the hash is irrelevant here as you simply don't have infinite attempts to get the hash in the first place using the RIDL example they posted in a realworld scenario.

EDIT: That isn't to be dismissive of the fact that some approaches of using RIDL or similar side-channel attacks can be very powerful for an attacker who already has one foot in the door such as could be the case with a server type environment where being able to break out of a VM/VPS would be very useful.

Give your straw man a break, the guy is dying. The RIDL does not steal the password, just the hash. It takes 24 hours as per the video I posted about. The filter part is in the slide I posted above.

You did not read the synchronize section.

The attack shown using EIDL to break security by allowing you to access information that uses the sudo command. When a user.

The video shows the command cat /etc/shadow
reply cat: /etc/shadow: Permission denied
sudo cat /etc/shadow | head -n 1
sudo is superuser so returns the file contents
./hackpasswd root:
runs the attack and steals the information from sudo cat /etc/shadow | head -n 1

sudo (/ˈsuːduː/ or /ˈsuːdoʊ/) is a program for Unix-like computer operating systems that allows users to run programs with the security privileges of another user, by default the superuser.

So when he runs the attack without superuser privileges, the attack works and steals the the secret. We leaks the content of the /etc/shadow file by repeatedly trying to authenticate a user with the passwd utility.

A similar attack can leak the /etc/shadow of a cloud co-tenant by repeatedly opening an SSH connection. I avoided it for a reason but that to is proof of concept, i.e RIDL leaking data that should not be leaked. That's all it is meant to be and security does not work the way you seem to think. The fact is with time you can steal anything.

It really has to be said at this point, with security you plug the hole and you don't wonder for a second how people use the hole. Stating well people might not be able to use it, I don't care and I don't think its realistic. So I will troll some random guy, is both asinine and proof you are no security expert.

The meme destroyed in this thread,

The first rule of cyber security: "Be Paranoid"

Paranoia Reigns Among Security Pros
https://www.lastline.com/blog/security-paranoia-reigns-among-security-pros/

Given you did not view the video I posted, you attacked your own straw man.

IT Troll · 19 Sep 2019 at 11:25

Another late night guys!

Did someone really complain about "muddying the waters" then proceed to do exactly that. Posting a whole wall of text on tangential subjects. :rolleyes:

When viewed in isolation, the videos are impressive and make it all look very easy. But let's not lose sight of what environment is required to execute the RIDL password attack. Taken from slide 26 of the researchers presentation which was posted previously:

1. Victim has VM in the cloud (so hardly a typical home user then)
2. We get on a VM on the same server
3. We make sure it is co-located
4. Victim VM runs an SSH server

Steps 2 & 3 are not trivial. Back to the burglary analogy, this is the burglar moving into the same apartment block as you and managing to get an apartment immediately next to yours, with only a thin wall between them. At which point then can attempt to "RIDL" limited items through a small hole in the party wall.

Copying and pasting the same information, ad nauseum, does not change the fact that this doesn't really apply to home users. No matter what font size you choose to shout in.