back to article AMD, boffins clash over chip data-leak claims: New side-channel holes in decades of cores, CPU maker disagrees

AMD processors sold between 2011 and 2019 are vulnerable to two side-channel attacks that can extract kernel data and secrets, according to a new research paper. In a paper [PDF] titled, "Take A Way: Exploring the Security Implications of AMD’s Cache Way Predictors," six boffins – Moritz Lipp, Vedad Hadžić, Michael Schwarz, …

  1. Anonymous Coward
    Anonymous Coward

    So not all FX and Ryzen architecture chips to date are affected?

    1. Anonymous Coward
      Anonymous Coward

      "So not all FX and Ryzen architecture chips to date are affected?"

      They very likely are affected if these findings are true.

      It would we very difficult for the boffins to obtain every single AMD CPU (since FX) for testing since AMD has made custom chips for their clients - like the Epyc 7571 they had tested. As long as each microarchitecture is tested with a couple of representative samples (which they've done) it is in my eyes very likely that all of them are affected.

    2. Grikath

      All of them should be....

      The attack requires the attacker to run his own code on your machine. This means a side channel attack is the least of your worries, since you've been pwned already. Once that happens your flavour of OS or hardware isn't exactly relevant anymore, isn't it?

      1. richard?

        It says unprivileged code, including Javascript, so no pre-pwnage required.

        1. Fading
          Terminator

          But the code used..

          Was pre-existing side channel exploit code that has been mitigated? Seems that if you have patched for the existing side channel attacks then this method as outlined in the paper would not work. Of course this doesn't mean a new side channel attack that has not been discovered and mitigated could not take advantage of this exploit but that is a harder attack vector than many others are already out there.

          I'm still a little more concerned with the IME exploit and the many meltdown/spectre variants that my intel chips are vulnerable to - thankfully I am probably not a high value target.

        2. Anonymous Coward
          Anonymous Coward

          @ including Javascript

          Yet more proof that websites should stop foisting their site's processing upon the client, especially when their JS being run is not under their direct control

          1. Stevie

            Re: @ including Javascript

            Ger Rid Of Useless Javascript Now!

            1. John Brown (no body) Silver badge
              Thumb Up

              Re: @ including Javascript

              GROUJaN!!!!

          2. YetAnotherJoeBlow

            Re: @ including Javascript

            On reason for client side processing is that PWAs need to have persistence locally to save state. IF the js code is trusted, this is a more secure process.

            Personally, I'm afraid I'm biased. I do not download non-trusted code and run it - if that can be prevented; and if not, only run in a sandbox (ie a browser.)

  2. Anonymous Coward
    Anonymous Coward

    What an absolute suprise!

    Who would have thought that something that implements Intel features and uses Intel speed ups suffers Intel problems.

    1. phuzz Silver badge

      Re: What an absolute suprise!

      In case you were wondering about all the downvotes, this article is about AMD making their own mistakes, entirely separate from Intel.

      The fact that this is somewhat similar to Melthdown says more about where researchers are currently looking for potential vulnerabilities, than it does about AMD or Intel's design decisions.

      1. Michael Wojcik Silver badge

        Re: What an absolute suprise!

        Mostly it says information thermodynamics is Still A Thing.

      2. eldakka

        Re: What an absolute suprise!

        I agree and upvoted for the first statement.

        However, I do not believe the second statement is accurate. As far as I can tell in my admittedly non-expert - vague would be more appropriate - understanding, this is not a Meltdown-equivalent or similar attack.

        These attacks seem to be more Spectre-equivalent attacks.

        Which is not to say that they aren't, potentially, serious.

  3. Anonymous Coward
    Facepalm

    Impact?

    I assume this has or will soon be weaponized by all major security services (and hacking tool creators like NSO) but, even so, I can't see it as a common attack vector.

    For the normal person, like the Intel vulnerability kerfuffle, it doesn't seem to matter. I've got a slew of security issues that I am much more concerned about.

    That said, both here and in the Intel case, it would seem that trying to make your chips seem to run faster by tweaks to the software can and sometimes does introduce low level security issues that may not be correctable. OTOH the benefits to the user experience probably means that this will not be the last of these articles.

    1. Anonymous Coward
      Anonymous Coward

      Re: Impact?

      How many security problems are there with a Z80 or an 8085?

      NONE!

      1. Blazde Silver badge

        Re: Impact?

        In a multi-user or multi-tasked 8085 environment you had every security problem imaginable because it had no memory protection whatsoever.

        Due to a variety of factors including - in my opinion at least - poor foresight, this wasn't fixable with a quick microcode update included in your regular patch Tuesday bundle, and so Intel were eventually forced to release an entire new chip design (the 286). Very embarrassing situation.

      2. Version 1.0 Silver badge

        Re: Impact?

        All the early Z80, 8080 multitasking problems were all in the people writing code who had grown up on single task systems and never considered multitasking before. I used to demo multi-masking to 8080 and Z80 coders and they were always amazed that it was even possible, let alone what the implications were. LOL

      3. eldakka

        Re: Impact?

        You'd be better off using early multi-tasking/time-sharing systems as a point of comparison such as the PDP-11 or VAXes than processors used in single-user systems such as the Z80 and 8085.

    2. Luke McCarthy

      Re: Impact?

      Any optimisation, either caching or prediction based on past behaviour (which is just a form of caching), is a potentially exploitable side-channel as it introduces an observable variable timing effect based on potentially privileged data. This is true for hardware or software. The only way to not leak information is for all operations to complete in a deterministic time that does not vary based on the data. This does leave a lot of clever speed up tricks on the table.

      1. Anonymous Coward
        Anonymous Coward

        Re: Impact?

        @"The only way to not leak information is for all operations to complete in a deterministic time that does not vary based on the data" or you can add "random" delay to all operations.

        There are other methods but ultimately whilst all processes share the same space then your are going to see side channel attacks however this is not compulsory, rather it was just easier/cheaper to implement it is possible to make a computer where only the messaging space is common and processes are physically limited to their assigned area.

        Shame that when multitasking became common no one thought it was necessary to also change the hardware design, beyond the CPU, so as to keep everything actually separate. Cost and IP was OFC to blame but now we know the current system is beyond repair perhaps it is time to look again, that or just accept that all computers, in their current form, are inherently insecure and untrustworthy. Yes you may mitigate but ultimately the costs of keeping with the current design are only going to increase

        1. phuzz Silver badge

          Re: Impact?

          When multitasking became common (eg on the Amiga), there was zero separation, because security was much less of a problem. Partly this was because most computers were standalone, and were never connected to a network, so all exploits required physical access.

          The big change wasn't multitasking, it was end users being much more likely to run untrusted code on their machines, eg, in the form of javascript from a website.

          1. Michael Wojcik Silver badge

            Re: Impact?

            it was end users being much more likely to run untrusted code on their machines, eg, in the form of javascript from a website

            Yes, aside from Javascript, all code running on end-user machines is entirely trustworthy. No vendor has ever released malicious code, deliberately or courtesy of a supply-chain attack.

            1. phuzz Silver badge

              Re: Impact?

              I used Javascript as a single example of untrustworthy code, that's what the "eg" means.

  4. wownwow

    Show something meaningful in the real world!

    "researchers"

    Intel paycheck collectors?

    Do vulnerabilities matter? Intel 245 but AMD less than 20, Intel won and have been pumping $Bs Q after Q!

    Not just the vulnerabilities but a lot more important is the design integrity without the cheap shortcut; Intel used partial addresses but AMD didn't!

    About using partial addresses, a cheap design shortcut:

    People who live on a street with 4-digit addresses can get in each other's houses as long as having addresses with the same last three digits, paying more for "Partial Addresses Inside", amazing!

  5. Anonymous Coward
    Anonymous Coward

    Realistically though

    There's a 200lb security vulnerability setting up the systems in most organisations, so this kind of extreme technical vulnerability is unlikely to be necessary most of the time. In the cases such as national security where this is an issue, I'm certain there are 5 more yet to be documented exploits out there which the national security people are actively using themselves.

    Personally I'm more concerned by the general lack of security knowledge in the industry, and the fact that most security "experts" were trained by firewall vendors and nobody else. The outcome is usually poor security, slow IT, and rich firewall vendors.

    1. Unicornpiss
      Meh

      Re: Realistically though

      True, IMO exploiting a vulnerability like this instead of all the other possible exploits to compromise an organization's security is like painstakingly picking a lock and ignoring the unlatched window next to the door.

  6. Anonymous Coward
    Anonymous Coward

    Digging the dirt

    Interesting that the article doesn't mention what is being reported elsewhere, which is that Intel is believed to have co-funded this security research.

    1. Peter2 Silver badge

      Re: Digging the dirt

      After the quite well known anti trust case I think people just assume that most attempted hit jobs on AMD come from their competition.

    2. phuzz Silver badge

      Re: Digging the dirt

      Or to put it another way, the university gets funding from Intel, and yet still helps out Intel's competition by finding and reporting vulnerabilities for them.

  7. Cuddles

    Not that surprising

    It often seems to be forgotten in the rush to hate on Intel, but AMD processors were vulnerable to Spectre as well, as were ARM and IBM. This has never just been an Intel problem. Intel certainly seem to have been the worst at leaving these kinds of holes, but given that everyone has already been shown to have the same problem to at least some extent, it's not at all surprising that further vulnerabilities have been found.

    1. Anonymous Coward
      Anonymous Coward

      Re: Not that surprising

      ARM, at the time, had no spectre vulnerable CPUs being produced, so you are wrong or a shill

      As to "the rush to hate Intel", where a company sells a premium product for a lot of money which is fundamentally flawed and still refuses refuses to do a recall then there are reasonable grounds for purchasers to feel that they have been abused. When the same company tries, as you have to muddy the waters rather than 'fess and pay up then dislike can only increase, when the software mitigations the same company offers reduce the performance of their CPU to a level equivalent to a different CPU for at a tiny fraction of the original's selling price then yes I can see hate raising it's ugly head and not, it must be said, without justification

      1. Michael Wojcik Silver badge

        Re: Not that surprising

        ARM, at the time, had no spectre vulnerable CPUs being produced, so you are wrong or a shill

        Irrelevant. ARM had published designs with Spectre-class side-channel vulnerabilities. The Cortex-A75 was also vulnerable to a Meltdown variant (as was POWER). The OP is correct.

  8. TeeCee Gold badge
    Meh

    ...the attacker is assumed to be able to run unprivileged native code on the target machine that's also on the same logical CPU core as the victim.

    Presumably while holding a Dodo under one arm and drinking a glass of Unicorn's milk?

    Interesting, but for an actual exploit you'd be far better off kidnapping a sysadmin and flaying his fingers until he logs you in remotely.

    1. Peter2 Silver badge

      My view when first reading about Spectre and fellow exploit classes is that they are deadly serious if you are running a virtualised enviroment and have other tenants that you don't trust running on the same physical hardware as you. eg, cloud services hosting VM's. It's obviously a really, really serious issue for people like Amazon who have a bazillion instances spun up each owned by different people who can potentially use software issues to compromise other VM's.

      When it comes to your own internal network though it's much less of a concern since by the time somebody has breached security enough to run untrusted code that's not signed (which would be blocked by normal security measures) then the possibility of an exploit that might expose things is less worrying than the fact they could be running a keylogger (if a desktop) or uploading the contents of the server.

      1. Michael Wojcik Silver badge

        Your threat model is flawed. Untrusted != privileged. And it's not at all difficult to get malicious code included in a signed package.

        1. Peter2 Silver badge

          How is it flawed? (genuine question btw, i'm quite aware I could have missed something)

          In line with Cyber Essentials requirements practically we (and one imagines most other compliant uk companies) have a default security level of "everything is blacklisted" and bits of code that run have to be individually whitelisted by hash to run.

          I'm finding it difficult to imagine the train of events that leads to a compromise in this situation. About the only realistic vector is hacking microsoft and injecting your code into one of their updates. I'd note again though that this comes under the heading of "at this point i'd be more worried about what else they could be doing".

    2. Zolko Silver badge
      Holmes

      ...native code on the target machine that's also on the same logical CPU core as the victim

      how do you even make that happen ? I mean, if you're on a normal system with thousands of processes that jump from one CPU (core) to another, how do you assure that another unrelated process from another unrelated user will be scheduled on the process you're trying to break ? I've been toying with CPU isolation things, and getting 2 processes to run on the same CPU is difficult, even if you're completely in charge of the entire system.

      To me, this "attack" isn't any actual attack as it supposes a scenario that is literally impossible without cooperation from the "victim".

      This smells like a smear-job by Intel to minimize their own (repeated) failures.

      1. Peter2 Silver badge

        The only threat that comes to mind for this entire class of threats only actually applies to vendors like Amazon where you could potentially hire a VM on a stolen credit card and then do an exploit on your VM which allows you to compromise data from another customer's VM.

        This is however probably not still a particularly useful form of attack compared to the well known Intel issues, and of course if your a normal system with servers on site on your own hardware then of course your utterly unaffected anyway since your not going to hire out a VM to a hacker.

    3. JakeMS
      Thumb Up

      Agreed

      But, I hope when they kidnap me again, they take a copy of my SSH keys, as without them I can't log them into anything remotely. :-O

  9. amanfromMars 1 Silver badge

    Meanwhile ....... Elsewhere ........

    AMD processors sold between 2011 and 2019 are vulnerable to two side-channel attacks that can extract kernel data and secrets, according to a new research paper.

    Is it realised that such attacks are also designed to insert kernel data and secrets too.

    In Order to Make Future Advanced IntelAIgent Moves which All can Follow from Source to Destination in Preparation for the Enjoyment of All Newly Arrived there.

    Here too, for truth to be told. :-)

  10. Cynic_999

    Fear mongering

    From the description given, I very much doubt that there is any way in practice for anyone to usefully exploit this vector "in the wild". Like many other recently published vulnerabilities, it is very much theoretical and could only work in a carefully stage-managed artificial situation where far more variables are known than would be the case in any real-life situation. Unless I see something to the contrary, I will continue to believe that the idea that a bit of java code could use this to extract an encryption key is very far-fetched.

    1. jeffdyer

      Re: Fear mongering

      So process B can read memory written by Process A. Unless B knows exactly what is stored there, it is of no use whatsoever.

      1. Michael Wojcik Silver badge

        Re: Fear mongering

        Have you read any of the papers? Even the original Spectre paper demonstrated a useful attack. Demonstrated, not just proposed.

        The willful ignorance around this class of attack is really quite impressive. None of these papers are hard to get or read.

        1. Cynic_999

          Re: Fear mongering

          "

          Demonstrated, not just proposed.

          "

          If it's the same demo I saw, it comprised of a command line program producing an unexplained output that was claimed to be the contents of memory locations that the code should not have had access to. As a proof of concept that the bug existed it was fine. It was not however claimed that anyone knew what data the memory locations in question were used to store, or that it could be made to target any specific content, so its usefulness to a criminal hacker is rather dubious. Snooping on random locations in several GB of RAM to try to spot something of use to the miscreant would be more time-consuming than a brute-force attack on securely encrypted data.

          I would need to see a demo of something useful - such as something that was extracting an encryption key or other sensitive data from a system that it was not uniquely tailored for.

    2. amanfromMars 1 Silver badge

      Re: Fear mongering with an unknown and/or cynically denied asset?

      it is very much theoretical and could only work in a carefully stage-managed artificial situation where far more variables are known than would be the case in any real-life situation. ..... Cynic_999

      So, and I would not disagree, Cynic_999, it is certainly practical and easily works in VM and AI environments ....... which are important leading sectors and vectors in an ever increasing number of real-life situations.

      And I would also most wilfully agree with Michael Wojcik if they were to say .... The ignorance around this class of attack is really quite impressive.

      And that ignorance provides a very effective stealth which covers and protects unrivalled progress in novel genres.

      And yes, of course it is weaponised to be particularly deadly against certain targets destined for meltdown and destruction/fundamental disruption.

  11. Anonymous Coward
    Boffin

    [ ... ] Meltdown, a far stronger attack, doesn't appear to have been weaponized by anyone.

    Absence of evidence is not evidence of absence. As they used to say.

    If it can be weaponized [ yes, it can ], it's been weaponized already. Meltdown-based attacks don't leave fingerprints behind.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like