Do you disable hyperthreading? (poll)

[moproblems99]

While that is true, a web browser can not be configured to run in such a way that would make it a gateway to take advantage of these types of vulnerabilities and become an attack vector.

While we are at it, this is also wrong.

ecause some of us understand how these problems work

Clearly you don't.

anywhere near easy

Anywhere easy and near impossible are completely different.

Please keep in mind, there is still no known exploits

It could take years to find them, and years more for it to be released.

 

[Aquinus]

While we are at it, this is also wrong.



Clearly you don't.



Anywhere easy and near impossible are completely different.



It could take years to find them, and years more for it to be released.

I don't recall seeing a JavaScript PoC for this and @lexluthermiester has a point. The feasibility of exploiting this isn't even worth the effort. How the hell do you think you know what the buffers contain data for every time there is a context switch to your application? You don't even know what the PC was at the time of the context switch so you can't even derive where the program was in its execution (assuming you're even privy to the assembled code itself.)

I would go so far to say that, unless the stars align, it's impossible to exploit MDS in a meaningful way. You would need to already have intimate knowledge about what's running and how it runs and even then there is no guarantee you'll be successful either. This isn't Meltdown.

 

[moproblems99]

I don't recall seeing a JavaScript PoC for this and @lexluthermiester has a point. The feasibility of exploiting this isn't even worth the effort. How the hell do you think you know what the buffers contain data for every time there is a context switch to your application? You don't even know what the PC was at the time of the context switch so you can't even derive where the program was in its executing (assuming you're even privy to the assembled code itself.)

I would go so far to say that, unless the stars align, it's impossible to exploit MDS in a meaningful way. You would need to already have intimate knowledge about what's running and how it runs and even then there is no guarantee you'll be successful either. This isn't Meltdown.

For the last time. I didn't advocate to turn off HT. My very first post says so. All I said was I was disputing that you need physical access. Root is perfectly attainable remotely. Never was I questioning the feasibility. Never was I advocating to disable HT. Is that clear? Do I need to repeat it?

What I did misread was lex saying using the browser for THIS attack. I did misread that. However, javascript timing 'attacks' are used to map the memory system to help with these class of attacks.

Edit: Here, this is even where I said not to disable it. And practically no one needs to worry about these: https://www.techpowerup.com/forums/threads/do-you-disable-hyperthreading-poll.255674/post-4050041

 

[R-T-B]

I don't recall seeing a JavaScript PoC for this and @lexluthermiester has a point.

There is one. I'll see if I can't find it. Hold on.

EDIT: Wow, ignore me. You can take me at my word that it is possible, but the security group that has this POC is a closed group and I do not presently have permission to share. As such, be a good skeptic and ignore me until I can ascertain whether or not this is sharable code.

I can say in my limited research of this Javascript is far less useful than I pictured (claimed via users anyhow, low throughput apparently). You'd have to sit at an infected page for some time for this POC code I see to do anything useful. But still.

 

[windwhirl]

Nope, HT will remain enabled. Updates, firmware revisions and the like will be installed as they become available, though (I've never stopped them even when they seemed to bork things for everybody else and I won't stop them now).

First, I think it is unlikely that I'll get targeted by any kind of malware taking advantage of such vulnerabilities and that they'll succeed.

Second, I do apply some security best practices even at home.

And third, these vulnerabilities seem rather hard to exploit, even in unlikely favorable conditions, so I'm not gonna bother beyond installing updates and enabling mitigations.

 

[R-T-B]

The best advice I have for people worried about this exploit is to visit trusted sites and close untrusted ones (hey look a porn popup lol let's click it! How about no grandpa?) quickly. Basically same old advice will work well for now.

 

[moproblems99]

Side Channel attacks can happen with JS. MDS, maybe not but side-channel is side-channel.

There is one. I'll see if I can't find it. Hold on.

EDIT: Wow, ignore me. You can take me at my word that it is possible, but the security group that has this POC is a closed group and I do not presently have permission to share. As such, be a good skeptic and ignore me until I can ascertain whether or not this is sharable code.

I can say in my limited research of this Javascript is far less useful than I pictured (claimed via users anyhow, low throughput apparently). You'd have to sit at an infected page for some time for this POC code I see to do anything useful. But still.

Not MDS. But a start:

https://www.reddit.com/r/javascript/comments/7ob6a2

More:

https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html

 

[R-T-B]

Not MDS. But a start:

https://www.reddit.com/r/javascript/comments/7ob6a2

Yeah, one I have is on a pastebin posted to an old yahoo group (the irony of a security group on yahoo groups never escapes me but this time they did something useful) so that's not the same code. As I said were it not a private group with a rights disclaimer I'd share right away. But it's likely similar: Javascript reduces speed to the point of it being far less useful. That's really my takeaway.

Spectre I'd exepect to have been exploited via Javascript by now if it were useful, I think. It must not be.

 

[moproblems99]

MDS appears to be able to use JS too. Is it only theoretically possible viz JS? I don't know. Don't really care. At least I provided some links.

The vulnerabilities can be exploited using malware planted on the targeted devices, but some of them can also be exploited remotely from the internet via JavaScript code and malicious websites.

https://www.securityweek.com/new-class-data-leaking-vulnerabilities-impact-intel-cpus

Yeah, one I have is on a pastebin posted to an old yahoo group (the irony of a security group on yahoo groups never escapes me but this time they did something useful) so that's not the same code. As I said were it not a private group with a rights disclaimer I'd share right away. But it's likely similar: Javascript reduces speed to the point of it being far less useful. That's really my takeaway.

Spectre I'd exepect to have been exploited via Javascript by now if it were useful, I think. It must not be.

JS can be more powerful than people give it credit for. It will be a scourge of the internet. Scourge is a little strong but you get the idea...

 

[R-T-B]

Yep, the code I have supposedly exploits MDS. But it's over my head to the point they could be using Spectre and just full of BS. I'm not a javascript guy, nor a security expert at the level of these vulnerabilities. I just know MDS isn't a speculative vulnerability as much as a strange way of attacking buffers inbetween processors used for processs-sync, or something similar. Still learning.

Random thought: I wonder if MDS affects nonspeculative atom chips? A few of them even had hyperthreading.

Netbook users everywhere can have even more power siphoned from their poor poor netbooks, if so.

JS can be more powerful than people give it credit for. It will be a scourge of the internet. Scourge is a little strong but you get the idea...

I do not disagree at all. I hate it with a passion. But, present exploits via it do appear limited in throughput. I think. I admit it's not my area of expertise and I am relying on comments from users of the code you linked and two comments on mine (largely a insignifigant sample really).

At least I provided some links.

I know. I'm working on that. I should've just shut up but I get excited talking about security for some reason. I'm strange.

EDIT: OK i have permission to post the code. Some corrections: It is psuedocode not javascript. I am told doing this in java script would be "fucking trivial." Cool language man, feels me with respect.

/* Flush flush & reload buffer entries. */
for (k=0; k<256; ++k)
flush(buffer+k*1024);

/* Speculatively load the secret. */
charvalue=*(new_page);
/* Calculate the corresponding entry. */
char*entry_ptr=buffer+(1024*value);
/* Load that entry into the cache. */
*(entry_ptr);

/* Time the reload of each buffer entry to see which entry is now cached. */
for(k=0; k<256;++k) {
t0=cycles();
*(buffer+1024*k);
dt=cycles()-t0;

if(dt<100)
++results[k];
}

Frankly, I have no idea what this is or how to use it. But I'm not an expert of this level. Frankly I'm not even sure they are.

I personally would just reference this statement from the RIDL docs posted by the authors of the vulnerability:

Building a RIDL attack from the browser requires a high level of control over the instructions executed by the JavaScript 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. Furthermore, all the majorbrowsers try to reduce the memory footprint of the We-bAssembly heap by relying on demand paging [60], whichwe can use to perform an attack along the lines of the one previously presented in Listing1. That is, we can rely on the validpage fault generated by our memory access totrigger an exception and spill the in-flightdata.

PDFs format weird. See:

https://mdsattacks.com/files/ridl.pdf

 

[Aquinus]

Frankly, I have no idea what this is or how to use it. But I'm not an expert of this level. Frankly I'm not even sure they are.

This is sort of the point I'm trying to make. Even if you do manage to leak a couple bits with Spectre v1, how to you intend to figure out what application that memory belong to and what it actually is? Also, how do you rectify issues with memory possibly changing between the times you can leak a bit or two? Afterall, you can't get more than 700 bits per second which is god awful slow. By the time you get the next bit, data may have moved, changed, or might not even exist anymore.

I'm not saying that these "vulnerabilities" can't be exposed, I just see no feasible way to actually use them to do anything beyond showing that it can be done. Also, you're example is in C, not JS.

I am told doing this in java script would be "fucking trivial."

Tell your buddy to make a real piece of software that actually does something with the data from the exploit, I'll wait. Just because we have PoCs doesn't mean it's useful.

 

[er557]

The last thing I'll ever do why i still draw breath, is ever disable hyperthreading

 

[John Naylor]

I have completly ignored all these "vulnerabilities". Until I see a story about a user expereincing an actual problem, will continiue to do so. As far as HT, my answer is yes and no. We generally create and store various BIOS profiles:

Stock Settings
Moderate OC
Max OC w/ HT
Max OC w/o HT

Histrically.... say back with Sandy Bridge if you took the Max OC w/ HT and turned off HT, you would see a 7-8 temerature drop when stress testing. This allowed you an extra 0.1 - 0.2 GHz OC before ya hit the same temperature limit. For the last 4-5 years tho, I'm usually hitting the voltage limit before the temperature limit and tho it's not really delivering anything, still put the option as a BIOS profile option in case users wants to play with it.

When there's an actual documented report of someone exploiting one of these theoretical vulnerabilities, that's when I will pay attention. As of yet, it's just fuel for fanbois to argue about which logo has more of them.

 

[SoNic67]

In my work computer I have HT turned off because Autodesk programs don't do multithreading (with small exceptions that are not applicable to me). 4 or 6 cores are sufficient, and with HT off, CPU gains a little more headroom on the clock.

 

[EarthDog]

CPU gains a little more headroom on the clock.

Only with overclocking (you have an overclockable work PC? Coo!). At stock it doesn't matter... boosts are still the same.

 

[GoldenX]

No. The biggest security flaw is on by default and can't be turned off. I mean Management Engine.

 

[R-T-B]

Also, you're example is in C, not JS.

I was told psuedocode. Again he's not really my buddy per se just pilfering a yahoo group I joined ages ago that aparently doesn't know psuedocode from C.

I also found the source. They ripped it from the friggin public RIDL pdf... see example 1. lol.

If I wasn't such a poor programmer (C# and Java is my world basically) I'd have caught that right away. Sorry for the run around.

 

[SoNic67]

Only with overclocking (you have an overclockable work PC? Coo!). At stock it doesn't matter... boosts are still the same.

No OC on workstations. But I think boost for 1,2 versus 6 cores is different when all virtual 12 are used. Thermal and electrical limits. Xeon E5-26xx v2 (dual-processor).
Plus single threads go faster when they don't share the pipeline with others.

 

[EarthDog]

No OC on workstations. But I think boost for 1,2 or 6 cores is different than for all 12.
Plus single threads go faster when they don't share the pipeline with others.

Regardless if HT is enabled or not, your boost clocks remain the same.

You may have a small performance bump single threaded, but since your apps don't use HT, the resources aren't shared in the first place.

I'm not hating/saying it is a bad idea for you to disable HT, but some of the reasons listed don't appear to be true is all ('headroom').

 

[SoNic67]

There are other apps running, like email, and OS is doing it's thing too.
So some multi core competition will probably occur, just from other sources.

 

[EarthDog]

The Song Remains the Same.

 

[danbert2000]

If I turned HT off, I would be left with a quad core processor in 2019. I will eventually upgrade my CPU, but since I am on the DDR3 side of things, it would essentially require replacing everything. So I will wait, with my 4 cores but 8 threads, and be sure to keep my computer updated. If a virus makes its way to my machine, I don't think I'm going to have much more of an attack surface just because HT is on. And I'm not running random VMs next to my other processes. So the risks of using HT are not that big.

In the enterprise game, this has really screwed up multi-residence VM hosts. Amazon, Google, Microsoft have to now make sure all mitigations are in place, or they have to turn off HT and lose ~33% of their capacity. If I were them, I'd be considering buying some new EPYC chips in the future, or start selling VM space with a requirement to bundle HT cores together. Having multiple companies sharing a CPU was always going to be a risky situation. Sharing the same core is madness.

 

[lexluthermiester]

While we are at it, this is also wrong.
Clearly you don't.
Anywhere easy and near impossible are completely different.
It could take years to find them, and years more for it to be released.

You're welcome to your opinions, but until you can demonstrate a proof of concept remote attack, the opinions of experts in the field have greater credibility.

 

[phanbuey]

I have completly ignored all these "vulnerabilities". Until I see a story about a user expereincing an actual problem, will continiue to do so. As far as HT, my answer is yes and no. We generally create and store various BIOS profiles:

Stock Settings
Moderate OC
Max OC w/ HT
Max OC w/o HT

Histrically.... say back with Sandy Bridge if you took the Max OC w/ HT and turned off HT, you would see a 7-8 temerature drop when stress testing. This allowed you an extra 0.1 - 0.2 GHz OC before ya hit the same temperature limit. For the last 4-5 years tho, I'm usually hitting the voltage limit before the temperature limit and tho it's not really delivering anything, still put the option as a BIOS profile option in case users wants to play with it.

When there's an actual documented report of someone exploiting one of these theoretical vulnerabilities, that's when I will pay attention. As of yet, it's just fuel for fanbois to argue about which logo has more of them.

I don't think there will be. Not because it's impossible, but there are just so many better ways of breaking in that it's highly improbable that attackers will waste their time like this. And your software might get flagged and you get caught before you even pull off an attack.

Now... that might all change when the first artificially intelligent exploiters hit the scene, since they would basically have all the time in the world.

But for right now, I cant imagine any attacker using this for anything other than academic purposes, just to see if they can, essentially.

Regarding turning off HT: The latest updates to prior MDS mitigation seem to have have incurred a cache miss penalty when HT is turned off. If you look around there are 9700K users complaining of stuttering in many games and some performance loss with HT turned off (used to be the opposite case). I can confirm this as well, HT turned off my chip can do 5.05 GHz with decent temps -- it now noticeably stutters in FC5 and FC5: New Dawn with those settings (SkX is weak with latency to begin with, so it compounds the issue) with HT turned on, the games are smooth.

The current prevailing theory is that HT allows for each thread to have it's own branch predictor, and by doubling the threads you give the CPU the option, in the case of miss, a greater chance that one of the other threads has the data you were looking for. I'm not versed well enough on how that works to actually know if that's true or not; will get links to the articles if yall are interested. I can confirm stuttering on i5 and non-HT i7 systems in those games after recent w10 updates though.

 

[R-T-B]

the opinions of experts in the field have greater credibility.

Lex, the RIDL whitepaper pdf from the "experts" does state javascript is a potential vector, FWIW. I've been reading it.

There is no POC yet, true. And it may even be impractical. But they did state it is possible.