10 ms·

[Ignorant tangent] Is core hardware more exploited these days or are vulnerabilities just more reported in tech news? I'd assume the former, but I'm not a hardw

by sf_rob 7y ago

[Ignorant tangent] Is core hardware more exploited these days or are vulnerabilities just more reported in tech news? I'd assume the former, but I'm not a hardware person. If so is this just due to increasing complexity/optimization going on in chip design or better tooling/methods of exploitation?

josh2600 7y ago
As far as I know there has never been an enclave attack found in a rootkit in the wild. This is probably because there hasn't been anything publicly obviously worth stealing in an enclave yet.
- sulam 7y ago
  Really? Credit card tokens aren't valuable enough? Device-specific private keys? These secure enclaves are routinely used for extremely sensitive data, surely it's more worth stealing than someone's WiFi credentials.
  - josh2600 7y ago
    It’s not obvious to me that credit card tokens are fungible enough (or stored in SGX). They’re also a highly insured asset with manageable counterparty risk. Edit: So yeah, I'm not sure it's worth all of the complexity of an SGX attack. There are probably easier ways to get the credit cards.
  - gowld 7y ago
    Not really, because if your device is owned, they can read your credit card info from the main OS environment. Secure enclave us really about protecting the device from being stolen and taken over, not protecting important secrets. An attacker doesn't want to remotely steal your iPhone or laptop. At most they want to unlock it after they steal the physical device. Injecting a bios worm into a data center is more of a concern.
    - sulam 7y ago
      This is actually not accurate. The payments loop is entirely closed in an SE-based system. There are keys loaded on the enclave in manufacturing that come from the card networks, they encrypt tokens on the way to the SE and they can only be decrypted on the SE itself. Then during an actual transaction there is another encrypted exchange over RFID and again the encrypted blob is generated by an applet on the SE.
      - paulmd 7y ago
        Sure, that's the theory, but I'm not sure a "SE-based" system as you describe it is actually used at all, or certainly for any non-trivial volume of transactions, in an Intel-based (desktop/laptop) environment. I've never used a web store checkout system that wasn't based on browser forms, or any mechanism that felt like asking a secure enclave to sign a transaction. Google Chrome offers to store your credit card numbers for you, but that's just so it can autofill web forms. Apple Pay or whatever, sure, on their hardware. Macbooks, I'd think it uses the touchbar secure enclave. But nothing really uses SGX on Intel except Netflix DRM.
  - strbean 7y ago
    Credit cards with complete billing info sell for what... 50 cents a piece? If you're rooting a payment processor, maybe a worthwhile target, although you could probably do much better than steal card numbers. A consumer device? Not so much.
    - SirYandi 7y ago
      I've usually seen them on onion markets for around $5 for those without any guaranteed available balance. Not that I've bought one or ever would.
      - strbean 7y ago
        Interesting. I haven't looked in a long time, but my vague recollection is of bulk card data being sold much cheaper than that. I could be totally incorrect though!
        yjftsjthsd-h 7y ago
        I mean, you'd expect verified data to sell for more than unvetted bulk dumps, yeah?
      - tomc1985 7y ago
        Most of the real sales are on carder forums. https://krebsonsecurity.com/ https://krebsonsecurity.com/ writes in-depth from infiltrating some of them if you're curious
  - dnautics 7y ago
    Is that really the case? If I'm not mistaken, secure enclaves have a different security model than the use cases you're suggesting: They are so a third party can run software on a user's machine without trusting the user. For example, delivering encrypted drm software to a customer that might be trying to crack it.
    - jdsully 7y ago
      It's so you can run software without trusting the operating system. And by extension that implies the root user as well, but that's not always the use case (it is for DRM). E.g. you might want your credit card processing in an enclave even if it's your own card, simply to hide it from any rootkits or malware you may have installed.
      - ptx 7y ago
        For the user, there is no real point to such a separation. If the system is full of rootkits and malware, the credit card can be hijacked through for the browser, for example. You don't need to get at the actual credit card processing if you can control all inputs and outputs.
- Causality1 7y ago
  As far as I know there's never been an in the wild system compromised based on Spectre either.
  - josh2600 7y ago
    I don’t think this entire class of processor attacks have ever been seen outside of academia (yet).
deleted 7y ago
[deleted]
chandlerc1024 7y ago
We're seeing the exploration of a new surface through speculative execution and related hardware techniques. There is basically a backlog of exploring this surface that researchers and security folks in industry are working to process. Eventually will settle into a more steady state, but takes a long while to push through the new territory.
- SemiTom 7y ago
  An expanding attack surface in hardware, coupled with increasing complexity inside and outside of chips, is making it far more difficult to secure systems against a variety of new and existing types of attacks https://semiengineering.com/hardware-attack-surface-widening/ https://semiengineering.com/hardware-attack-surface-widening.... Per Paul Kocher “AI will help attackers in a number of ways, where behaviors that used to be unique to humans can now be automated in ways that are lot harder to distinguish from humans"
akiselev 7y ago
It's probably a bit of both. Intel started implementing speculative execution decades ago but the first exploits like Specter/Meltdown weren't published until a few years ago so that alone is strong evidence that there might be ancient attack vectors that we haven't even considered yet. On the other hand, interest in this topic among the public has definitely grown since branding departments started getting their hands on the exploits and Bloomberg published that sensationalist Micro story so it's a self reinforcing cycle.
- WrtCdEvrydy 7y ago
  Interestingly, there was a 1998 paper about speculative execution that basically outlined all of Spectre/Meltdown.
  - akga 7y ago
    Sounds interesting. Do you have a link to it?
    - Kurakuan 7y ago
      I'm not sure if there was another paper in '98, but this one in 1995 may be the one being referenced: https://web.archive.org/web/20180506083456/https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f6536c91aaf7756857.pdf https://web.archive.org/web/20180506083456/https://pdfs.sema...
  - cpach 7y ago
    And 'cperciva found some weird stuff long before Spectre. He reported to Intel and their reply was basically “meh”.
    - cperciva 7y ago
      Intel is a very different company in 2020 than they were in 2005.
      - 7y ago
piinthesky 7y ago
All multicore cpu's are insecure, just like CPU virtualisation is highly exploitable, its just no one has documented how and what to exploit yet, so "legally" it doesnt exist yet, but bit by bit more HW exploits are being discovered. Very few people really really understand how these systems work, and there's plenty of hubris knocking about the IT sector.
gowld 7y ago
"Hardware" runs a lot more complex software nowadays than in the past. So it's more exploitable. Also, tools for probing hardware are more available and affordable.
willis936 7y ago
Whenever I wonder this, I always think back to wargames’ example of phone phreaking. The answer seems obvious: early hardware/software was insanely easy to exploit because hardware/software security was not a thing. It was trivial to use features in a malicious way. We’re currently in an arms race because eventually society decided it wanted computer security. That’s not to say systems were all insecure in the past. You just didn’t trust computers to be secure.
- ghaff 7y ago
  Computers were also a lot less connected to communications channels that could be used to break in.
blihp 7y ago
All of the above. Greater complexity/more features, people dedicated to finding vulnerabilities, more news coverage of vulnerabilities, more money to be made from exploiting vulnerabilities and general complacency from Intel. Given the lack of serious competition in the high performance space until recently, Intel figured they could get away with their rather slow and unimpressive response which basically boiled down to kneecapping recent processors and telling owners of older ones to just buy a new computer. Compare and contrast their handling of the stream of vulnerabilities in the past few years to the FDIV bug in the 90's. The FDIV bug was the first time I remember a hardware bug making national news. Intel just about shit themselves over this apologizing profusely, offering free processor swaps, billion dollar write down, talking about how this would never happen again etc. A big part of the reason they took it so seriously was that there were still a number of other alternative CPU manufacturers trying to compete with Intel at the time and it was far from certain that x86 would become the undisputed ISA for PCs. (this was pre-Windows 95) All this, and the vast majority of people would never ever experience the FDIV bug even if their processor had it. Times change, but the lesson remains the same: competition is good.
- wbl 7y ago
  Fixing FDIV was simple. Fixing Spectre creates some very painful performance tradeoffs.
cesarb 7y ago
What happened is that Spectre was the first instance of a new class of vulnerabilities, one which hadn't been considered previously. Side-channel attacks were already well known, but nobody seemed to have considered side channels from speculative execution before (it's hard to overstate how bizarre these vulnerabilities look like, from a software point of view: they're leaking information from a code path which has not been executed, could not execute, and in some cases doesn't even exist; that is, when looking only at the software, the leak appears to come from a parallel universe where an impossible code path actually executed). Since this vulnerability class was previously unknown, hardware didn't have much protection against it, except by accident (or as a side effect of more conservative design). Being in hardware, they are difficult or impossible to workaround in software. And they were found in common hardware most people have. This all lead to them being widely reported by the tech press.
- gitgudnubs 7y ago
  Almost, but plenty of computer architects speculated about vulnerabilities in speculative execution. It just seemed infeasible. The attack can differ based on the particular architecture (cache hierarchy, associativity, latency per instruction, buffer sizes...), clock speed, microcode, workloads, temperature, and a thousand other variables. Spectre was more impressive than a new idea: it was a brilliant execution of an idea that every architect eventually had. Rowhammer was similar. Everyone knew that it was possible to get boned by physics, but it can happen at an arbitrary place in an arbitrary way that isn't captured by any model. Rowhammer wasn't impressive because it was an idea, but because it was a simple, obvious in retrospect, way to exploit physics to bypass the models.
  - pixl97 7y ago
    >Almost, but plenty of computer architects speculated about I remember reading papers in the mid to later 90s on just this topic, in regard to processing on top secret systems. Most of the infeasiblility at the time was of running code on remote systems at the same time. Things like javascript were not everywhere at the time and most computers only had one core.
Twirrim 7y ago
Part of this is just that eyes are suddenly focussed on it. It's a repeated pattern in the tech industry. Several years ago it felt like we barely went a week between Flash vulnerabilities. Then someone found a major vulnerability in the JVM, and that became the centre of attention, and it felt like we were having to patch the JVM every single month. Then something else came along and all eyes got focussed on that... rinse, repeat. Right now the CPU is becoming a focus. We've probably got another couple of years of this before it'll settle down. CPU is interesting because it's a lot harder to exploit, it's much less by way of finding low hanging fruit, unlike Flash and JVM.
- fl0wenol 7y ago
  It's because normalization of "cloud" brought into clear focus you're running your business critical code on other people's computers, along with other customers' code. And now that code can adversarial effect you? That's why it became such a hot topic.
gitgudnubs 7y ago
There are more hardware exploits. New classes of exploits using physics and side-channels are circumventing the formal models used to build CPUs. CPU designers have made complex architectural decisions to speed up execution. In the case of spectre, it's to speed up single-threaded execution. In the case of this, it's to optimize security features. An analogous case is AES256, which was chosen because it's fast. But it's fast because the s-boxes use the private key as an index into an array, so there's caching. But this introduces a side-channel, because based on time to execute you can infer the private key.

by sf_rob 7y ago

josh2600 7y ago

As far as I know there has never been an enclave attack found in a rootkit in the wild. This is probably because there hasn't been anything publicly obviously worth stealing in an enclave yet.

sulam 7y ago
Really? Credit card tokens aren't valuable enough? Device-specific private keys? These secure enclaves are routinely used for extremely sensitive data, surely it's more worth stealing than someone's WiFi credentials.
- josh2600 7y ago
  It’s not obvious to me that credit card tokens are fungible enough (or stored in SGX). They’re also a highly insured asset with manageable counterparty risk. Edit: So yeah, I'm not sure it's worth all of the complexity of an SGX attack. There are probably easier ways to get the credit cards.
- gowld 7y ago
  Not really, because if your device is owned, they can read your credit card info from the main OS environment. Secure enclave us really about protecting the device from being stolen and taken over, not protecting important secrets. An attacker doesn't want to remotely steal your iPhone or laptop. At most they want to unlock it after they steal the physical device. Injecting a bios worm into a data center is more of a concern.
  - sulam 7y ago
    This is actually not accurate. The payments loop is entirely closed in an SE-based system. There are keys loaded on the enclave in manufacturing that come from the card networks, they encrypt tokens on the way to the SE and they can only be decrypted on the SE itself. Then during an actual transaction there is another encrypted exchange over RFID and again the encrypted blob is generated by an applet on the SE.
    - paulmd 7y ago
      Sure, that's the theory, but I'm not sure a "SE-based" system as you describe it is actually used at all, or certainly for any non-trivial volume of transactions, in an Intel-based (desktop/laptop) environment. I've never used a web store checkout system that wasn't based on browser forms, or any mechanism that felt like asking a secure enclave to sign a transaction. Google Chrome offers to store your credit card numbers for you, but that's just so it can autofill web forms. Apple Pay or whatever, sure, on their hardware. Macbooks, I'd think it uses the touchbar secure enclave. But nothing really uses SGX on Intel except Netflix DRM.
- strbean 7y ago
  Credit cards with complete billing info sell for what... 50 cents a piece? If you're rooting a payment processor, maybe a worthwhile target, although you could probably do much better than steal card numbers. A consumer device? Not so much.
  - SirYandi 7y ago
    I've usually seen them on onion markets for around $5 for those without any guaranteed available balance. Not that I've bought one or ever would.
    - strbean 7y ago
      Interesting. I haven't looked in a long time, but my vague recollection is of bulk card data being sold much cheaper than that. I could be totally incorrect though!
      - yjftsjthsd-h 7y ago
        I mean, you'd expect verified data to sell for more than unvetted bulk dumps, yeah?
    - tomc1985 7y ago
      Most of the real sales are on carder forums. https://krebsonsecurity.com/ https://krebsonsecurity.com/ writes in-depth from infiltrating some of them if you're curious
- dnautics 7y ago
  Is that really the case? If I'm not mistaken, secure enclaves have a different security model than the use cases you're suggesting: They are so a third party can run software on a user's machine without trusting the user. For example, delivering encrypted drm software to a customer that might be trying to crack it.
  - jdsully 7y ago
    It's so you can run software without trusting the operating system. And by extension that implies the root user as well, but that's not always the use case (it is for DRM). E.g. you might want your credit card processing in an enclave even if it's your own card, simply to hide it from any rootkits or malware you may have installed.
    - ptx 7y ago
      For the user, there is no real point to such a separation. If the system is full of rootkits and malware, the credit card can be hijacked through for the browser, for example. You don't need to get at the actual credit card processing if you can control all inputs and outputs.
Causality1 7y ago
As far as I know there's never been an in the wild system compromised based on Spectre either.
- josh2600 7y ago
  I don’t think this entire class of processor attacks have ever been seen outside of academia (yet).

deleted 7y ago

[deleted]

chandlerc1024 7y ago

We're seeing the exploration of a new surface through speculative execution and related hardware techniques. There is basically a backlog of exploring this surface that researchers and security folks in industry are working to process. Eventually will settle into a more steady state, but takes a long while to push through the new territory.

SemiTom 7y ago
An expanding attack surface in hardware, coupled with increasing complexity inside and outside of chips, is making it far more difficult to secure systems against a variety of new and existing types of attacks https://semiengineering.com/hardware-attack-surface-widening/ https://semiengineering.com/hardware-attack-surface-widening.... Per Paul Kocher “AI will help attackers in a number of ways, where behaviors that used to be unique to humans can now be automated in ways that are lot harder to distinguish from humans"

akiselev 7y ago

It's probably a bit of both. Intel started implementing speculative execution decades ago but the first exploits like Specter/Meltdown weren't published until a few years ago so that alone is strong evidence that there might be ancient attack vectors that we haven't even considered yet. On the other hand, interest in this topic among the public has definitely grown since branding departments started getting their hands on the exploits and Bloomberg published that sensationalist Micro story so it's a self reinforcing cycle.

WrtCdEvrydy 7y ago
Interestingly, there was a 1998 paper about speculative execution that basically outlined all of Spectre/Meltdown.
- akga 7y ago
  Sounds interesting. Do you have a link to it?
  - Kurakuan 7y ago
    I'm not sure if there was another paper in '98, but this one in 1995 may be the one being referenced: https://web.archive.org/web/20180506083456/https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f6536c91aaf7756857.pdf https://web.archive.org/web/20180506083456/https://pdfs.sema...
- cpach 7y ago
  And 'cperciva found some weird stuff long before Spectre. He reported to Intel and their reply was basically “meh”.
  - cperciva 7y ago
    Intel is a very different company in 2020 than they were in 2005.
    - 7y ago

piinthesky 7y ago

All multicore cpu's are insecure, just like CPU virtualisation is highly exploitable, its just no one has documented how and what to exploit yet, so "legally" it doesnt exist yet, but bit by bit more HW exploits are being discovered. Very few people really really understand how these systems work, and there's plenty of hubris knocking about the IT sector.

gowld 7y ago

"Hardware" runs a lot more complex software nowadays than in the past. So it's more exploitable. Also, tools for probing hardware are more available and affordable.

willis936 7y ago

Whenever I wonder this, I always think back to wargames’ example of phone phreaking. The answer seems obvious: early hardware/software was insanely easy to exploit because hardware/software security was not a thing. It was trivial to use features in a malicious way. We’re currently in an arms race because eventually society decided it wanted computer security. That’s not to say systems were all insecure in the past. You just didn’t trust computers to be secure.

ghaff 7y ago
Computers were also a lot less connected to communications channels that could be used to break in.

blihp 7y ago

All of the above. Greater complexity/more features, people dedicated to finding vulnerabilities, more news coverage of vulnerabilities, more money to be made from exploiting vulnerabilities and general complacency from Intel. Given the lack of serious competition in the high performance space until recently, Intel figured they could get away with their rather slow and unimpressive response which basically boiled down to kneecapping recent processors and telling owners of older ones to just buy a new computer. Compare and contrast their handling of the stream of vulnerabilities in the past few years to the FDIV bug in the 90's. The FDIV bug was the first time I remember a hardware bug making national news. Intel just about shit themselves over this apologizing profusely, offering free processor swaps, billion dollar write down, talking about how this would never happen again etc. A big part of the reason they took it so seriously was that there were still a number of other alternative CPU manufacturers trying to compete with Intel at the time and it was far from certain that x86 would become the undisputed ISA for PCs. (this was pre-Windows 95) All this, and the vast majority of people would never ever experience the FDIV bug even if their processor had it. Times change, but the lesson remains the same: competition is good.

wbl 7y ago
Fixing FDIV was simple. Fixing Spectre creates some very painful performance tradeoffs.

cesarb 7y ago

What happened is that Spectre was the first instance of a new class of vulnerabilities, one which hadn't been considered previously. Side-channel attacks were already well known, but nobody seemed to have considered side channels from speculative execution before (it's hard to overstate how bizarre these vulnerabilities look like, from a software point of view: they're leaking information from a code path which has not been executed, could not execute, and in some cases doesn't even exist; that is, when looking only at the software, the leak appears to come from a parallel universe where an impossible code path actually executed). Since this vulnerability class was previously unknown, hardware didn't have much protection against it, except by accident (or as a side effect of more conservative design). Being in hardware, they are difficult or impossible to workaround in software. And they were found in common hardware most people have. This all lead to them being widely reported by the tech press.

gitgudnubs 7y ago
Almost, but plenty of computer architects speculated about vulnerabilities in speculative execution. It just seemed infeasible. The attack can differ based on the particular architecture (cache hierarchy, associativity, latency per instruction, buffer sizes...), clock speed, microcode, workloads, temperature, and a thousand other variables. Spectre was more impressive than a new idea: it was a brilliant execution of an idea that every architect eventually had. Rowhammer was similar. Everyone knew that it was possible to get boned by physics, but it can happen at an arbitrary place in an arbitrary way that isn't captured by any model. Rowhammer wasn't impressive because it was an idea, but because it was a simple, obvious in retrospect, way to exploit physics to bypass the models.
- pixl97 7y ago
  >Almost, but plenty of computer architects speculated about I remember reading papers in the mid to later 90s on just this topic, in regard to processing on top secret systems. Most of the infeasiblility at the time was of running code on remote systems at the same time. Things like javascript were not everywhere at the time and most computers only had one core.

Twirrim 7y ago

Part of this is just that eyes are suddenly focussed on it. It's a repeated pattern in the tech industry. Several years ago it felt like we barely went a week between Flash vulnerabilities. Then someone found a major vulnerability in the JVM, and that became the centre of attention, and it felt like we were having to patch the JVM every single month. Then something else came along and all eyes got focussed on that... rinse, repeat. Right now the CPU is becoming a focus. We've probably got another couple of years of this before it'll settle down. CPU is interesting because it's a lot harder to exploit, it's much less by way of finding low hanging fruit, unlike Flash and JVM.

fl0wenol 7y ago
It's because normalization of "cloud" brought into clear focus you're running your business critical code on other people's computers, along with other customers' code. And now that code can adversarial effect you? That's why it became such a hot topic.

gitgudnubs 7y ago

There are more hardware exploits. New classes of exploits using physics and side-channels are circumventing the formal models used to build CPUs. CPU designers have made complex architectural decisions to speed up execution. In the case of spectre, it's to speed up single-threaded execution. In the case of this, it's to optimize security features. An analogous case is AES256, which was chosen because it's fast. But it's fast because the s-boxes use the private key as an index into an array, so there's caching. But this introduces a side-channel, because based on time to execute you can infer the private key.