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).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
