Slashdot Mirror

← Back to Stories (view on slashdot.org)

Intel CPUs Impacted by New PortSmash Side-Channel Vulnerability (zdnet.com)

Posted by msmash on from the ever-growing-list-of-holes dept.

Intel processors are impacted by a new vulnerability that can allow attackers to leak encrypted data from the CPU's internal processes. From a report: The new vulnerability, which has received the codename of PortSmash, has been discovered by a team of five academics from the Tampere University of Technology in Finland and Technical University of Havana, Cuba. Researchers have classified PortSmash as a side-channel attack. In computer security terms, a side-channel attack describes a technique used for leaking encrypted data from a computer's memory or CPU, which works by recording and analyzing discrepancies in operation times, power consumption, electromagnetic leaks, or even sound to gain additional info that may help break encryption algorithms and recovering the CPU's processed data. Researchers say PortSmash impacts all CPUs that use a Simultaneous Multithreading (SMT) architecture, a technology that allows multiple computing threads to be executed simultaneously on a CPU core. [...] Researchers say they've already confirmed that PortSmash impacts Intel CPUs which support the company's Hyper-Threading (HT) technology, Intel's proprietary implementation of SMT.

116 comments

  1. Never liked Hyper-Threading... by mi · · Score: 1

    PortSmash impacts Intel CPUs which support the company's Hyper-Threading (HT) technology, Intel's proprietary implementation of SMT.

    Never liked Hyper-Threading. It always seemed like a fishy hack — and now my irrational fears have been "substantiated" by Finnish and Cuban academics...

    --
    In Soviet Washington the swamp drains you.
    1. Re:Never liked Hyper-Threading... by alvinrod · · Score: 5, Informative

      It's not a bad idea in general and it certainly made a lot of sense when Intel introduced it since the number of stages in their CPUs' pipelines were massive (eventually ~30 with the last generation of P4 chips) and adding the functionality cost very little in terms of additional die space for the performance boost you would get.

    2. Re: Never liked Hyper-Threading... by Anonymous Coward · · Score: 0

      Its another liberal conspiracy!

    3. Re:Never liked Hyper-Threading... by HiThere · · Score: 2

      I've never liked hyperthreading either, but in my case it's because it didn't optimize things correctly for me. I want genuinely separate multi-processor systems that can communicate rapidly with each other. And rather than fancy instruction sets, I'd be satisfied with a 64 bit version of the z-80...plus a few to handle interprocessor communication.

      OTOH, I realize that my proposed task-load is substantially different from the most common case.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    4. Re:Never liked Hyper-Threading... by mi · · Score: 1

      adding the functionality cost very little in terms of additional die space for the performance boost you would get

      What "performance boost"?..

      --
      In Soviet Washington the swamp drains you.
    5. Re:Never liked Hyper-Threading... by Anonymous Coward · · Score: 2, Informative

      SMT adds the ability to achieve about a 30% overall system performance gain at the cost of a mere 10% additional die space.
      As far as design choices go and economics, it's a very solid choice to make.

      Overall system throughput is of course load-dependent.
      Neither multiple cpus, multiple cores, nor multiple contexts will help a single threaded workload just the same.

    6. Re:Never liked Hyper-Threading... by Bert64 · · Score: 1

      Only when your code is inefficient and causing pipeline stalls, if your code is well optimized then SMT is more likely to cause a performance loss.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    7. Re:Never liked Hyper-Threading... by gman003 · · Score: 4, Informative

      Some code can't be compute-bound, no matter how well written. Stuff with very random memory access patterns, for example - 3D particle systems are notorious for this. While one thread is blocked on a LLC or RAM read, the other has full use of the core.

      Some code can also be very optimized for SMT. It's rare to have two threads using almost exclusively separate execution units of a core, but if your problem is naturally divisible in such a way, you can get a full 100% performance improvement. Think a Huffman decoder feeding data to some kind of SIMD floating-point number crunching - one thread's using mostly shifts and integer math, the other's using SSE, and SMT will let both run simultaneously.

    8. Re:Never liked Hyper-Threading... by Zorpheus · · Score: 1

      Isn't something with very random memory access patterns most likely limited by ram throughput anyway?

    9. Re:Never liked Hyper-Threading... by Anonymous Coward · · Score: 0

      That's the point. Such programs tend to switch rapidly between memory access and computation. Running two at the same time lets them use the CPU more efficiently.

    10. Re:Never liked Hyper-Threading... by Anonymous Coward · · Score: 0

      More like 80 per cent on the DEC Alpha where it was developed. Of course Intel's copying of it left out the full implementation and introduced security vulnerabilities.

    11. Re:Never liked Hyper-Threading... by Anonymous Coward · · Score: 0

      My asus eeepc netbook with Atom N570 runs on a linux kernel with hyperthreading disabled. No recognizable performance loss so far. Machine is used as a typical desktop.

    12. Re:Never liked Hyper-Threading... by Highdude702 · · Score: 1

      Machine is used to surf slashdot.

      FTFY
      Netbooks are garbage for anything but surfing the web. You cant do 80% of the things you can do on a typical desktop. Damn sure not more than one at a time either. You get a little better performance on linux than you do windows, however it is still very limited. I used a netbook for a year or so cause I had no other choice.

    13. Re:Never liked Hyper-Threading... by drinkypoo · · Score: 1

      Netbooks are garbage for anything but surfing the web.

      Most of them are garbage for that, too, because these days web surfing elegantly requires multiple cores and at least 4GB RAM, plus more for caching if your storage is slow.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    14. Re:Never liked Hyper-Threading... by Highdude702 · · Score: 1

      Oh how right you are.. I could never try to deal with that torture again.

    15. Re:Never liked Hyper-Threading... by Anonymous Coward · · Score: 0

      Pycharm is quite usable. Compiling the kernel with necessary options takes about 30 minutes.

  2. Still waiting on my remote root SSH exploit by Seven+Spirals · · Score: 1, Flamebait

    Spectre, Meltdown, a few others I forgot, and now this one. Okay security fearmongering douches, I just have one fucking question. If all this shit is so bad, where are the exploits for SSH? The phrases "tempest in a teapot" and "much ado about bullshit" come to mind. Why aren't there worms ravaging the internet and pwning every intel-based router and host machine on the net? Perhaps because all these TLB exploits and crypto hand wringing make for much better copy on some wired article than they make research material for real exploits. Send all the fucking links to "whitepapers' you want, but nobody has a fucking leg to stand on until there is some real fallout here, and it's just not materializing.

    1. Re:Still waiting on my remote root SSH exploit by iggymanz · · Score: 5, Insightful

      Stupid point of view, you're saying we have to wait until some no-goodnick exploits a known and proven weakness before we lift a finger to do anything? No, they need to be fixed before something bad happens. some of us are responsible for machines that handle billions of dollars, we can't take your lazy attitude

    2. Re:Still waiting on my remote root SSH exploit by crow · · Score: 4, Interesting

      Those were big bugs, and they have real impacts. Not all impacts allow remote exploit. For home users, the impact is to change any remote exploit that gains user privileges into one that gains root privileges. That's important, but not a disaster.

      Where the real disaster is is in virtualized systems. That class of exploits allows you to potentially hack from one VM into another running on the same physical hardware. That's a disaster for cloud providers, but fortunately, they have professional IT teams that can stay on top of required patches, to the extent that they are able to do so. Unfortunately many of the patches may need to be done inside the user-controlled VMs.

      This sounds like a somewhat similar bug in that if you can execute on one hyperthread, you can figure out what is going on on the other one on the same core (or at least I suspect that's it--I didn't read the article). Again, that's bad for virtualized systems, but not that serious for most home users. It does potentially blow a big hole in the security for whole-disk encryption and things like that, which some people are going to be very concerned about.

    3. Re:Still waiting on my remote root SSH exploit by Seven+Spirals · · Score: 3, Interesting

      No, I'm not saying take no action, I'm saying don't tell me it's the end of computing unless it really is. Quit acting like all these *potential* vulnerabilities amount to anything but a "possible fear". They aren't fully-formed threats, they are nebulous bullshit until they can be shown to be something else. Also, this shit has been going on all through 2018 if it's so bad that we all need to prepare so much, then why haven't ANY of these flaws really resulted in 4/5ths of 5/8ths of FUCK ALL?

    4. Re:Still waiting on my remote root SSH exploit by Seven+Spirals · · Score: 3, Informative

      The reality of 2018 is that they have had SQUAT for impact. Hand wave and fear dance all you want, but that's the reality.

    5. Re:Still waiting on my remote root SSH exploit by Anonymous Coward · · Score: 0

      No dumbass, he's saying the fear mongering from media outlets and some security "researchers" is the problem. Nothing was said about fixing it.

      Can you read motherfucker?

    6. Re:Still waiting on my remote root SSH exploit by Anonymous Coward · · Score: 0

      Argument from incredulity

      The argument from incredulity is a logical fallacy that occurs when someone decides that something did not happen, because they cannot personally understand how it could happen.

      The fallacy is an argument from ignorance and an informal fallacy.

    7. Re:Still waiting on my remote root SSH exploit by Anonymous Coward · · Score: 0

      The reason is because most people capable of carrying out attacks want the internet to keep working. Those who want to create chaos have easier ways and the remainder keep it secret.
      Also; Durr durr durr derp on you sir.

    8. Re:Still waiting on my remote root SSH exploit by Seven+Spirals · · Score: 1

      Didn't say I didn't understand. I said it's histrionic bullshit until one of these 4-5 "severe flaws" produces some significant non-whitepaper non-researcher impact. The fact is that they haven't.

    9. Re:Still waiting on my remote root SSH exploit by Seven+Spirals · · Score: 1

      That'd be all fancy and nice and smart-debater-like if that actually had anything to do with my actual point. I never said I didn't understand it or that I can't understand how it could happen. So, that makes your entire post moot and totally ridiculous. Try re-reading your Wikipedia list of logical fallacies before you post more tripe.

    10. Re:Still waiting on my remote root SSH exploit by Anonymous Coward · · Score: 0

      These are actual potential problems, they could conceivably cause massive data loss, and if you give us tons of money we can study it and fix this problem that doesn't exist yet. Nice database you have there, it'd be a real shame if something were to happen to it....

    11. Re: Still waiting on my remote root SSH exploit by Anonymous Coward · · Score: 0

      Youre mom is on my jock

    12. Re: Still waiting on my remote root SSH exploit by Anonymous Coward · · Score: 0

      Where have you been? These exploits are all over the place.

    13. Re:Still waiting on my remote root SSH exploit by Anonymous Coward · · Score: 1

      Relax. It's an ongoing war, and the doomsday scenario you're hoping for might indeed happen.

      The way software works, you don't just have one surface area that can be attacked like popping a balloon. It's more like an onion composed of many stacked layers. Some of these vulnerabilities are serious because they're either lower level, in hardware or code that we thought was well-tested for years or even decades, and other times they're serious because there's no quick and fast workaround that doesn't cause it's own side-effects. Systems that stay unpatched degrade due to people finding more and more exploits at each layer. If the seriousness of the threat isn't respected, those systems will ultimately become exploitable by automated attacks.

      This, along with Spectre/Meltdown/Heartbleed/Rowhammer, are more serious than a random bug in application software because they affect millions of systems worldwide.

      Overall system security is much like anti-terrorism, it's largely preventative because you don't know what the precise threat level is, only that you know it exists and what the potential for damage is. If you do nothing, it'll definitely be catastrophic.

    14. Re:Still waiting on my remote root SSH exploit by Anonymous Coward · · Score: 0

      It's only bullshit depending on your reaction to it. If you stop all the presses and tear everything apart in an attempt to mitigate spectre then you're doing security wrong. Now you can research the potential impact and determine ROI. If you can mitigate a security vulnerability easily then you'd be an idiot if you didn't.

      Without researchers letting us know what potential new threats there are we can't be proactive. Being reactive to virus threats really sucks. Fortunately I'm at a point in my career where I have enough say that I can turn most IT departments into being proactive and saving a ton of time and headache.

    15. Re: Still waiting on my remote root SSH exploit by Seven+Spirals · · Score: 1

      Well, my mom is dead, so I hope you like necrophilia, Mr Coward.

    16. Re:Still waiting on my remote root SSH exploit by Anonymous Coward · · Score: 0

      I said you don't understand. Listen, "You do not understand these vulnerabilities." You might think you do, but you do not. It doesn't matter what you think, you simply do not understand.

    17. Re: Still waiting on my remote root SSH exploit by Seven+Spirals · · Score: 1

      Link, asshole. Link? Funny cause Googling: "remote root exploit openssh spectre meltdown side channel tlb" doesn't return anything useful.

    18. Re:Still waiting on my remote root SSH exploit by Seven+Spirals · · Score: 1

      "If you do nothing, it'll be definitely catastrophic." I hear this argument a lot these days. Still sounds like bullshit. Nobody gets rich betting on the end of the world.

    19. Re:Still waiting on my remote root SSH exploit by Anonymous Coward · · Score: 0

      Must not do anything virtualized. There is an impact and to pretend otherwise is foolhardy. Hide your head in the sand all you want but there is impact.

    20. Re:Still waiting on my remote root SSH exploit by postbigbang · · Score: 4, Insightful

      It's not really a war, it's more intrigue and economy

      The state actors will try to have the exploits first. They'll pay mightily to have them, and let them do work quietly for a long time. I suspect they're already at work. Because of the problem in AMD's PSP chips, some exploits will never be detected, ever, only blindly wiped at some point.

      Other exploits will try to be quiet and quietly unobtrusive for as long as possible. Then there'll be a leak or a copycat found, and available on an onion address for a short while at a slowly degrading price, until someone buys and exposes it, and then there will be a fury of patching until variants of that bug come alive, while other bugs are sitll in stage one or two.

      Don't believe nothing's going on. We're just in the quiet stage, until someone either screws up and lets their EK become revealed, or a handy packet snifter starts alarming someone to a rogue somewhere. Then something at stage one will go to stage two. That's how this works.

      --
      ---- Teach Peace. It's Cheaper Than War.
    21. Re:Still waiting on my remote root SSH exploit by Anonymous Coward · · Score: 0

      You sound massively inept. Please only be a stupid home user that has no access to any infrastructure of importance outside of your Minecraft server

    22. Re:Still waiting on my remote root SSH exploit by Anonymous Coward · · Score: 0

      Spectre, Meltdown, a few others I forgot, and now this one. Okay security fearmongering douches, I just have one fucking question

      You didn't have to read the full article. Just up to "The PoC steals an OpenSSL (
      The phrases "tempest in a teapot" and "much ado about bullshit" come to mind. Why aren't there worms ravaging the internet and pwning every intel-based router and host machine on the net?

      The last time worms came close to "ravaging the Internet" was 15 years ago. Everything has been fine since then. You can go back to sleep now. All of these security patches and shit since... no need to bother because the Internet still worked without them.

    23. Re:Still waiting on my remote root SSH exploit by Anonymous Coward · · Score: 0

      Evidence? The reality is that you don't have a clue.

    24. Re:Still waiting on my remote root SSH exploit by Anonymous Coward · · Score: 0

      The reality of 2018 is that they have had SQUAT for impact. Hand wave and fear dance all you want, but that's the reality.

      I bet you're one of those people who didn't vaccinate your kids for stuff like Polio because there are barely any cases of that anymore.

    25. Re: Still waiting on my remote root SSH exploit by Anonymous Coward · · Score: 0

      You are an idiot lol.

    26. Re:Still waiting on my remote root SSH exploit by OneHundredAndTen · · Score: 2

      While this is obviously a trolling attempt, the fact is that there is an element of truth in it. An example: we have been told for years now that RSA-1024 is insecure, and that it should have been ditched long ago. In truth, no RSA-1024 certificates have been compromised because an RSA-1024 has been broken. The largest RSA keys that have been brute-forced were RSA-768 a few years. After many months of work on many different systems in the network. I.e. after a huge effort, that nobody has so far attempted to replicate for RSA-1024. The projection was that RSA-1024 would have been publicly broken by about now. It hasn't happened. Why? Because it is way too onerous a process, both financially and time-wise. If you have a certificate meant to be valid for 10 years and meant to protect really critical, world-importance data then, sure, use a bigger RSA key or ECC. Otherwise, nobody is going to bother attempting to break your RSA-1024 key - if the bad guys/government agencies really wanted your data (which they probably don't anyway) they have far more efficient, faster, cheaper and better methods at their disposal to obtain it than trying to brute-force your key.

      In a nutshell, security people engaging in hype, probably for job-security reasons.

    27. Re: Still waiting on my remote root SSH exploit by TimMD909 · · Score: 4, Funny

      I run my Minecraft server as root so I can dig past the bedrock, you insensitive clod.

    28. Re:Still waiting on my remote root SSH exploit by OneHundredAndTen · · Score: 1

      The last time worms came close to "ravaging the Internet" was 15 years ago.

      For very elastic definitions of "close".

      Everything has been fine since then.

      And just about everything was mostly fine then. It was, once again, 95% hype and 5% reality.

    29. Re:Still waiting on my remote root SSH exploit by fustakrakich · · Score: 1

      ...it's just not materializing.

      :-) How do you know that?

      --
      “He’s not deformed, he’s just drunk!”
    30. Re:Still waiting on my remote root SSH exploit by Anonymous Coward · · Score: 0

      No, I'm not saying take no action, I'm saying don't tell me it's the end of computing unless it really is. Quit acting like all these *potential* vulnerabilities amount to anything but a "possible fear".

      I don't understand. What in your mind is the difference between a "potential" and an "actual" vulnerability?

    31. Re: Still waiting on my remote root SSH exploit by Anonymous Coward · · Score: 0

      Just means that, much like before you were born, she just can't say no to the D.

    32. Re:Still waiting on my remote root SSH exploit by Anonymous Coward · · Score: 0

      Yes, nobody gets rich betting on the end of the world.

      But lots of people get poor or dead failing to bet on the "end of the world" throughout history.

    33. Re:Still waiting on my remote root SSH exploit by slack_justyb · · Score: 2

      I don't dispute what you said, it's correct, however, I do want to point out a few things.

      we have been told for years now that RSA-1024 is insecure, and that it should have been ditched long ago

      If someone told you it's insecure, then they should have preceded it with, "in some situations". And you hit on the reason a bit further in your comment, here.

      If the bad guys/government agencies really wanted your data (which they probably don't anyway) they have far more efficient, faster, cheaper and better methods at their disposal to obtain it

      But brute-forcing it is also an option for State sponsored cracking efforts. And indeed, for most folks, RSA-1024 is good enough unless you're targeted. At least right now. But the timelines for when to retire a given RSA strength was based mostly on Moore's Law and carefully (actually that's debatable but that'll get us side-tracked) calculating people dragging feet versus new and improved advancements in processing. So the idea is that folks would indeed drag their feet on RSA-1024 and thus calculate a point when processing power is good/cheap enough to break RSA-1024 and subtract 20-30ish years from that. That's the date we need to pull it. But again, you are totally right in that we're not near getting to a point where folks freely break RSA-1024 all over the place.

      The largest RSA keys that have been brute-forced were RSA-768 a few years...The projection was that RSA-1024 would have been publicly broken by about now. It hasn't happened. Why?

      Also, I just want to point out there was money involved. RSA stopped paying people in 2007. That might (I'm guessing here so feel free to call me out on my BS here) have had some effect on when these things get broken by research efforts.

      Because it is way too onerous a process, both financially and time-wise

      Absolutely, expect in cases where it is worthwhile to spend that time and money on breaking it, which are few and far between which again, you already pointed out.

      If you have a certificate meant to be valid for 10 years and meant to protect really critical, world-importance data then, sure, use a bigger RSA key or ECC

      Exactly.

      So you might wonder, why deprecate RSA? Because you aim for lowest common denominator here. In 20-30ish years computational power is going to be to a point where breaking RSA-1024 will become easier, not at the point where we do it on a desktop, but definitely within the realm of someone who's got enough equipment to do such a thing. Thus, since folks tend to drag everything out, let's call it now (which was 2010) and eventually everyone will catch up, eight years later, still seeing folks using RSA-1024. So the dragging feet argument I think has some merit.

      Now of course that was based on processing power growing at a steady state, which I think we're hitting a point where that will no longer be true. If we do hit a plateau, well then good news! All the worrying was for naught. So you have an incredibly fair argument here and I commend you. However, I think it is fair to remember what the thinking was way back in the day when RSA was designed. You know simpler times and when there was massive idealism about where computers were heading.

      As far as the Uber-hype that shortly followed when RSA-1024 was going out of date. Yeah, that's totally...

      In a nutshell, security people engaging in hype, probably for job-security reasons.

    34. Re: Still waiting on my remote root SSH exploit by Anonymous Coward · · Score: 0

      Keep responding lmfao it's like when you want to ask something linuxwise: just say linux won't hack it and you'll have 20 minions to prove you wrong.

      This guy is taking notes for tomorrows sales presentation for his brothers fuware which prevents percieved threats, especially if they sound funky and there is no real fix.

      Let it go he has enough to work with now.

    35. Re: Still waiting on my remote root SSH exploit by Anonymous Coward · · Score: 0

      So did she die on his cock then or twat?

    36. Re:Still waiting on my remote root SSH exploit by Anonymous Coward · · Score: 0

      You sound massively gay. I'm surprised you could write that with a dick in your mouth.

    37. Re:Still waiting on my remote root SSH exploit by Seven+Spirals · · Score: 1

      A potential vulnerability is one that has or shows the capacity to become or develop into something in the future. An actual one exists right now. Did someone block dictionary.com for you or something?

    38. Re:Still waiting on my remote root SSH exploit by Seven+Spirals · · Score: 0

      Well, running thousands of Internet-legal IP hosts, managing firewalls & NIDS across dozens of sites globally, and finally having a shitton of Intel servers gives me at least some idea. Is some uber-hacker sitting on a secret unused megaspoit? Sure, maybe, or maybe they have an even worse method. However, that's an argument like "How do you know there is no God?" It's tough to disprove anything completely. However, some of us are pragmatists and not "security experts" with vivid imaginations about what "might" happen. My whole point is that all these "potential" problems haven't amounted to enough of an actual real exploitable problem to get so excited that we have a collective freakout. In fact, they haven't resulted in hardly any fallout at all besides security circle-jerks and finger wagging. Where's the spoits!? (said like "Where's the BEEF?"). I'm saying "let's all ignore security" either. It's just that you can only talk shit and wave your arms for so long before at least some of the people in the room walk off and say "Fuck this. You guys are whining, hand-wringing, pussies. I have real work to do."

    39. Re:Still waiting on my remote root SSH exploit by Seven+Spirals · · Score: 1

      Not really.... only sometimes. I definitely remember days where flaws followed up minutes, hours, or days later with REAL exploits. The rpc.statd exploits were that way and so were Samba 2.x flaws. It didn't take 11 months for someone to "unwrap the onion", more like 11 minutes for actual flaws that aren't made up of pure fear and unicorn farts.

    40. Re:Still waiting on my remote root SSH exploit by Miamicanes · · Score: 1

      > The last time worms came close to "ravaging the Internet" was 15 years ago

      Not quite. There was plenty of nasty stuff a couple of years ago involving buffer overflows, especially a particularly nasty one caused by the way a very popular image library handled JPEG files that ended up enabling "drive-by" exploits.

      On the hierarchy of badness for a typical non-enterprise user, "drive-by" exploits are absolutely, positively the worst, because those are the exploits that can nail even people who are aware & prudent (without necessarily succumbing into paralysis and tinfoil-hat paranoia).

      One half step down are vulnerabilities that involve the kind of attacks that can be carried out remotely against arbitrary systems over the internet. Simple NAT is often more than good enough to protect against THESE, even if it's just a lucky side effect. Firewalls are effective against "most" of the rest, with the exception of high-value targets that are explicitly sought out.

      Slightly lower than those are attacks that rely on trusted agents. For example, an attack that uses a compromised computer sitting on your internal network to carry out activities that couldn't be carried out directly by someone over the internet itself.

      Moving WAY down the list (from the perspective of home users), you have the kind of attacks that allow privilege escalation... but only with the active assistance of a trusted user who has physical access to the hardware itself. Things like malicious USB keys and trojans are the main vectors here that are likely to really concern a home user. The risk that a second legitimate user might be able to intentionally do something that a legitimate admin regards as naughty is a very, very, extraordinarily-distant concern to home users... but a very BIG concern to people who administer things like networks in schools, libraries, and large enterprises.

      Near the bottom of the bin (from the perspective of home users) are attacks that enable code running in one hypervisor to compromise data running in another. These are horrific to companies that provide hosting services, but almost a complete non-issue to home users.

      The catch is, there are ALSO plenty of security vulnerabilities that were a total non-issue to home users 20 years ago, but have BECOME an issue in recent years. Prior to the large-scale emergence of rootkit trojans, privilege-escalation was almost a complete non-concern to home users, if only because Windows ITSELF barely enforced any kind of limits on code-execution for home users not running on enterprise networks under group policy limits. The rapid popularity of single-sign-on services like Facebook & Google made request-forging and impersonation attacks something that suddenly mattered to normal home users, whereas previously it was something that was of concern mostly to enterprises (who were just about the only users who could AFFORD single-sign-on solutions).

      And frankly, the capabilities that have been semi-insidiously added to Javascript over the past few years by Firefox, Chrome/Webkit, and Microsoft are just plain horrifying (Jesus God, compiling Javascript to NATIVE CODE?!? So much for ANY remaining pretense of containment...). And that's coming from someone who used to laugh at tinfoil-hat people who refused to enable Javascript.

      IMHO, though, the thing that will REALLY send us down the security black hole is the growth of artificial intelligence. It's one thing to have an exploit that can sniff the contents of random memory addresses and obtain context-free data that could be an AES key... or nothing more an a single byte of a JPEG image. It's another matter ENTIRELY if attackers have the ability to take 27k of seemingly-random chunks of memory and effectively do pattern-recognition on it to quickly FIND things likely to be an AES key, or a RSA private key.

      Here's a practical metaphor: suppose you accidentally throw your house key in the trash, and it ends up at the landfill. At the present time, it's almost a complete, total

    41. Re: Still waiting on my remote root SSH exploit by Anonymous Coward · · Score: 0

      Nobody gets rich betting on the end of the world?

      You haven't seen the (mostly on Fox) ads telling preppers to buy gold and silver coins(at way, way over the bullion rate)?

      Ditto for the people selling into the race war crowd. Buy our products, which have suspiciously high margins, because we already price in a yet to happen, low probability event.

    42. Re: Still waiting on my remote root SSH exploit by Anonymous Coward · · Score: 0

      As of right now, are you vulnerable to bullets?

      Did your definition just change?

      Also, why the attempts to deflect this Intel only problem o to AMD PSP?

    43. Re:Still waiting on my remote root SSH exploit by Anonymous Coward · · Score: 0

      Surprised you can stand with that cock up your ass

    44. Re:Still waiting on my remote root SSH exploit by drinkypoo · · Score: 2

      The reality of 2018 is that they have had SQUAT for impact.

      Remember Y2K? It had squat for impact because a lot of people did a lot of work. Guess what?

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    45. Re:Still waiting on my remote root SSH exploit by Anonymous Coward · · Score: 0

      nobody has a fucking leg to stand on until there is some real fallout here, and it's just not materializing.

      Because it's getting patched, you putz.

      All of these vulnerabilities are disclosed to the vendor, so patches are ready for public disclosure.

      A sfor zero-day exploits... if anyone has figured these vulns out ahead of time, it's government agencies, and you'll have to wait a long time before those stories get published.

    46. Re:Still waiting on my remote root SSH exploit by Seven+Spirals · · Score: 1

      No, it had squat for impact because it was bullshit. I'm guessing you weren't there. It was much ado about nothing, not because "people did work" to mitigate it, but because it was a bullshit media circus to begin with.

  3. So... by DontBeAMoran · · Score: 1

    Do not buy the new 2018 top-of-the-line i7 Mac mini, the i3 and i5 options without hyper-threading are safer. Got it.

    --
    #DeleteFacebook
    1. Re:So... by iggymanz · · Score: 1

      Hyperthreading usually can be shut off in BIOS, why not do that if you're worried and your apps don't need it? my apps certainly don't benefit from it much...

    2. Re:So... by drinkypoo · · Score: 3, Informative

      Hyperthreading usually can be shut off in BIOS, why not do that if you're worried and your apps don't need it? my apps certainly don't benefit from it much...

      No BIOS on Macintoshes. And no other way to permanently disable HT, AFAICT. You can disable it with Instruments.app and probably with sysctl. (I do not own a Mac with an Intel CPU, I just googled.)

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    3. Re:So... by Highdude702 · · Score: 2

      "To be clear, Macs don't have a BIOS, they have an EFI." I know fuck all about macs, but you got me curious. Then I realized after 2 clicks you were being pedantic as usual.

    4. Re:So... by Anonymous Coward · · Score: 0

      No BIOS on Macintoshes

      If you wanna be pedantic, go big or go home :P

      There's no BIOS on any recent computer made for quite some time now.

      Consumer level PCs replaced BIOS with a full on UEFI system, combined with a BIOS compatible API layer to it, and additional software to emulate the look and feel of the "BIOS Setup" software.

      Power PC Macs use Open Firmware, and at least with Apple never had a BIOS, but pretty sure never had BIOS for any implementation.
      Open Firmware had an entire built in forth shell to work in which was SO much better than anything Intel based.

      Intel Macs use EFI instead of BIOS. Which by the way you can get rEFIt to modify the EFI flash configuration.
      Then you can disable HT by changing the values of hw.availcpu and hw.logicalcpu based upon the current value of hw.physicalcpu

      ARM based systems also have no BIOS, and are quite driver-capable in their boot firmware, usually providing the most mind mindbogglingly simple methods to configure the CPU, boot functions, driver functions, and peripheral hardware.
      It's a joy when the system reads the settings from a plain text file in the root of your boot media.

    5. Re:So... by sexconker · · Score: 1

      EFI and UEFI are both a form of BIOS. BIOS is not "BIOS" unless you're on an old IBM PC.

      Compaq stole BIOS from IBM and basically revolutionized the industry. No, Compaq did NOT develop a compatible implementation in a clean room scenario. No fucking way. Yes, I know they won in court. No, I'll still never believe that load of horse shit.

      The BIOS you have today is not IBM's BIOS, but a basic input/output system used for low level setup, hardware initialization, etc. EFI and UEFI are simply modern versions of that (that are typically fucking trash).

    6. Re:So... by squiggleslash · · Score: 5, Informative

      While I was initially annoyed about the pedantry of the original poster who corrected the use of the term BIOS, I feel that your comments are... not entirely accurate?

      EFI and UEFI are both a form of BIOS.

      This is incorrect. EFI and UEFI and BIOS (and OpenBoot, etc) are all forms of firmware, but are only partially related. EFI and UEFI have nothing in common with BIOS except being standards for PC firmware.

      BIOS is not "BIOS" unless you're on an old IBM PC.

      BIOS is BIOS if it contains bootstrap code (code to load an operating system) and a set of code vectors providing a minimal HAL defined by the original CP/M operating system. It has nothing to do with the IBM PC, though the original IBM PC does have a BIOS as CP/M (specifically CP/M 86) was one of the intended operating systems, and Microsoft's MS DOS, based upon QDOS86, also used Digital Research's BIOS specification to ensure it could easily be ported to other 8086/8088 based computers at the time.

      Confusingly, in the IBM architecture, only some of the BIOS is actually located in the ROM.

      Compaq stole BIOS from IBM and basically revolutionized the industry. No, Compaq did NOT develop a compatible implementation in a clean room scenario. No fucking way. Yes, I know they won in court. No, I'll still never believe that load of horse shit.

      Well, tough, because they did. Compaq documented everything they did and had teams of lawyers on staff to make sure of compliance, which is how they managed to end up with a BIOS that was almost completely compatible with IBM's, but contained mostly different code. If they had "stolen" it, the code would have been identical in most of their implementation. It would also have contained a BASIC interpreter because IBM's firmware included a BASIC interpreter that either loaded when you didn't have an operating system disk, or could be patched and loaded from an operating system using the 'BASICA' command.

      Bear in mind we're not talking about an enormously complex piece of software. The original IBM firmware was 16K including both the BIOS and that BASIC interpreter. The BIOS component was probably less than 2K in size. Compaq's reverse engineering process wouldn't have had many different test cases needed to determine behavior under each applicable condition. People greatly overestimate the complexity of computers during the 1970s and 1980s, and while copyright infringements did occur, most supposed "They copied this" rumors are bullshit. See also: MSDOS vs CP/M (two operating systems with dissimilar file systems, dissimilar command lines, dissimilar process architectures, but sure, MS DOS must be a copy because... uh it implements a CP/M API. Consisting of, what, less than forty functions? Including "LIFT HEAD" and other things that were NOOPs by 1981?

      The BIOS you have today is not IBM's BIOS, but a basic input/output system used for low level setup, hardware initialization, etc. EFI and UEFI are simply modern versions of that (that are typically fucking trash).

      See above. When a computer comes with a BIOS, it generally still has that jump table to a HAL compatibility library, which is why it's able to run MS DOS (and CP/M 86 if you can find a copy.) EFI requires you load an optional extension which, essentially, contains a BIOS, EFI by itself is not a BIOS.

      Source: I was there. Get off my lawn etc.

      --
      You are not alone. This is not normal. None of this is normal.
    7. Re:So... by flygeek · · Score: 1

      Not to mention that IBM provided the source code for the BIOS in the extended manual kit, so Compaq had a good idea of what they were not supposed to copy...

    8. Re:So... by sexconker · · Score: 1

      Compaq claims they produced a compatible BIOS without even so much as taking a peek under the covers. Absolute horse shit.

    9. Re:So... by sexconker · · Score: 0

      You're missing the point entirely. They're all BIOS. They all serve the same purpose and function that BIOS does. Saying EFI and UEFI have nothing in common with Coke is like saying Pepsi has nothing in common with Coke, while failing to realize you're in Atlanta and Coke is the common term for all cola. Just because a given EFU / UEFI doesn't support the same hardware as a given BIOS does, doesn't mean EFI and UEFI and BIOS are fundamentally different.

      It has EVERYTHING to do with the IBM PC because Compaq stole it and created the personal computer industry as we know it (diametrically opposed to the IBM PC + shitty wannabes industry). If you believe Compaq did it cleanly I've got a bridge to sell you. Compaq would not have needed to copy everything, obviously. Why would they copy shit they weren't going to use? You really think that because the code is somewhat different it wasn't created by stealing from IBM? You wouldn't even survive grading an 8 year old's homework assignment.

    10. Re:So... by Anonymous Coward · · Score: 0

      call it a bootloader and be done

    11. Re:So... by drinkypoo · · Score: 1

      Compaq claims they produced a compatible BIOS without even so much as taking a peek under the covers. Absolute horse shit.

      Those BIOSes were stunningly simple. They hardly did anything because they hardly had anything to do. The 5150 PC had one bus, with little more than a keyboard controller and a floppy controller on it, plus whatever primitive display card you had — mine didn't even have graphics when I got it, just a text-only display card. The original BIOS didn't even know how to talk to a storage controller other than a floppy, though my PC had upgraded ROMs that would do it.

      It's not hard to imagine that Compaq could create a compatible PC BIOS that would do all the same stuff the IBM PC BIOS did, because it hardly did anything.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  4. AMD by Anonymous Coward · · Score: 0

    Is all it takes to be free! Free! FREE! Say NO! to the iNtel tyranny.

    1. Re:AMD by iggymanz · · Score: 2

      AMD has problems too

      in fact only modern arch not proven to have problems yet is Sparc...but fuck Oracle, don't buy their shit. They will have auditors come and camp at a customer and be a pest for months until they break down and buy UNNECESSARY licenses. There are now consultants that help clients reign in Oracle to only get fees for legally required things without the extra theft money Oracle is trying to extort.

    2. Re:AMD by alvinrod · · Score: 4, Interesting

      Although no one has tested it, the article indicates that the people who discovered this vulnerability think that AMD's SMT implementation would also be vulnerable to this kind of attack. While that isn't a confirmation, it does appear as though this exploit is general enough that it wouldn't be specific to Intel. Hopefully they also disclosed this to AMD so that they had time to explore this for themselves and work on a fix if necessary.

    3. Re:AMD by drinkypoo · · Score: 1

      AMD has problems too

      They do, and so far they seem to be vulnerable to most of the SPECTRE-type attacks. However, because they at least tried to do the right thing, they are not vulnerable to MELTDOWN, and mitigation seems to be cheaper in all of the cases where the AMD processors are vulnerable.

      The real question is, if Intel was willing to deliberately compromise the security of the entire system in this way, in what other ways have they done so?

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    4. Re:AMD by Anonymous Coward · · Score: 0

      It should also be noted that the PoC code requires frequency scaling and turboboost be disabled, which is not very real world.
      It remains to be seen if this is a very practical attack.

      This security notice may be the reason behind Intel disabling HT on all but the highest end processor for 9th gen release.

  5. Intel CPU = Trash by Anonymous Coward · · Score: 0, Offtopic

    This is what happens when the CEO doesn't have the balls to say no to the NSA.

    And, before some autistic manchild says I should have used "==" understand that I am assigning the value Trash to Intel, now fuck off.

    1. Re:Intel CPU = Trash by Anonymous Coward · · Score: 0

      In that case, you should have said "Trash = Intel CPU", as that coding style helps prevent the kind of error that you were talking about.

  6. Multicore will be next by xluap · · Score: 5, Insightful

    If a hyperthread can spy on the other hyperthread that runs on the same core, it is possible to disable hyperthreading.

    However, the next exploit will be that one core can spy on another core. This is possible because all cores use the memory subsystem including the L3 cache that is shared between all cores.

    1. Re:Multicore will be next by Anonymous Coward · · Score: 0

      Speculative execution exploits are with us forever.

    2. Re:Multicore will be next by Anonymous Coward · · Score: 0

      This is why this shit will never be "fixed". The cores/threads need to collaborate if they are to function together. Leave the chip alone! The only way to mitigate a potential problem is to monitor your network traffic very closely. Oops! I hope that's not a call to Beetlejuice! But I do gotta say, that little text file can do a lot... if you keep it short and sweet.

    3. Re:Multicore will be next by DigiShaman · · Score: 3, Informative

      On August 23, 2018 - Theo de Raadt with OpenBSD even recommended disabling HT in BIOS. His e-mail below.

      https://marc.info/?l=openbsd-t...

      --
      Life is not for the lazy.
  7. "executed simultaneously on a CPU core"? by Anonymous Coward · · Score: 0

    But HT does NOT execute simultaneously!?!?

    1. Re:"executed simultaneously on a CPU core"? by Megol · · Score: 2

      Yes it does, that's the whole idea. Hyper-Threading is the Intel implementation of SMT or Simultaneous Multithreading. The idea is to make use of execution resources that would otherwise be wasted to run an extra thread of execution (or more). This is what make it different to other designs like for example switch-on-stall threaded processors which run a thread until it have to wait for something and then switches to another thread.
      Haven't looked at it but: https://en.wikipedia.org/wiki/...

    2. Re:"executed simultaneously on a CPU core"? by Anonymous Coward · · Score: 0

      That wiki says AMD has SMT as well. Why isn't their implementation affected?

  8. wait for the 2020 mac pro with amd! by Joe_Dragon · · Score: 1

    wait for the 2020 mac pro with amd!

    1. Re:wait for the 2020 mac pro with amd! by Anonymous Coward · · Score: 0

      2020 Mac Pro with ARM! The iPad Pro is already faster than a Macbook Pro...

    2. Re:wait for the 2020 mac pro with amd! by DontBeAMoran · · Score: 1

      I was waiting for the 2018 MacBook Air with ARM... disappointed it still uses an expensive piece of junk from Intel, dual-core only too.

      --
      #DeleteFacebook
  9. So by Impy+the+Impiuos+Imp · · Score: 3, Funny

    The aliens in Independence Day never stood a chance.

    --
    (-1: Post disagrees with my already-settled worldview) is not a valid mod option.
  10. APK probably thinks he can solve this by Anonymous Coward · · Score: 0, Funny

    APK probably thinks that hosts can prevent this vulnerability, just like he thinks hosts protect from Spectre and Meltdown. I'm waiting for that retard to show up in this story.

  11. Re:Oracle and lawyers by Anonymous Coward · · Score: 0

    They are the only company I know that evaluates change requests, both for possible legal liabilities and opportunities, as part of their agile process.

  12. HT available only for one process? by Mes · · Score: 2

    How does this exploit work in practice? Do you have one legitimate process doing encryption/decryption while another process tries to get itself hyperthreaded with the first in order to spy on it?

    Why not have HT available only for threads of a single process? That would stop two unrelated programs from sharing the same core simultaneously.

    1. Re:HT available only for one process? by Anonymous Coward · · Score: 0

      Having the OS schedule only threads of the same process to multiple hardware threads of the same core should help, but it's not sufficient, because "process" is not synonymous with trust boundary. You don't want data leaking between Javascript threads loaded from different origins (or from the browser to Javascript), even if both are in the same process.

  13. Researchers suspect AMD also impacted by Anonymous Coward · · Score: 0

    From TFA: "Researchers suspect AMD processors are also impacted."

  14. Yawn by duke_cheetah2003 · · Score: 1

    In lay terms, the attack works by running a malicious process next to legitimate ones using SMT's parallel thread running capabilities.

    Once again, we are presented with an 'exploit' that requires one to have compromised the target already, rendering this as a "Why bother? You're already inside."

    This feels more like bashing Intel than anything else at this point.

    1. Re:Yawn by Anonymous Coward · · Score: 0

      If by "compromised the target already", you mean "able to run javascript from a browser on the computer", sure.

    2. Re:Yawn by Anonymous Coward · · Score: 0

      The cloud.

  15. I've a good proposal. by Anonymous Coward · · Score: 0

    I want to buy a cheaper and relatively faster personal computer that has the following features.

    1. Only 1 core.
    2. No Hyper-Threading.
    3. No GPU.
    4. Largest L1, L2 and L3 caches.
    5. Lowest TDP.
    6. 10nm or 7nm process.
    7. Accelerated fabrication due to small die.
    8. Less than $100 the CPU.
    9. For running this OS Linux or *BSD.

  16. So Now What? by Anonymous Coward · · Score: 0

    My ancient desktop has a Core2 Extreme with 4 cores and 4 thread - no HT - and a real BIOS. So it should be immune? Same for my 4-core, 4-thread Atom tablet, with 32-bit Windows and UEFI.

    My laptop has an i5 with 2 cores and 4 threads - with HT. So I should disable HT in the BIOS (if it's possible - early UEFI running in legacy BIOS mode) and live with slower performance? Probably, if I'm paranoid. How likely is it that this will be widely distributed and able to operate remotely?

  17. How does it go. If you build it... by Anonymous Coward · · Score: 0

    They will game it.

    Every time I hear about a new vulnerability I laugh.
    We are at the cusp of finding out how insecure all of our electronics really are.
    People are just beginning to scratch the attack vector surface.
    As more and more non CS people are brought into the world of computing we will see an every increasing number of new methods to "break the system".
    As soon as you lose physical control of a reactionary device all security goes out the window.
    What I am saying is that it is impossible to stop it, impossible to predict it and impossible to know when it will happen. The only truth is that it will happen. It's the it we just wont know until it happens.

  18. I don't say hosts cure Spectre/Meltdown by Anonymous Coward · · Score: 0

    I don't say hosts cure Spectre/Meltdown (or PortSmash): You do IMPERSONATING me https://idle.slashdot.org/comm... & you also LIE that I have a MacOS X version of my hosts program - I don't (yet).

    * Give up already loser!

    APK

    P.S.=> FACT - you're already losing for a LONG TIME resorting to lying & IMPERSONATING me... apk

  19. just call it a bootloader by Anonymous Coward · · Score: 0

    I hate semantic arguments too, but bootloader is a generic term that should cover EFI, UEFI, and BIOS

  20. Then again? Hosts MAY stop Portsmash & why by Anonymous Coward · · Score: 0

    See subject + quote: "You basically have to already be able to run your own evil code on a machine in order to PortSmash it." from https://www.theregister.co.uk/...

    * So when hosts blocks REMOTE SOURCES of such malware? Yes, hosts CAN stop "portsmash" attacks!

    APK

    P.S.=> For once? The IMPERSONATORS of me MAY be right... apk

    1. Re:Then again? Hosts MAY stop Portsmash & why by Anonymous Coward · · Score: 0

      Am I sucking myself off in public?

      Maybe.

      APK

      P.S.=> For once? The IMPERSONATORS of me MAY be right... apk

  21. Re:I don't say hosts cure Spectre/Meltdown by Anonymous Coward · · Score: 0

    P.S.=> FACT - you're already losing for a LONG TIME resorting to lying & IMPERSONATING me... apk

    Dude, make a fucking account.

  22. LOL! Impersonating me's "best ya got" loser? by Anonymous Coward · · Score: 0

    See subject: You "F'd up" BAD saying what you did vs. this that BLEW YOU AWAY you dumb bastard https://it.slashdot.org/commen... & now you "eat your words" for it, hahahaha!

    * Eating your words != GOOD nutrition - you'll STARVE & die of malnutrition STUPID!

    (Tell us, won't you, how EATING YOUR WORDS tasted? A bit like your FOOT IN YOUR MOUTH ramming them down your CHICKEN NECK unidentifiable anonymous "WEEZIL" throat?? Washed down w/ the BITTER taste of SELF-defeat - hohohoho!)

    APK

    P.S.=> I blew your DUMB ass away, again, like always you STUPID fuck... apk