5 ms·

Almost as disgusting as Intel's response. > "It is important to note that this method is dependent on malware running locally which means it's imperative for u

Almost as disgusting as Intel's response. > "It is important to note that this method is dependent on malware running locally which means it's imperative for users to practice good security hygiene by keeping their software up-to-date and avoid suspicious links or downloads." If you're running something on your ARM CPU, it's running locally!, they're using careful language to make the problem seem to impact them less than it does and lay the blame on the user. This affects a huge number of processors out there, not just in phones and tablets but in embedded, industrial and network devices - many of which will never seem workarounds from their OS / software for the hardware fault. Also OH: "The bug doesn’t happen if you don’t use our product"

ENOTTY 9y ago
None of the Cortex M cores seem to be affected, according to ARM. These are the ones mostly used in embedded applications.
- andrewcchen 9y ago
  Cortex M cores don't have MMUs, so they cannot be affected. Also in embedded applications you would only be running trusted code anyway
  - sitharus 9y ago
    The MMU isn't part of this attack, and there are ARM cores with MMUs that are not affected. Cortex M cores are in-order CPUs, so they do not have branch prediction or perform speculative execution which the attacks rely on.
    - userbinator 9y ago
      The attack is all about bypassing memory protection, which without an MMU to provide any, is moot --- code has access to all of memory to read normally anyway.
      - TickleSteve 9y ago
        Cortex-M has an MPU, not MMU to provide protection for memory regions. But as said above, the MPU/MMU has no effect on this bug, this is ab out speculative execution and determining information from a cache side channel attack.
- mrmondo 9y ago
  ‘M’ just stands for microcontroller, as apposed to ‘A’ for application. Many / most complex or multitasking embedded devices will use ‘A’ series to meet their processing requirements, e.g. network routing + OS + firmware / OS programming and multiuser processsing. I probably should have better qualified my use of the term ‘embedded’.
  - hinkley 9y ago
    But it does affect the processors used on the Beaglebone and older Raspberry Pi devices.
    - frik 9y ago
      It does not affect Raspberry Pi devices to my knowledge. Please provide source for your claims! The CPUs in Raspberry Pi 1-3 are not affected. ARM11, Cortex-A7, Cortex-A5 Raspberry Pi 2 v1 use a Broadcom BCM2836 SoC with a 900 MHz 32-bit quad-core ARM Cortex-A7 processor. Raspberry Pi 3 (and Pi 2 v1.2) uses a Broadcom BCM2837 SoC with a 1.2 GHz 64-bit quad-core ARM Cortex-A53 processor. According to ARM website https://developer.arm.com/support/security-update https://developer.arm.com/support/security-update it especially says "*Only affected cores are listed, all other Arm cores are NOT affected.*" and it lists only "Cortex-R7, Cortex-R8, Cortex-A8, Cortex-A9, Cortex-A15, Cortex-A17, Cortex-A57, Cortex-A72, Cortex-A73, Cortex-A75"
      - hinkley 9y ago
        and older Raspberry Pi devices https://www.raspberrypi.org/products/raspberry-pi-2-model-b/ https://www.raspberrypi.org/products/raspberry-pi-2-model-b/ But it looks like I confused the Cortex-A7 with the Cortex-R7, which is not listed.
- sitharus 9y ago
  Cortex M and all ARM-developed cores prior to v7 are in-order CPUs, so they do not do branch prediction or speculative execution. Without branch prediction this kind of issue cannot exist.
  - rayiner 9y ago
    In-order CPUs (e.g. Pentium 1, older Atom and ARM chips, POWER 6) perform branch prediction and speculative execution. They'll predict the branch and start speculatively decoding and executing instructions from the predicted target, then flush the pipeline if there was a misprediction. What they won't do is execute past an instruction that has an unresolved data dependency.
    - sitharus 9y ago
      You're right, I was conflating two things. It looks like no in-order ARM cores have branch prediction though.
userbinator 9y ago
Their response makes perfect sense and is a careful contrast to the "everything is broken" hysteria from the other side. This isn't like Heartbleed or a remote code execution vulnerability --- the attacker has to be able to run very specific code on the processor in order to exploit anything. Thus they are basically saying "you're fine if you don't run untrusted code" --- something which bears repeating since it is the only positive thing in this whole debacle. but in embedded, industrial and network devices - many of which will never seem workarounds from their OS / software for the hardware fault. ...many of which won't ever run anything but the original firmware they came with from the factory anyway, making it a somewhat moot point (and if there are exploits that lead to remote code execution, chances are there are better things for an attacker to go after than try to exploit a timing side-channel.) The ones most affected by this are cloud providers and other scenarios where multiple mutually untrusting users are sharing the same hardware on which they can run arbitrary code. The ones least affected (i.e. not at all) are isolated single-user/single-purpose machines running trusted code. This includes the majority of embedded systems, which is presumably why ARM is emphasising the point so much compared to Intel or AMD.
- flukus 9y ago
  > Thus they are basically saying "you're fine if you don't run untrusted code" --- something which bears repeating since it is the only positive thing in this whole debacle. Except for that whole web thing that has most of the world running untrusted code just about every minute of every day. Security hygiene doesn't protect you from this.
  - userbinator 9y ago
    Except for that whole web thing that has most of the world running untrusted code just about every minute of every day Certainly those who e.g. have JS off by default are currently in the minority, but perhaps this will be the defining event that causes everyone else to think more deeply about letting untrusted code run, regardless of how sandboxed it is. Things like TEMPEST[1] have shown for many years that side-channel attacks are extremely difficult to defend against, even for an attacker who is merely in proximity to the hardware and can't influence it at all; nevermind running code directly on it. It was only a matter of time. A lot of malware researchers already don't trust VMs and use separate physical hardware, precisely because of these risks of sharing trusted and untrusted code on the same hardware. [1] https://en.wikipedia.org/wiki/TEMPEST https://en.wikipedia.org/wiki/TEMPEST
tedivm 9y ago
Yeah this bothered me as well. It's not just a matter of not clicking suspicious links or downloads, apparently (according to the Spectre pdf) there's a javascript vulnerability for this. What does a suspicious page even mean anyways, and how does the average user determine that before clicking?

ENOTTY 9y ago

None of the Cortex M cores seem to be affected, according to ARM. These are the ones mostly used in embedded applications.

andrewcchen 9y ago
Cortex M cores don't have MMUs, so they cannot be affected. Also in embedded applications you would only be running trusted code anyway
- sitharus 9y ago
  The MMU isn't part of this attack, and there are ARM cores with MMUs that are not affected. Cortex M cores are in-order CPUs, so they do not have branch prediction or perform speculative execution which the attacks rely on.
  - userbinator 9y ago
    The attack is all about bypassing memory protection, which without an MMU to provide any, is moot --- code has access to all of memory to read normally anyway.
    - TickleSteve 9y ago
      Cortex-M has an MPU, not MMU to provide protection for memory regions. But as said above, the MPU/MMU has no effect on this bug, this is ab out speculative execution and determining information from a cache side channel attack.
mrmondo 9y ago
‘M’ just stands for microcontroller, as apposed to ‘A’ for application. Many / most complex or multitasking embedded devices will use ‘A’ series to meet their processing requirements, e.g. network routing + OS + firmware / OS programming and multiuser processsing. I probably should have better qualified my use of the term ‘embedded’.
- hinkley 9y ago
  But it does affect the processors used on the Beaglebone and older Raspberry Pi devices.
  - frik 9y ago
    It does not affect Raspberry Pi devices to my knowledge. Please provide source for your claims! The CPUs in Raspberry Pi 1-3 are not affected. ARM11, Cortex-A7, Cortex-A5 Raspberry Pi 2 v1 use a Broadcom BCM2836 SoC with a 900 MHz 32-bit quad-core ARM Cortex-A7 processor. Raspberry Pi 3 (and Pi 2 v1.2) uses a Broadcom BCM2837 SoC with a 1.2 GHz 64-bit quad-core ARM Cortex-A53 processor. According to ARM website https://developer.arm.com/support/security-update https://developer.arm.com/support/security-update it especially says "*Only affected cores are listed, all other Arm cores are NOT affected.*" and it lists only "Cortex-R7, Cortex-R8, Cortex-A8, Cortex-A9, Cortex-A15, Cortex-A17, Cortex-A57, Cortex-A72, Cortex-A73, Cortex-A75"
    - hinkley 9y ago
      and older Raspberry Pi devices https://www.raspberrypi.org/products/raspberry-pi-2-model-b/ https://www.raspberrypi.org/products/raspberry-pi-2-model-b/ But it looks like I confused the Cortex-A7 with the Cortex-R7, which is not listed.
sitharus 9y ago
Cortex M and all ARM-developed cores prior to v7 are in-order CPUs, so they do not do branch prediction or speculative execution. Without branch prediction this kind of issue cannot exist.
- rayiner 9y ago
  In-order CPUs (e.g. Pentium 1, older Atom and ARM chips, POWER 6) perform branch prediction and speculative execution. They'll predict the branch and start speculatively decoding and executing instructions from the predicted target, then flush the pipeline if there was a misprediction. What they won't do is execute past an instruction that has an unresolved data dependency.
  - sitharus 9y ago
    You're right, I was conflating two things. It looks like no in-order ARM cores have branch prediction though.

userbinator 9y ago

Their response makes perfect sense and is a careful contrast to the "everything is broken" hysteria from the other side. This isn't like Heartbleed or a remote code execution vulnerability --- the attacker has to be able to run very specific code on the processor in order to exploit anything. Thus they are basically saying "you're fine if you don't run untrusted code" --- something which bears repeating since it is the only positive thing in this whole debacle. but in embedded, industrial and network devices - many of which will never seem workarounds from their OS / software for the hardware fault. ...many of which won't ever run anything but the original firmware they came with from the factory anyway, making it a somewhat moot point (and if there are exploits that lead to remote code execution, chances are there are better things for an attacker to go after than try to exploit a timing side-channel.) The ones most affected by this are cloud providers and other scenarios where multiple mutually untrusting users are sharing the same hardware on which they can run arbitrary code. The ones least affected (i.e. not at all) are isolated single-user/single-purpose machines running trusted code. This includes the majority of embedded systems, which is presumably why ARM is emphasising the point so much compared to Intel or AMD.

flukus 9y ago
> Thus they are basically saying "you're fine if you don't run untrusted code" --- something which bears repeating since it is the only positive thing in this whole debacle. Except for that whole web thing that has most of the world running untrusted code just about every minute of every day. Security hygiene doesn't protect you from this.
- userbinator 9y ago
  Except for that whole web thing that has most of the world running untrusted code just about every minute of every day Certainly those who e.g. have JS off by default are currently in the minority, but perhaps this will be the defining event that causes everyone else to think more deeply about letting untrusted code run, regardless of how sandboxed it is. Things like TEMPEST[1] have shown for many years that side-channel attacks are extremely difficult to defend against, even for an attacker who is merely in proximity to the hardware and can't influence it at all; nevermind running code directly on it. It was only a matter of time. A lot of malware researchers already don't trust VMs and use separate physical hardware, precisely because of these risks of sharing trusted and untrusted code on the same hardware. [1] https://en.wikipedia.org/wiki/TEMPEST https://en.wikipedia.org/wiki/TEMPEST

tedivm 9y ago

Yeah this bothered me as well. It's not just a matter of not clicking suspicious links or downloads, apparently (according to the Spectre pdf) there's a javascript vulnerability for this. What does a suspicious page even mean anyways, and how does the average user determine that before clicking?