It seems Intel has been twisting the truth and bullying researchers again....

Intel’s security response team worked for the next eight months to verify the findings and develop a patch, scheduled to be released on May 14. Four days before the release, however, when the company provided the researchers with details of the fix, the researchers quickly realized that the patch didn’t address all of the vulnerabilities.

Intel’s engineers had overlooked some of the proof-of-concept exploits the researchers had provided. But the researchers said that even without seeing the exploits, Intel should have been able to uncover the additional vulnerabilities on their own.

The researchers said Intel had chosen an ineffective way to address its chip vulnerabilities. Rather than fix the core issue, which would possibly require redesigning the processor, it has patched each variant as it is discovered.

Source: The New York Times

Sounds like Intel is rather incompetent and care more about their reputation and market position than anything else.

lexluthermiesterThat is incorrect. Section4, the very first sentence reads as follows; "Following most side-channel attacks, we assume the attacker can execute unprivileged native code on the target machine"' This directly implies physical access by a logged in user. Additionally, in the paragraph "User-Space Leakage" it states that "In the cross-process user-space scenario, an unprivileged attacker leaks values loaded or stored by another concurrently running user-space application. We consider such a cross-process scenario most dangerous for end users. Many secrets are likely to be found in user-space applications such as browsers. The attacker is co-located with the victim on the same physical but a different logical CPU core, a common case for hyperthreading." Network users login using a different protocol than physical access users. The user-space parameters effect side-channel access adversely.

Such requirements need physical access in the initial stage of any attack, whether by fully executing the attack in physical presence or by starting the attack with physical presence and handing off to a remote user. Regardless of the following stages of any attack, the use of this vulnerability requires physical access to the machine being attacked.

What if someone were to have remote access in the sense that somehow login credentials were stolen and were subsequently used to attack the system via either SSH or via Remote Desktop?

Yes, I know... at that point you've got more problems than a processor exploit.

lexluthermiesterThat is incorrect. Section4, the very first sentence reads as follows; "Following most side-channel attacks, we assume the attacker can execute unprivileged native code on the target machine"' This directly implies physical access by a logged in user.

What leads you to believe that? What word in that sentence implies physical access? Native code just means machine code, and unpriviledged just means normal user level. This is literally anyone that can login and execute a program. Nothing about it requires them to be physically there.

trparkyWhat if someone were to have remote access in the sense that somehow login credentials were stolen and were subsequently used to attack the system via either SSH or via Remote Desktop?

Yes, I know... at that point you've got more problems than a processor exploit.

Bingo. And yes, you have larger issues at that point, but again, it's another tool for malware writers to use, and you should never give them more.

R-T-BWhat leads you to believe that? What word in that sentence implies physical access? Native code just means machine code, and unpriviledged just means normal user level. This is literally anyone that can login and execute a program. Nothing about it requires them to be physically there.

A detailed explanation would require pages. It is sufficient to say that the initial stages of such an attack must include a physical presence element to succeed. It can not be pulled off 100% remotely.

lexluthermiesterA detailed explanation would require pages. It is sufficient to say that the initial stages of such an attack must include a physical presence element to succeed. It can not be pulled off 100% remotely.

Oh, how I could poke holes in that theory! Have you ever heard of two types of exploits called Remote Code Execution and the oh so wonderful Privilege Escalation exploit? No one single type of exploit could be used to attack a system via these processor exploits but if an attacker were to somehow bundle the processor exploit into an exploit chain that follows these steps...

1. Sends a block of data to a program that then causes a buffer overflow that overwrites the program stack of an exploitable program.
2. The aforementioned exploit then takes advantage of a privilege escalation which essentially makes whatever malicious code run at a level that's higher than that of the host program.
3. Download additional malicious code and execute it.
4. ???
5. Profit!

This has happened multiple times in everyone's favorite punching bag of a web browser called Internet Explorer! Not a month goes by where we don't read in some security bulletin where there was an issue with memory handling and... well, you get the idea.

The whole idea is that you can, at least in theory, line up your exploits in a chain and despite the chain being made up of little pieces, they come together to do much more damage than if they were to be used individually.

trparkyThe whole idea is that you can, at least in theory, line up your exploits in a chain and despite the chain being made up of little pieces, they come together to do much more damage than if they were to be used individually.

Perhaps, but like Spectre and all of the other side-channel type attacks, remote execution is extremely difficult. So difficult that no proof of concept attack has yet been successful. It's as you stated, only theory. So until anyone has proof that it can actually be pulled off, remote attacks are not possible and thus require a physical presence component. This new vulnerability is fundamentally no different.

lexluthermiesterSo difficult that no proof of concept attack has yet been successful.

YET! I like how you used the word "yet" in what you said.

lexluthermiesterSo until anyone has proof that it can actually be pulled off, remote attacks are not possible and thus require a physical presence component.

Again, if history has shown us, it's possible. You just need to get all of your ducks in a row and deliver the attack just like how Internet Explorer has been attacked in the past.

Think about Google Chrome, people once said that Google Chrome has an impenetrable sandbox and that nothing can escape it. Yeah... we've seen how that has played out. All it takes is the right exploits put in a chain in the right order and then oh crap, the sandbox has been breached.

trparkyYET! I like how you used the word "yet" in what you said.

The possibility exists, thus "yet"...

trparkyAgain, if history has shown us, it's possible. You just need to get all of your ducks in a row and deliver the attack just like how Internet Explorer has been attacked in the past.

In most other situations, I would agree. However the particulars of these vulnerabilities are known and that knowledge shows the extreme difficulty of remote attack. It is so ridiculously difficult that it is effectively impossible at this time, which is why no proof of concept attempt at remote attack has been successful. Physical attacks is been pulled off but at considerable difficulty. The conditions literally have to be perfect.

trparkyThink about Google Chrome, people once said that Google Chrome has an impenetrable sandbox and that nothing can escape it.

That is a browser, a piece of software. And only fools bought into the idea you suggest. However, the vulnerabilities we're discussing are hardware based and are an entirely different beast. Exploiting them is a very different task altogether.

lexluthermiesterA detailed explanation would require pages. It is sufficient to say that the initial stages of such an attack must include a physical presence element to succeed. It can not be pulled off 100% remotely.

Uh... no. Not if you have an account with say, RDP rights. If you can execute native code you can do it, it doesn't matter how you got there. Physical access is simply not a requirement.

lexluthermiesterPerhaps, but like Spectre and all of the other side-channel type attacks, remote execution is extremely difficult. So difficult that no proof of concept attack has yet been successful. It's as you stated, only theory. So until anyone has proof that it can actually be pulled off, remote attacks are not possible and thus require a physical presence component. This new vulnerability is fundamentally no different.

I could do it to you today with an unmitigated system with user level rights. I'd be admin in less than a day.

lexluthermiesterA detailed explanation would require pages.

No, I don't think so. The concepts are simple enough.

Remember, security consulting is literally my day job here.

R-T-BI could do it to you today with an unmitigated system with user level rights. I'd be admin in less than a day.

Sorry, can't accept that without evidence. No one has been able to do it without physical access, at least no one is showing proof of such.

lexluthermiesterSorry, can't accept that without evidence. No one has been able to do it without physical access, at least no one is showing proof of such.

I mean, they literally state that in the whitepaper and even provide tool POC's for it.

You'd need an existing ability to execute native code on the system. If you have rdp or even telnet rights, you have that. This is why it's important to trust your users... even with the mitigations.

Frankly, the only claim without evidence is yours. The very sentence of the whitepaper you cite contradicts your claim.

R-T-BI mean, they literally state that in the whitepaper and even provide tool POC's for it.

Showing how it's done is not the same as actually doing it. And as that has not been done...

R-T-BIf you have rdp or even telnet rights, you have that.

Rarely implemented on systems that would be viable targets of such attack attempts.

R-T-BI could do it to you today with an unmitigated system with user level rights. I'd be admin in less than a day.

What is the minimum level of access you need for this?

I watched zombieland 2, and although it was enjoyable, I think the first movie was best. :rolleyes:

lexluthermiesterRarely implemented on systems that would be viable targets of such attack attempts.

Often implemented on cloud providers, and regardless, completely irrelevant to your claim that physical access is a hard requirement.

londisteWhat is the minimum level of access you need for this?

Remote desktop or command line. Basically, write access to a directory and ability to spawn a process.

Could theoretically be done with less, but never done it personally.

Mind you, this isn't just theory in my case. I have done this for a client in the past to restore admin rights to a bad-admin firing situation on a cloud server. Gotta love meltdown unmitigated servers.

R-T-BMind you, this isn't just theory in my case. I have done this for a client in the past to restore admin rights to a bad-admin firing situation on a cloud server. Gotta love meltdown unmitigated servers.

If you can provide a link to a successful attack demonstration, I'd be happy to read it.

lexluthermiesterIf you can provide a link to a successful attack demonstration, I'd be happy to read it.

You have the whitepaper documenting the methods. I really can't help you beyond that, it's not as though I can provide a link for you to click that will instaprove I did this.

It is more complex than a point and click attack though. These attacks really only leak data you'd not otherwise know. On it's own, that won't escalate privildges, but there are plenty of other exploits to chain with that that will.

At the end, it needs human involvement. If that's what you mean by physical access, 100% agree.

I still don't understand how anyone but a bad actor physically tampering with the CPU and then installing it on a target server could exploit this bug. You have to have access to the microcode which means you are not writing garden variety software that you can run at the OS level.

R-T-BYou have the whitepaper documenting the methods.

Documenting a theorized situation and actual practical implementation are two very different things.

R-T-BI really can't help you beyond that, it's not as though I can provide a link for you to click that will instaprove I did this.

And I have no desire to imply you are being less than truthful. However, your attempt was clearly with the approval and involvement of the owner/administrator of the target system, very likely present at the target system itself, or at the very least logged on opening the door for you to render exploitation.

R-T-BIt is more complex than a point and click attack though. These attacks really only leak data you'd not otherwise know. On it's own, that won't escalate privileges, but there are plenty of other exploits to chain with that that will.

Of course.

R-T-BAt the end, it needs human involvement. If that's what you mean by physical access, 100% agree.

I've spent time over the past few days to further research how this and the other side-channel type vulnerabilities can be exploited and a few things have been made very clear;
1. No known attack(successful or otherwise, proof of concept or otherwise) has been documented thus far.
2. While in theory a remote attack is possible, circumstances have to be so very perfect(or be made so) as to be virtually impossible without human input at the target system.
3. Given the difficulty involved, attacks most certainly will require a degree of physical presence at the target system.
4. While the average user is unlikely to have the high levels of security measures implemented that one would find on a business/enterprise system, average users generally do not use the entry points required to render an attack, thus making them effectively protected anyway.
5. Average users, even those targeted by criminal investigations, do not have information valuable enough to justify the difficulty involved in a remote attack attempt(though in practical terms, physical access would be far easier to achieve, assuming such access would be lawful).
6. Rendering attack against power users, such as many of us here at TPU who take personal security very seriously, would make any attempt so extremely unlikely that success is effectively impossible.
7. Attempts will be noticed. An attacker will get 2, maybe 3, attempts before the actions taken to effect such attack will be noticed.

While technically possible, remote exploitation of these types of vulnerabilities is so, ironically, remote as to be effectively impossible without some level of human presence at the target system.

What about Ice Lake?

er557Welcom to tpu, @Neverdie , and nice nick, it represents a goal of mine...

Thanks! :)

I believe TSX was disabled later on, at least on some of the Haswell SKUs.

ThubanI believe TSX was disabled later on, at least on some of the Haswell SKUs.

My 4790K only had TSX enabled for a few months after purchase then a microcode update disabled the feature.

lexluthermiesterNo known attack(successful or otherwise, proof of concept or otherwise) has been documented thus far.

Uh... you saw the github examples, right?

I think this is the original one, might be a repost:

github.com/IAIK/ZombieLoad

R-T-BUh... you saw the github examples, right?

I think this is the original one, might be a repost:

github.com/IAIK/ZombieLoad

I did. That POC page prescribes that the attack code to be compiled and run from the local target system, remote attack is not implemented.