Running on Intel? If you want security, disable hyper-threading, says Linux kernel maintainer Linux kernel dev Greg Kroah-Hartman reckons Intel Simultaneous Multithreading (SMT) - also known as hyper-threading - should be disabled for security due to MDS (Microarchitectural Data Sampling) bugs. Kroah-Hartman, who was speaking at the Open Source summit in Lyons, has opened up on the subject before. "I gave a talk last …
.... with Post Modernist Fact for Present Current Fictional Tales Ploughing Almighty Virtual Trails
"They're not that hard to exploit," Kroah-Hartman said. "The research has proved how to do it. The hard part is, you can't tell if somebody is exploiting it. But it is a known problem, you can reproduce it yourself. The Zombieland guys have a great demo. It's a real issue, you need to fix it."
But it is not broken or in dire need of a fix whenever bounty delivers its temptations. You might like to realise and enjoy it as a SMARTR Stealthy Feature in a Bug Infested and Virus Invested PlayScape.
To do 20 patches a day. Fully regressed non-trivial fixes (that is, understand, create, test, release) are more like 2 fixes a week per person... Oh, and don't forget to provide performance impact for at least 4 different workloads. And go to conferences to tout those 20 patches a day... or maybe the implication is just applying 20 patches a day, that seems more reasonable, someone else does the heavy lifting. But then the comment about creating CVEs is meaningless, that is a job for whoever is doing the heavy lifting...
Badly off topic now granted by for kicks installed i386 version instead and voila no lock up. Woot at least until they kill off the architecture but hopefully by then whatever is fubar (guessing an X video driver extension or something) in amd64 will be resolved. If I was a good netizen I would track it down, report it and give back and all that but meh I suck. Works for now will do for now.
That question is difficult to answer. The main reason is that these aren't of particular concern to single-user machines. Of course one might want access to protected memory on those, but an evil person is more likely to have a better way of gaining access to data on a less secure user machine. This type of vulnerability is more useful in penetrating the protections in place on a machine running VMs for multiple people or for multiple purposes. The other problem is that you can't easily detect this by a signature or other file characteristic. Only by observing the operation of a program can the behavior be detected, and the overhead required to do that to everything is prohibitive.
All that said, the best answer is "not very many". It's not easy to do, it's relatively slow, and it's only useful in a few circumstances. You probably shouldn't fear this vulnerability as much as many others. But that's not to say it's unimportant, as there are lots of things someone could do with it.
Yes. If you are running a web server or are running on a cloud, it is an issue.
For businesses who run on-premises or for individual users on their PCs, it is less of an issue.
The proof of concepts have been shown to get the private keys from other instances over a hypervisor. That is a serious risk for multi-tenant servers. But it would only be highly targeted attacks, which means they would be hard to detect and you have to find it, before you know you are being attacked - and if the attack is running on somebody else's instance on the shared server, you may never know, especially if they don't have any AV software or other security in place.
Knowing what that data represents is difficult. Not impossible. It's made a lot easier if you have some knowledge of the format the data is likely to take. This is possible if the data is from, for example, a widely-used library or application. You could even potentially look for credit or debit card numbers (as these follow a strict format).
But even if you can read someone else's bytes, actually knowing what that data represents (in someone else's application) is impossible.
The many successful MDS demonstrations, going back to the original SPECTRE paper, show that you are utterly incorrect.
So do many other untargeted-exfiltration exploits, such as Heartbleed. In fact it's often very easy to determine how to correctly interpret exfiltrated data.
When the Morris Worm came out, there was much public sentiment that Morris was some sort of wunderkind and overflowing the fingerd stack was a stroke of genius, unlikely to be reproduced any time soon. Then Levy published "Smashing the Stack for Fun and Profit" in phrack, demonstrating that it was actually quite easy to develop a stack-smashing exploit, and suddenly everyone and their basement-dwelling cousin was doing it.
That was answered in the article, its not known how many because its not something you can easily detect.
Its easy to exploit and hard to detect. win win for the black hats.
I'd be more interested in if metasplot has this built in allowing any script kiddie to create something that exploits it after they get home from school.
How many attacks exploiting spectre and it's ilk have been discovered in the wild so far?
I'm curious.
Hard to tell as attacks are very hard to detect.
Do not pay attention to the others who replied to you as they did NOT read the article properly (and I cannot be bothered to downvote the lot):
"MDS is where one program can read another program's data. That's a bad thing when you are running in a shared environment such as cloud computing, even between browser tabs."
This "probably" means it is exploitable via JavaScript, so, basically, you're 0wned by a web page.
So, yeah, it is a problem for average Joe if he has more than one program or browser tab open at the same time. The rest is wishful thinking.
This "probably" means it is exploitable via JavaScript, so, basically, you're 0wned by a web page.
If you read the original SPECTRE paper, you'll see that one of their demonstrations was indeed implemented in Javascript. Before the paper (and associated CVEs) went public, major browser manufacturers implemented mitigations for that particular attack. Subsequently other MDS issues in browser Javascript engines were pointed out, and then mitigated, over a number of iterations.
These days, it's likely difficult to mount a successful MDS attack in Javascript under a recent release of a major browser, particularly when hardware / firmware / OS mitigations against the most useful side channels are also enabled. I wouldn't rule it out, though.
If you are super paranoid and wanting to be the most secure you can be. Security is like backups. You have to judge for yourself what you are protecting against, and how best to protect that. What are the risks vs costs of the mitigation? For me it's easy, I believe these side channel attacks are WAY overblown and as such have actively avoided firmware updates from my vendors to patch them. At some point I'll buy a new enough system that it will probably include some of those firmware fixes, but so far I have not.
But it's nice the firmware updates are there for those that want it.
I also don't run cloud stuff. I have hosted my own email on my own server for more than 20 years now(same with my websites). I have managed internet facing infrastructure (100s of systems) for more than 20 years without a single known security incident(I have been involved in other security incidents with things that were managed by other teams or people though). So my track record and confidence is high with that in mind. I also don't run things that I'd rate as high risks for attacks, so that factors in as well. I admit that my situation is far from common, but it does annoy me to see so many folks treat security as an absolute. It's either secure or it's not. That's not true at all because there will always be security patches and vulnerabilities. Just because they haven't been publicly disclosed doesn't mean they aren't there, and in many cases doesn't mean they aren't actively being(perhaps highly targeted) exploited. Goes back to risk again of course.
If you're one of those folks that doesn't feel secure unless they have the latest patch then well go do that, but security is a lot more than just making sure you have the latest patch (and in my opinion it's the other bits that count a lot more towards security than having the software up to the latest patch).
@Nate Amsden belief's and realiity
You say you have managed "100s of systems" for more than 20 years and yet you also say that you have had no responsibility for security issues in that time and noticed no security issues whatsoever on kit you "managed". You go on admit that whilst "you" never had any security problems others working on what I presume to be these same systems did have?
What exactly does "managing" systems in your opinion mean? I take it to mean that you had nothing to do with firewalls, antivirus, OS and application updates, would I be wrong in this assessment?
You say you ran your own email server without any security issues for 20 years? is this server perchance running on your home LAN and was it switched on and accessible to the internet at any point?
I ask as there have been lots of emails attacks of all kinds over the last 20 years going to all IPs with any email ports open and if you never noticed any of these then either you were very very lucky, blind or someone else did the "hard work" of protecting your system for you.
Personally I am thinking the latter since no day has passed for me over the last 20 years even on my home network where there were no attacks blocked by my firewall.
So in conclusion, whilst you do not believe that security is something you need to worry about and then when you admit that you have been oblivious to the security problems everyone else has seen for 20 years then I am not going to take your opinion on security very seriously, sorry even if you are running NIX then there have still been enough security issues for you to know that they exists in reality
@Anon
I appreciate Nate's nuanced and relevant comment. Not every server is multi-tenant, and mitigating sidechannel attacks has significant costs. He didn't say what you claim or in the way you claim it. I will reply from my own experience managing Internet-facing sites.
What exactly does "managing" systems in your opinion mean? I take it to mean that you had nothing to do with firewalls, antivirus, OS and application updates, would I be wrong in this assessment?
What an odd statement. Firewalls and antivirus servers are designed to survive in hostile environments. I've managed a few of these and never saw one compromised. "OS and application updates" is very broad and shouldn't be lumped in with security appliances.
I ask as there have been lots of emails attacks of all kinds over the last 20 years going to all IPs with any email ports open and if you never noticed any of these then...[insults]
Sure, that's Internet Background Radiation. SMTP is some of the less interesting stuff we see. What do you find remarkable about it?
whilst you do not believe that security is something you need to worry about and then when you admit that you have been oblivious to the security problems everyone else has seen for 20 years then I am not going to take your opinion on security very seriously, sorry even if you are running NIX then there have still been enough security issues for you to know that they exists in reality
You grasped the wrong end of the stick. Read again for comprehension. And consider how much we might care whether an anonymous person with incoherent ideas about Internet security will "take [our] opinion very seriously."
Well said and thanks for posting.
I'm the same (though not at the same scale) - I've not had reason to believe anything I've worked with has been compromised. Under attack, even DDoS level of attack (just once thankfully, lasting 14 or so hours IIRC, but nothing compromised. I did go over stuff heavily after the DDoS, removing the server's drive and rebuilding from good known sources then scoured the original drive (including checksum checks against original sources) for signs of compromise, but not one single byte out of place or failed checksum/date/size check.
I even used to run a repair shop network where we often had infected machines connected to my network. Simple things could save a lot of headaches (eg the file store the customer machines could reach was built on RO DVD's housed in ROM-only drivers (not DVD-RWx, plain old DVD-R) - even if the 'nix permissions were somehow bypassed, it was physically impossible to write to the disks!)
In that time I too was involved in hundreds of incidents involving others, but not my stuff.
The AC who replied doesn't seem to grasp the basic concept of "managed by other teams or people" likely means systems you weren't responsible for and maybe not even using at any time. I did help clean up after some attacks and help some companies recover and rebuild their systems, but they weren't things I designed or built or ran, in fact often the first time I even heard of the firm was when they came to me for help.
There are two different issues here:
1. old kernels have bugs, all kinds of them. Many of the bugs are security holes. Embedded devices are built on some old, randomly selected kernel and never updated - so they "accumulate" (in a passive manner) security holes which are never patched. The same applies to Android phones which do not receive vendor updates, BTW.
2. some of the security bugs are not in the kernel; the patches in the kernel are just workarounds for security related bugs in the CPU hardware itself, e.g. timing attacks which can read one-bit-at-a-time from some hypothetically protected part of the address space. Computers are fast and one-bit-at-a-time can leak a significant amount of data e.g. a private key. The workarounds in the kernel come with performance overhead and also hit intel much more frequently than they do hit AMD. In particular, there either are no good workarounds for some security bugs related to Intel hyperthreading, or GKH is so fed up with merging those that he does not trust the whole edifice. Meanwhile, the equivalent AMD technology appears to be safe.
I'm not sure our personal PCs is where he was aiming though.
Sure, but... I have been asked in the past to cough up suggestions for what server hardware to buy, and who knows, I might be asked again (retirement is still 20+ years away).
So, based on my experience with my own personal rig and articles like this one, I am very likely to push for AMD at every opportunity I get.
Regardless of all that, it is good to see AMD being competitive again. Quite a relief actually.
Speculative execution is a very old bit of tech and exists in some form in many CPU designs from all sorts of architectures.
Embedded intel devices may be running on a 386, 486 or pentium if they are older and dont have this issue but anything that embeds a pentium 4, xeon or Atom does. The question is if it is enabled.
But embedded devices are unlikely to be running multi-tennat VMs, which is the main risk for this type of bug.
To exploit this type of bug, an attacker has to have some way of running code on your computer. If your embedded device is (eg) a firewall, that's not going to happen unless they can leverage some other kind of flaw in order to execute code of their choosing, and most bugs of that type will give them full root access anyway (the state of embedded security being what it is), so by that point they don't need to use Spectre.
So if your choice is between something running Intel SMT, but with well written software that's continually supported, or a different CPU but standard embedded software (ie release once then abandon), I'd go for the Intel.
To exploit this type of bug, an attacker has to have some way of running code on your computer. If your embedded device is (eg) a firewall, that's not going to happen unless they can leverage some other kind of flaw in order to execute code of their choosing, and most bugs of that type will give them full root access anyway (the state of embedded security being what it is), so by that point they don't need to use Spectre. ... fuzz
If attacked by this type of computer bug exploitation, is the target of interest the computer user, which may or may not be your very good self.
Whenever not all bugs are bad are some AWEsomely Great and well worthy of Prime Private/ Premium Pirate Consideration in Future Virtual Operations Spaces ..... with Spookily IntelAIgently Serviced and Servered Places.
And one can't buy them for they are exceptionally expensive. It is just as well then there are countless innovative buy-in schemes with SMARTR Investors in Futures Delivering Plots.
Are we chatting outsider/insider information dealing there? I'd be wonderfully surprised to hear of any financial or of any possible computer code violations forthcoming from that shared intelligence. It is not as if it is secret whenever all is so surely shared here ...... and for Showing New Pleasant Present Creations to Vast IntelAIgent Audiences.
Would you Like to Help Assist and get Thoroughly Excited by the Simply Addictive Process which Drivers Full Wilfull Participation to Explosive Mutually Beneficial Climaxes.
Tell me that aint Holy Grail Central and we may both still have a lot to learn, but for now I'll just stick to the tales and trails that try passionate temptation to prove that it is. :-)
That sounds like a Search for Heavenly Grounds has Supplied Almighty Bounty there. What's not to like?
It's only systemd distros which are unbootable. Poettering decided calling the kernel to get a random number wasn't good enough for him. You know, the kernel routine which mixes in other sources of entropy instead of just using the CPU's entropy generator. Instead he just calls RdRand, which also has bugs on some Intel chips and doesn't exist before 2012.
> It's only systemd distros which are unbootable. Poettering decided calling the kernel to get a random number wasn't good enough for him
get off the bandwagon, you'll end up in a ditch
the problem was that the kernel needed entropy but it didn't trust RdRand, with no entropy and no services starting the system would lock up because the init system was waiting for kernel random pool initialization (getrandom() won't give out bits before that happens)
that is fixed with the very newest kernel (5.4) after Linus merged jitter entropy generator: https://lwn.net/Articles/802360/
To all of you who don't think rng bug is scary - how many applications use cpu rng only? Do you know? VPN clients? And amd keeping this bug quiet, notifying users only buy email, no posts on their website (as far as I know)?
I get all that cheering for underdog, but rng returning all ffff... getting past qa means no amd CPUs for me in near future. This slappy beyond believe - can't believe all of you just shrugging it off!
can't believe all of you just shrugging it off!
Most of my stuff is AMD. I tend to run one or few VMs on a regular basis, sometimes even play games in some of them sometimes do other stuff.
Thus far the problem - well the first I heard of it was reading your post a few minutes back. Hasn't been an issue so far and probably won't be, if it ever is I'll deal with it. Till then, enjoy a good hearty shrugging. I'll put it on my to-do list just after taking a post-Boxing Day dump (for the year 2258 - I might not be around then to do something about it though).
"I get all that cheering for underdog, but rng returning all ffff... getting past qa means no amd CPUs for me in near future. This slappy beyond believe - can't believe all of you just shrugging it off!"
The problem can be summarised as a BIOS bug that prevents machines booting in certain circumstances and a fix has been released by AMD but may not have been released by all motherboard manufacturers.
It's annoying and there are workarounds if you are unlucky enough to be affected and in a few months it will largely be addressed.
In the meantime, back to the real security issues with Intel Hyperthreading that can't be addressed other than by disabling a feature (hyperthreading) and suffering a performance hit as a result. The fix for which is a new CPU.
If you find these comparable rather than one inconvenient and the other challenging to address in any large scale environment then....*shrug*
If you're running on Intel, but want to be secure: best practice is to disable hyper-threading and keep your BIOS and kernel up to date.
Surely, if the problems are exclusive to Intel hardware, the best practice is to stop running Intel hardware and get non-broken hardware from vendors who didn’t cut corners with security to win benchmarks?
This post has been deleted by its author
If you're running on Intel, but want to be secure: best practice is to disable hyper-threading and keep your BIOS and kernel up to date.
Updated Linux kernels are easily and freely available.
BIOS - not so much. Many OEMs provide firmware (which could be BIOS, or a whole host of other things) updates as Windows-only executables. FreeDOS and the Linux Vendor Firmware Service don't cover all the hardware out there, which means that there are an awful lot of systems with out-of-date firmware out there. This is not good, but I can't see a realistic and easy answer.
"Updated Linux kernels are easily and freely available."
Yes, and even those are only chasing the problems that they've discovered. The implication is that there are still many out there to be discovered - and maybe some have been discovered by someone else.
Yes, and even those are only chasing the problems that they've discovered. The implication is that there are still many out there to be discovered - and maybe some have been discovered by someone else. ..... Doctor Syntax
:-) ..... and what can/should one do with such an attractive promiscuous beast and wild child, Doctor Syntax, should it ever be thought possible to be able to do anything at all effective and worthwhile in so many fields in which ignorance and arrogance would claim to exercise reign?
Whenever nothing at all effective and worthwhile is the true answer, who and/or what suffers and benefits the most from such as is as Madness and Mayhem for CHAOS in Confusion?
Any advance on Intelligence and Sanity?
Updating OS kernels is (usually) tractable. I can test the new kernel for hardware compatibility and other issues without destroying my system. Or if the testing failed to show a problem that becomes all too apparent later. I can (probably) recover from a problemetic update one way or another.
BIOS and other firmware upgrades OTOH have the potential to be a "final solution". If I brick the hardware, am I going to be able to unbrick it?
There is an easy answer, but the vendors and "power users" aren't going to like it.
The hundreds of megabytes of Flash, the tweaking guff, weird Windows backwards compatibility widgers (eg: "A20" config), PXE boot loaders can and should get shit-canned. This allows a customer to have some confidence + control over what is actually executed and some assurance that their M/B can't be perma-bricked by some tosser at the other end of an Ethernet cable.
This could be achieved very simply and cheaply by replacing the Flash memory + fscking BIOS / UEFI with a tiny *ROM* bootloader that loads a few bytes off a bootstrap storage device (eg: a MicroSD card on the motherboard) and executes it. That ROM bootloader should do nothing other than load those bytes and execute them - everything else is to be done by the code on the MicroSD card that is firmly under customer control.
The boot loader for PDP11s was short enough so that you could key in the 10 or so instructions from the front panel to initiate the load of the first stage bootstrap. From the V6 "Setting up UNIX" document on Tuhs:
Once the UNIX `binary' disk is obtained, the system is booted by keying in and executing one of the following programs at 100000. These programs correspond to the DEC bulk ROMs for disks, since they read in and execute block 0 at location 0.
RK05 RP03 RP04
012700 012700 (to be added)
177414 176726
005040 005040
005040 005040
010040 005040
012740 010040
000005 012740
105710 000005
002376 105710
005007 002376
Many early machines actually had the boot loader on paper tape that would be run through a reader on the console.
Sorry about the line spacing, the < pre > marker looks like it does not preserve line spacing.
If I'm in a high performance environment then I've already done boundary stuff or weeded out fringe activities. No screen-savers for me while I'm AI-ing the next national lottery numbers.
For the rest of us why not enable whizzo cache stuff only when CPU usage exceeds 85%? That way most of the time there is no point in poking around with fancy caches and long before Mr. Black Hat has winkled-out any cross-contaminated trivia I'll have detected or changed.
Whilst in general I agree, it is now the case that within a browser, each tab is run in a separate thread, with protection between the threads (there was an article about this in Firefox a few months ago).
As each tab could be running client side code downloaded from different servers, each in their own thread, it is necessary to have some degree of protection to prevent code in one tab getting information from another tab (imagine if you are doing some online banking in one tab, which could be spied on from a tab running some 4Chan or LOLcats pages in another).
So it is not safe to have hyperthreading turned on even inside a single process.
In addition to this, as most OSes schedule at a thread level, not a process level, it is practically impossible to have hyperthreading turned on in one process and not in another. Maybe on a core-by-core basis, but then you have all sorts of core affinity problems, and that does not solve any problems!
I think the issue that your are touching is much broader. If you host a service (e.g. a web browser) that expose a Turing machine (e.g. a javascript engine) to external parties (e.g. websites), then you need to be very careful about what is available to that Turing machine. Ensuring that code is not able to exploit speculative execution bugs in that closed environment should be easy (and to my understanding it has been solved).
With regards to scheduling, then it would be similar to being NUMA-aware when scheduling.
Most of the code running on your desktop or laptop comes from signed rpms and operates on input written by you. So it's fine. The risk is really browser tabs spying on each other. A few years ago in most browsers those weren't separate processes anyway (just threads) and we weren't too bothered, but the simplest mitigation is just to close your whole browser and reopen only one window if you need to login to your bank account etc.
This is not really the case. Yes, much of the code is in signed RPMs or DEBs, but that only goes so far.
There are many other routes to get code on your system, which include Perl CPAN modules, browser extensions, desktop extensions, Java and Javascript running outside of a browser, and pretty much any high capability scripting language, especially those that allow the use of online code repositories, of which there are now plenty.
The flexibility of having client side code execution comes with many, many security implications, many of which are not even obvious unless you look at how these features are implemented.
Also, using a browser to execute complex applications is becoming much more normal with the G-suite, Office365 and all the other cloud based services. It soon won't be a minor piece of functionality, but the norm, as it is on Chromebooks now.
Its not just browser tabs spying on each other.
Its the browser tab running in your VM spying on the host too!
Also signing does not guarantee the program is not malicious, it only guarantees that the program is undamaged/unaltered from the repo. Once the GPG keys get compromised or the Git tree modified under the nose of the developer signing means very little beying confirming that the malicious package you just downloaded did in fact get signed by those keys and was not modified.
"Making that switch means one, two, three more data centres....
Or swapping to AMD CPUs a) because "All the issues that came out this year, were reported not to be an issue on AMD," and b) because they have better multithreaded performance even before you cripple the Intel ones.
You might want to be shorting Intel about now...
Cripes. The whole article is a mass of confusion, which seems to originate in the direct quotes, between threading, hyperthreading, shared cache and multi-core processors. Was English not the first language of some of these guys? .... david 12
david 12,
The whole gist of the argument is that virtually all practical machinery is commanded and controlled with the use of patented words. It is why certain strings of words are so terrifying as to be absolutely worthless in anything worthy of enjoying and employing/engaging and exploring possibilities with.
Whose words are drivering your vast mute geopolitically astute machines .... you know, the Source Servers of Current Present Confections Holding Media Hostage with a Dodgy Past Catalogue of Very Early Exceptional Successes to Protect and Prune/Prime Time Performance Enhance. ‽
You might find now there are more than just a precious few, and the precious few are confounded and confused to be so easily recognised and liable to follow up questioning on future plans.
Things then can easily very quickly go super critical frenetic and crazy ballistic if that is your only proposed plan .... to hold worlds to ransom with almighty worthless weapons .... for that is Universally Unacceptable and Punishments are Certain Death and Immense Destruction. It is as a Purge and at all times necessary whenever a Blockage to the Surge. :-)
> Whose words are drivering your vast mute geopolitically astute machines .... you know, the Source Servers of Current Present Confections Holding Media Hostage with a Dodgy Past Catalogue of Very Early Exceptional Successes to Protect and Prune/Prime Time Performance Enhance. ‽
Man people go to secret prisons for saying stuff like that.
It would not burn down the world to publish all the bugs you're fixing. It would only burn down intel.
Why the hell is anyone still buying Intel's chips? They have been inferior, overpriced junk, since the 1990s.
AMD doesn't have this issue? And threadripper CPUs are _killing it_. Google would not build 3 new datacenters, they'd replace all their Intel CPUs with AMD. So would Facebook, Twitter, so on and so forth. Intel would enter bankruptcy _overnight_.
Which would be good for all of us, BECAUSE INTEL HAS ALWAYS SUCKED.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
