Slashdot Mirror

← Back to Stories (view on slashdot.org)

Researchers Discover Seven New Meltdown and Spectre Attacks (zdnet.com)

Posted by msmash on from the security-woes dept.

A team of nine academics has revealed today seven new CPU attacks. The seven impact AMD, ARM, and Intel CPUs to various degrees. From a report: Two of the seven new attacks are variations of the Meltdown attack, while the other five are variations on the original Spectre attack -- two well-known attacks that have been revealed at the start of the year and found to impact CPUs models going back to 1995. Researchers say they've discovered the seven new CPU attacks while performing "a sound and extensible systematization of transient execution attacks" -- a catch-all term the research team used to describe attacks on the various internal mechanisms that a CPU uses to process data, such as the speculative execution process, the CPU's internal caches, and other internal execution stages. The research team says they've successfully demonstrated all seven attacks with proof-of-concept code. Experiments to confirm six other Meltdown-attacks did not succeed, according to a graph published by researchers. Update: In a statement to Slashdot, an Intel spokesperson said, "the vulnerabilities documented in this paper can be fully addressed by applying existing mitigation techniques for Spectre and Meltdown, including those previously documented here, and elsewhere by other chipmakers. Protecting customers continues to be a critical priority for us and we are thankful to the teams at Graz University of Technology, imec-DistriNet, KU Leuven, & the College of William and Mary for their ongoing research."

53 of 98 comments (clear)

  1. 2018... by Anonymous Coward · · Score: 2, Funny

    the year of the k6 processor.

    1. Re:2018... by ArchieBunker · · Score: 1

      I'm using Itanium you insensitive clod!

      --
      Only the State obtains its revenue by coercion. - Murray Rothbard
  2. SESTEA by fred911 · · Score: 1

    I hereby claim copywrite and trademark privileges to the above work. All rights reserved. Please enquirer directly for permissions or use licensing.

    "a sound and extensible systematization of transient execution attacks"

    --
    09 F9 11 02 9D 74 E3 5B - D8 41 56 C5 63 56 88 C0 45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
    1. Re:SESTEA by Aighearach · · Score: 1

      Trademark doesn't even protect a "work." If it was doing work, we know it wasn't a mark.

      Maybe apply for a design patent next time.

  3. Re: Yawn by jd · · Score: 1

    Why? Scared of formal methods?

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  4. Re:Yawn by Anonymous Coward · · Score: 1

    These aren't "bugs." Bugs are not intentional.

    These are design flaws... weaknesses brought about by deliberate abandonment of sound engineering practice. These processors are defective by design, and I would imagine the right subpoenas would reveal that these multi-billion dollar companies knew or should have known that their product was defective by design, and withheld that information from the public.

    That is why I am joining the class action lawsuit against all three chipmakers. I figure they owe me approximately 49 billion dollars in real and imagined damages.

  5. News Flash by fahrbot-bot · · Score: 2

    Researchers discover that computers are only 100% secure while powered down and still in the box.
    Further investigation is need to determine how this affects productivity.

    --
    It must have been something you assimilated. . . .
    1. Re:News Flash by Anonymous Coward · · Score: 4, Insightful

      Do you have proof that a powered down computer in the box is actually secure? After all, they have batteries and some components are active.

    2. Re:News Flash by Aighearach · · Score: 1

      If this affected all computers equally, you'd even have a point; as it is you're just trying to be misleading while sounding smaht.

  6. Soon all the last decade performance wins by ReneR · · Score: 1

    will be lost in vulnerability workarounds :-/

    1. Re:Soon all the last decade performance wins by DontBeAMoran · · Score: 4, Interesting

      For the majority of users, we could be doing fine with computers from 1998 if the operating systems, applications and the Web had not suffered so much bloat, especially because of the overuse and bloat of using multiple javascript librairies because web monkeys are too lazy to write their own five lines functions in javascript.

      The only regular users who need so much computing power are gamers, where security is not exactly critical.

      Then there is an extreme minority of users and datacenters who need both security and computing power, but those are specialized users and should move to a different architecture.

      --
      #DeleteFacebook
    2. Re:Soon all the last decade performance wins by Anonymous Coward · · Score: 1

      I doubt the problem is laziness. It's incompetence.

      Programmers used to be incredibly skilled, not least because the machines where they cut their teeth were insanely limited which lead to intimate knowledge of how a computer actually worked, assembler, etc. They were working _really_ close to the hardware, because that was the only way to get anything useful out of the machine, which was horrifically expensive.

      Since the 90's however, the exploding capabilities of hardware have allowed companies to consistently purge competence in favour of hiring cheap codemonkeys and replacing skills with "libraries" and "frameworks". I'm sure the present day breed of programmers do as well as they are able and allowed to do. The problem is that that isn't very good. Most of them have never even had as much experience with optimization as you'd get in the past from having to optimize you autoexec.bat or config.sys to get various games running, clues of how a computer actually works are rare. And even if they do know, they are not given time to fix their crappy code, let alone optimize it in any meaningful way.

    3. Re:Soon all the last decade performance wins by UnknownSoldier · · Score: 1

      > And even if they do know, they are not given time to fix their crappy code,

      Nail. Head.

      "There is never time to do it right but there is always time to do it over."

    4. Re:Soon all the last decade performance wins by Zmobie · · Score: 4, Insightful

      This is more the problem. I've known both flavors or software devs, code monkey or genuine talent, and while obviously you want the later they both face the same issues. The number one issue for code optimization is time constraints. Until the performance of the code actually becomes a problem and there is significant monetized benefit to improving the underlying architecture/design/implementation no one in management is really going to care if the dev got the algorithm to run in O(n) or O(logn). The questions they ask are simply does it work, is the customer ok with how it works, and how fast can you give it to us/them to buy/sell?

      I remember one piece of code I managed to write on a project that I was actually extremely proud to have written. It was a completely proprietary need, so it had to be done in house with no libraries and was a very core piece of the service I was creating. I was able to do O(1) insertions, keep it self sorting for easy traversals, and perform O(1) lookups while it cleaned itself up. It even had a very minimal spatial complexity because I managed to do some wonderful pointer magic (in .NET at that) with a few different data structures. Once I completed the service I was actually satisfied with the implementation and that part of the code didn't have to be touched again (ever from what I was told by a few other project leads years later). You know what the project manager said? He didn't care at all and was actually upset that I didn't finish it early so I could work on the other developer's pieces because they were going slower than he wanted (I was even on time with the delivery and still got that response). Upper management sided with him and to avoid further friction moved me to a different project and threw a code monkey onto their team that spat out hot garbage...

      I think if you talk to most good developers they probably have a similar story if they have been in the industry for more than 5 years or so. Scope creep and the insatiable desire for new tangible features are the biggest enemies to efficient and optimized code these days. We probably have just as many genuinely talented developers in the industry as ever imho.

    5. Re:Soon all the last decade performance wins by UnknownSoldier · · Score: 1

      Wow! Your story is disheartening but mirrors what Ive seen. I'm starting to hate the corporate culture more and more. No one has time to answer questions, everyone is too busy trying to get their stuff done, etc.

      Smart programmers, like you, get shat on and then companies wonder why they have a hard time finding god people! I swear clueless management has to be responsible for 49% of the problems along with the other 49% being code monkeys.

    6. Re:Soon all the last decade performance wins by hairyfeet · · Score: 2

      Can I have some of what you are smoking please? Because in 1998 we were using 600Mhz CPUs with almost no cache, 128Mb of RAM was considered a lot, oh and did I mention that if there was ANY error 9 times out of 10 your computer would just crash and take your work with it? Yeah wasn't the web and javascipt causing that part of the bloat, having an OS fail gracefully without taking down the system instead of just shitting itself takes quite a bit of overhead. And God forbid you have more than 1 thing at a time you wanted to do as multitasking was about as pleasant as waiting in line at the DMV.

      Now if you would have said 2008, when the Phenom quads and C2Q ruled the land and 4-8Gb of RAM was pretty common? Would have agreed with you 100%, because even today those early quads are quite usable for a daily driver, heck I have an HP Media Center with a Q9505s I still use at the shop for looking up parts and converting analog to digital thanks to its built in capture card and on basic tasks its as snappy as my octocore, but dude its obvious its been quite awhile since you used a single core X86 PC because let me tell you its quite painful.

      Even those $10 ARM SoC maker boards use at least a dual as nobody wants to suffer with a single core even at $10 and those CPU designs are a hell of a lot more advanced than the shit we was running in 98.

      --
      ACs don't waste your time replying, your posts are never seen by me.
    7. Re:Soon all the last decade performance wins by DontBeAMoran · · Score: 1

      I guess it's a difference of experience, I grew up with computers and started on a Tandy Color Computer 2 with a tape cassette reader and a CPU that ran at less than 4MHz with 64KB of RAM.

      From my point of view, I see 600MHz CPUs with 128MB of RAM as more than enough to do basic office work. I used to be enough, then bloat creeped in around the era you're thinking of as being the golden era of computing.

      Without bloat, a single computer with a quad-core CPU and 4GB of RAM would be the server doing the workload of an entire office floor where workers use dumb terminals.

      --
      #DeleteFacebook
    8. Re:Soon all the last decade performance wins by hairyfeet · · Score: 2

      Dude I started on the VIC 20, remember when "The Shat" was selling the VIC with his TJ Hooker dead beaver rug? Didn't mean I didn't know then as now that they sucked.

      Maybe its because I was in the biz and had access to hardware you didn't but the boss at the PC shop I worked at had me hooked up to an ex server board with dual socket 650Mhz running an insane at the time 512Mb of RAM and even back then I'd have to get off my system and jump onto a 450Mhz Celery like the masses were using at the time and go "wow...this REALLY sucks" so even back then I had got to experience just how much nicer multicores were and even on basic office work and browsing it was like night and day, you on your PC would have been like Bubsy and I was Sonic on crack, I could bounce between a dozen running programs with instant reaction time thanks to my 10k RPM drives, it was like running an octocore with SSD today.

      You just didn't know it blew because you didn't get to see what as possible back then which was totally understandable, until I took a job at the shop I thought my Celery 300a OCed to 500Mhz was just banging but even back then once you went multicore? You just couldn't go back, it was just too painful. Hell the boss even gave me one of the first 1Ghz systems that came through the door, I ended up handing it back and going back to my dual 650Mhz until we got some dual socket boards that could take the 1Ghz+ chips, I just could not stand going back to single core after tasting how much nicer computing with multicore was.

      --
      ACs don't waste your time replying, your posts are never seen by me.
  7. Maybe... by jd · · Score: 4, Interesting

    ...This wasn't the best way to improve performance. There are other approaches, or modifications to existing ones.

    Does anyone know if Itanium 3 was affected? If not, Intel might want to revisit it, as there's bound to be commercial interest in fast, secure processors. (Because it was a ground-up redesign, it would have been free of defects from mainstream processors.)

    I'm guessing the UltraSPARC/T3 is safe, for similar reasons. Totally different internal architecture.

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
    1. Re:Maybe... by Seven+Spirals · · Score: 2

      Anyone know how this affects really strange x86 CPUs like the Transmeta Crusoe, or VIA stuff? I'm also curious about MIPS, HPPA, Alpha, VAX, and POWER.

    2. Re:Maybe... by OneHundredAndTen · · Score: 1

      Yes, Itanium was affected by Spectre. Unsure about meltdown.

      My understanding is that Itanium is not vulnerable to either. Would you care to share a reference where it is explicitly said otherwise?

    3. Re:Maybe... by Seven+Spirals · · Score: 2

      This article doesn't have great references, but does state that Itanium isn't impacted. I'd be surprised if it's horrible EPIC architecture is vulnerable in the same ways. I'd also be surprised if it doesn't have a zillion other problems, but it's unlikely anyone cares enough at this point to uncover them. EPIC was an extreme take on "fuck ASM coders, let the compiler do the work." and the ASM coders won by default.

    4. Re:Maybe... by DontBeAMoran · · Score: 1

      https://it.slashdot.org/commen...

      --
      #DeleteFacebook
    5. Re:Maybe... by DontBeAMoran · · Score: 1

      If it comes to that, I still have a VIA C3 mini-ITX motherboard in its box... somewhere.

      --
      #DeleteFacebook
    6. Re:Maybe... by AvitarX · · Score: 1

      If I'm not not mistaken, Itanium requires the compiler to through instructions in parallel and executes them all at once (VLIW).

      This was a method to improve performance without speculative execution, unfortunately, it doesn't work as well as the CPU taking things out of order and predicting.

      That's my understanding anyway.

      --
      Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
    7. Re:Maybe... by thegarbz · · Score: 3, Interesting

      ...This wasn't the best way to improve performance.

      Maybe given the incredibly low threat posed by side channel attacks given that they literally require letting someone not only run code on your computer but also have the opportunity to characterise that computer in attempt to learn how to actually achieve something with a speculative execution attack, maybe given all that it was a GREAT way to improve performance.

      We are nearly 1 year in, and there have been no nefarious exploits utilising this despite the fact that for the most part you could consider perfectly patching these holes almost impossible. Remember that when you think of trade-offs.

    8. Re:Maybe... by Seven+Spirals · · Score: 1

      That's more or less the same as my understanding. So, like I said, I'd be surprised if it was vulnerable to speculative execution attacks. However, with bizarre ISA they've got, I'm sure they made plenty of mistakes somewhere. However, it's also pretty likely they'd be able to fix those issues with recompiled binaries rather than whole new TLB strategies.

    9. Re:Maybe... by jd · · Score: 1

      Hobbits are affected by magic ring buffer attacks via the arithmetic and Mordor unit.

      --
      It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  8. The worst part... by Layzej · · Score: 3, Informative

    Important tidbit not mentioned in the summary: "In addition, the research team also discovered that some vendor mitigations that have been already deployed have also failed to stop the seven new attacks, even if they should have, at least in theory."

  9. Which cpus are vulnerable to what... by shaitand · · Score: 4, Informative

    https://zdnet1.cbsistatic.com/hub/i/2018/11/14/15e46793-eebf-46b5-8fbd-23896b34a1ae/9641c5228c53fbde1d8778dd94ae5832/new-meltdown-attacks.png

    Not that quantity of vulnerabilities is everything but Intel and Arm are in serious relative trouble... again. How many of their performance and power advantages over the last several years have been substantially due to the of taking secure design shortcuts? AMD may be even further than the lead than we've realized.

    1. Re: Which cpus are vulnerable to what... by Seven+Spirals · · Score: 4, Informative

      Wrong. You can't exploit speculative execution on a CPU that doesn't have it.

    2. Re: Which cpus are vulnerable to what... by Gravis+Zero · · Score: 4, Funny

      Wrong. You can't exploit speculative execution on a CPU that doesn't have it.

      sure you can... but only speculatively. ;)

      --
      Anons need not reply. Questions end with a question mark.
    3. Re:Which cpus are vulnerable to what... by thegarbz · · Score: 1

      How many of their performance and power advantages over the last several years have been substantially due to the of taking secure design shortcuts?

      Probably none given the incredibly difficulty of doing anything useful with such an attack without already having unsupervised access to a computer. By none I mean they didn't take any shortcuts and instead put through what looks like a reasonable performance trade-off.

      Or are you taking a shortcut right now reading this? I suggest if you're worried about Spec Execution attacks you start with the low hanging fruit and take an axe to your modem. You'd be insane to have a connection to the internet if you're worried about the security issues here. Or maybe you legitimately use your computer like this: http://screencrush.com/files/2...

    4. Re:Which cpus are vulnerable to what... by shaitand · · Score: 1

      Actually I think this is a great thing, the people who are likely most concerned are those who are trying to lock down information from those who have unsupervised access such an employer or the copyright/gaming cartels with DRM.

    5. Re:Which cpus are vulnerable to what... by shaitand · · Score: 2

      Sure, right now the fix is AMD. The fixes for Intel have been dramatically reduced performance.

    6. Re:Which cpus are vulnerable to what... by Aighearach · · Score: 1

      Not that quantity of vulnerabilities is everything but Intel and Arm are in serious relative trouble... again. How many of their performance and power advantages over the last several years have been substantially due to the of taking secure design shortcuts? AMD may be even further than the lead than we've realized.

      Basically none of the ARM advances over the past several years would be rolled back by this, because it is only a tiny portion of their portfolio that is even vulnerable at all, and those are the newer chips that are in few products. The affect on ARM has to do with promised offerings in the future, not the offerings in the past whose advantages have driven their adoption in the marketplace.

    7. Re:Which cpus are vulnerable to what... by Kuruk · · Score: 1

      Notice AMD is called out so often but.

    8. Re:Which cpus are vulnerable to what... by thegarbz · · Score: 1

      Hahahah now that is a very interesting perspective I've never considered :-)

  10. Re:Where is my remote root openssh exploit? by XanC · · Score: 1

    Being able to spy on and manipulate other VMs on your VM's host is a plenty big enough exploit.

  11. Re:Where is my remote root openssh exploit? by Seven+Spirals · · Score: 1

    I think he's calling bullshit. Meaning hand-waving is not the same as having-shit-to-back-up-what-you-say-right-fucking-now. So, where is the code to said exploit?

  12. Re:DRM predictions by NewtonsLaw · · Score: 1, Offtopic

    LOL... this is funny... if you read the previous comment first ;-)

    first comment:
    "The Intel CEO must pay for his crimes... He failed us and must be hung in the town square"

    Following comment:
    "How long until they prohibit execution on vulnerable CPUs"

    LOL

  13. To quote a bowl of petunias by gman003 · · Score: 1

    Oh no, not again.

    1. Re:To quote a bowl of petunias by DontBeAMoran · · Score: 2

      Many people have speculated that if we knew exactly why the bowl of petunias had thought that we would know a lot more about the nature of central processing units.

      --
      #DeleteFacebook
  14. How do you like your clouds now?! by sinij · · Score: 1

    How do you like your clouds now? Do you even know all APTs that now have your keys?

    1. Re:How do you like your clouds now?! by kiviQr · · Score: 1

      Keep in mind that cloud provider can fix it for all. Much better option than people having racks in their closet and never patching it.

    2. Re:How do you like your clouds now?! by Aighearach · · Score: 1

      If you have a rack in your closet and have to protect it from yourself, you have worse problems.

      This should only be a concern if you have a rack in somebody else's closet, or somebody else's rack in your closet.

  15. Three choices .... by ELCouz · · Score: 1

    Speed....Security...Cheap...Pick only two, can't have it all!!!

    1. Re:Three choices .... by DontBeAMoran · · Score: 1

      I'll have you know that the ATmega328P has all three!

      I mean... 16MHz is fast, right?

      --
      #DeleteFacebook
    2. Re:Three choices .... by Aighearach · · Score: 1

      16Mhz is your crappy arduino board, you can't blame the ATmega328 for that.

      And stop saying P at the end, the ones you buy have -P at the end which stands for PDIP, but the actual 328P with the P as part of the processor name is exactly the same as the 328 it just uses less power on standby. So you don't mention the P part when its true, you only mention the P when you're confused about the part numbers.

      ATmega328 supports up to 20Mhz using an external oscillator. It actually works up to over 30Mhz. But out of the box without an external oscillator it runs at 8Mhz, out of the box divided down to 1Mhz. So the number 16Mhz doesn't even come up.

      That may not sound fast, except that, you get an instruction every cycle. For some workloads it is faster than a x86 running at 3Ghz. This is because the cache, pipelining, etc, in a CISC processor are designed to maximize average throughput, but the potential worst case times are worse than if you had no pipelining or cache at all. One instruction might take thousands of cycles on the x86, and only 1 on the AVR. And if the exact timing of the instructions matters, then it is even worse, because the AVR is totally deterministic and can merely count cycles to know where it is in the algorithm, but the x86 is non-deterministic and will have to do a bunch more work to track not only elapsed cycles, but where it is in the algorithm.

      All of that said, it should have been "throughput, security, cheap; pick two." You can absolutely have fast, secure, cheap. That's actually easier than fast, secure, expensive because then you have to support a lot more memory, probably different types of memory, and now it is hard to get speed without non-determinism, which cuts into security!

    3. Re:Three choices .... by Anonymous Coward · · Score: 1

      Businesses have been trading security away for cheaper solutions....for years. You may have noticed the endless parade of stories in the news about businesses being hacked and the identifying information of their clients being exposed to criminals? You know....again and again and again to the point where we are numb to it?

      That is because businesses basically must skimp on security in order to be competitive. Otherwise, the ones who pay up for good security are destroyed in the market by the ones that don't. And the buyers don't care. Oh, they say they care, but then keep right on buying from the lowest bidder, which is invariably the one that skimped on security.

      So, there you go.

  16. Re:The Intel CEO must pay for his crimes by rogoshen1 · · Score: 1

    hanged.

    A painting is hung. CEO's and other criminal miscreants are hanged.

    Slashdot, where pedantry will always be alive and well!

  17. SPecial Executive for Counterintelligence... by Livius · · Score: 1

    For a second I was really curious what SPECTRE was up to and what James Bond was going to do about it.

  18. Doesn't surprise me by Sqreater · · Score: 1

    And fixing them will introduce more attack vectors. What a man can make, a man can break. That is why I don't think quantum communication and encryption is actually unbreakable.

    --
    E Proelio Veritas.