[HN Gopher] New flaw in Intel chips lets attackers slip their ow...
___________________________________________________________________
New flaw in Intel chips lets attackers slip their own data into
secure enclave
Author : jbegley
Score : 326 points
Date : 2020-03-10 17:04 UTC (5 hours ago)
(HTM) web link (techcrunch.com)
(TXT) w3m dump (techcrunch.com)
| kumarski wrote:
| efabless becomes more and more relevant every day.
| bayindirh wrote:
| I'm considering to upgrade my primary computer this summer and
| considering an AMD system. Following is my thought process:
|
| - Maybe I should buy an Intel system again because of the
| performance counters and other nice things.
|
| _Another Intel attack surfaces_
|
| - Yep, I shall go AMD this time...
| MatthiasP wrote:
| There are good reasons to go with AMD over Intel CPUs at the
| moment, the number of published security exploits should not be
| one. There is nothing fundamentally more insecure in the
| Skylake CPU architecture than in Zen 2, just one has more
| marketshare and gets scrutinized more intensely.
| kllrnohj wrote:
| > There is nothing fundamentally more insecure in the Skylake
| CPU architecture than in Zen 2
|
| Except there is. Hence why Skylake suffered from Meltdown
| while AMD didn't. Skylake's design is to do ACL checks at
| instruction retirement instead of up front. AMD's is the
| reverse.
|
| Software workarounds for Meltdown exist, yes, but the Skylake
| architecture still fundamentally has that insecure design.
| [deleted]
| mynameisvlad wrote:
| https://www.techspot.com/news/84309-amd-cpus-vulnerable-seve...
|
| From 2 days ago, in case you weren't aware.
| temac wrote:
| The "new" AMD attack depends on lack of already existing
| spectre mitigations. If I understand correctly, this one is a
| real new one that works against a correctly patched system.
| cosmiccatnap wrote:
| You are correct. No AMD vulnerability is in the same
| universe as the Intel vulnerabilities from this year alone.
| Good luck on your new build
| paulmd wrote:
| the new AMD attack effectively breaks KASLR (the "metadata"
| that the attack reveals is page table layouts) and AMD has
| announced they're not going to patch it.
|
| itself it's not a problem but if you pair it with something
| else it destroys a major line of defense against that
| something else.
|
| AMD is still architecturally vulnerable to some variants of
| SPECTRE, they just consider it "hard to exploit", but they
| do recommend you run KASLR to harden against it. Well, so
| much for that.
| spectramax wrote:
| "Fanboyism" needs to stop for AMD and Intel. It's clouding
| facts and objectivity. These days people have a hard on for AMD
| as if it's some kind of a religious messiah saving them from
| doom.
|
| It bothers me and I don't really understand. There are some
| really vile comments about Intel and unreasonable praise for
| AMD - simply because it's the "underdog". What is this? Some
| kind of a sport that one is rooting for the "underdog". It's a
| multi billion dollar corporation.
| ghusbands wrote:
| The post you're replying to fairly clearly states that
| security issues in Intel chips are pushing them to buy AMD,
| next. It doesn't look at all like "fanboyism".
| spectramax wrote:
| I'm just talking about the general theme of AMD/Intel
| discussions on HN. There is a heavy bias for AMD, not just
| on HN but everywhere on the internet. Just go to Anandtech
| forums.
|
| I should clarify that my frustration isn't about what the
| OP said. It's a general observation.
| BoorishBears wrote:
| You're a hundred percent right and I've noted it before,
| but this is exactly what happens if you call it out (your
| post gets buried) because there's a nice mix of people
| who are emotionally attached to AMD and see AMD as their
| best bud who's showing Intel what's what and not a profit
| driven company that would squeeze them exactly as much as
| they could afford if they were in a better position...
|
| and people who bought AMD stock, but none of Intel or
| anything much else, because they see the CPU market as a
| 0 sum game. AMD was a darling of first time investors on
| a certain platform and they don't diversify. It's not
| that their constant wall of pro-AMD stock noise is going
| to affect the stock price, but it also becomes a bit of
| an emotional thing for them.
|
| All the AMD posts here end up looking a lot more like
| Reddit than Hacker News
| amiga-workbench wrote:
| Intel have a history of anti-competitive practices and
| high prices. We're all just enjoying seeing them get the
| kicking they deserve.
|
| The schadenfreude isn't coming from nowhere.
| spectramax wrote:
| Yea but you do realize that it's a legislative issue? We
| need better controls for anti-competitive behavior.
|
| You can just flip the sides, if AMD controlled 85% market
| share, the shareholders would demand the same unless we
| have laws preventing anti-competitive behavior.
|
| That said, I do acknowledge the business leadership at
| Intel and their toxic attempts to prevent competition.
| yjftsjthsd-h wrote:
| Why would we legislate it when the underdog is winning?
| This _is_ the market fixing itself without help.
| cosmiccatnap wrote:
| Its not a bias it's just true. Intel has chips that are
| objectively underperformannt and less secure based on
| everything we know currently. There are no good reasons
| anyone should pick an Intel chip for their desktop system
| for the foreseeable future.
| spectramax wrote:
| We are talking about server chips? Can you point to some
| comparisons?
| kllrnohj wrote:
| > We are talking about server chips?
|
| What gave you that idea? This thread was clearly about
| someone building a local PC. There's no reason to assume
| that'd be a server chip?
|
| But even in the server world go look up any comparison of
| Epyc Rome vs. Intel Xeon and you'll still struggle to
| find a reason to go Intel. The Epyc 7742 is in a league
| of its own at this point.
| spectramax wrote:
| I'm trying to get a point across for favoritism of AMD
| beyond objective measures.
|
| This entire post is about Intel security flaw where we
| just had one discovered for AMD yesterday! But people are
| not as vile about AMD but become hostile when it comes to
| Intel. Why? There are some toxic people defending both
| sides with passion. I'm baffled. If this isn't "Fanboys",
| what is?
|
| Regarding comparisons, I'm yet to see a conclusive source
| that points at AMD > Intel for server workloads -
| benchmarking these things is complex. Power, efficiency,
| workload types, etc matter. So it's not as simple as
| saying "Hey, AMD won".
|
| I'm disappointed at the hostility for pointing out
| fanboyism on HN. It's present whether one denies it or
| not.
|
| Edit: Holyshit. I won't be responding anymore. This has
| become an unproductive discussion simply for pointing out
| the bias in supporting the "underdog". I have no way to
| prove this but I stand by my observations and what my
| eyes see - given Apples and Apples comparison for metric
| X or security flaw X, people have a deep bias for
| supporting the "underdog". I saw this first hand back in
| 2006 when Intel was the "underdog". This is a fact and no
| amount of massaging on HN or the Internet forums will
| change that. I'm again disappointed in the HN community's
| response.
| bayindirh wrote:
| It sounds like I'm trying to debunk you, but I just want
| to answer your questions.
|
| I work as an HPC administrator and I just want to tell a
| single thing:
|
| We were unable to buy first generation EPYC processors
| because almost all of the production run is bought by
| Google, Amazon and Dropbox. They weren't offered by many
| vendors as general availability servers because it wasn't
| possible.
|
| It's a bit late here so, I cannot do much research but
| I'll leave this Phoronix article [0] about RocksDB
| performance.
|
| Phoronix Test Suite sounds a bit cheesy but, as far as I
| can see, it's becoming a reputable benchmark suite. I was
| troubleshooting a server from a big manufacturer and, its
| official live CD has this thing installed to see how
| system performs.
|
| Also our fellow HPC centers says that EPYC is not
| vaporware in terms of performance.
|
| [0]: https://www.phoronix.com/scan.php?page=article&item=
| intel-am...
| bmelton wrote:
| > I'm disappointed at the hostility for pointing out
| fanboyism on HN
|
| Because it very much comes across as though you've got an
| axe to grind. OP was "maybe sort of" going to build an
| AMD box, for which there are a lot of good reasons
| irrespective of the bug on topic, and this set him over
| the top.
|
| His post doesn't really exude fanboy behavior, and your
| comment - while possibly appropriate for some other post
| - isn't really appropriate to OP.
| kllrnohj wrote:
| > where we just had one discovered for AMD yesterday
|
| AMD's was a new side channel that doesn't appear to be
| that different from existing side channels like
| flush+reload. Some pros (and cons) over the established
| ones, but you're not attacking anything with those
| either. It's how you ex-filtrate data after a successful
| attack.
|
| This, by comparison, is a new attack vulnerability. They
| are different severity, and I'd expect here of all places
| to recognize & acknowledge that. I'm baffled as to why
| you seem to be expecting something different?
|
| > Regarding comparisons, I'm yet to see a conclusive
| source that points at AMD > Intel for server workloads -
| benchmarking these things is complex. Power, efficiency,
| workload types, etc matter. So it's not as simple as
| saying "Hey, AMD won".
|
| Did you look? Yes benchmarking these is complex, but when
| one CPU wins the overwhelming majority of every
| comparison on every metric it reeks of fanboyism to then
| claim it's "not conclusive." There's no shortage of
| server CPU benchmarks done in this space. If you have a
| specific comparison that's missing then say it. Otherwise
| you're just accusing people of the fanboy behavior that
| you're exhibiting.
|
| But here: https://www.anandtech.com/show/14694/amd-rome-
| epyc-2nd-gen/1...
|
| "For those with little time: at the high end with
| socketed x86 CPUs, AMD offers you up to 50 to 100% higher
| performance while offering a 40% lower price. Unless you
| go for the low end server CPUs, there is no contest: AMD
| offers much better performance for a much lower price
| than Intel, with more memory channels and over 2x the
| number of PCIe lanes. These are also PCIe 4.0 lanes. What
| if you want more than 2 TB of RAM in your dual socket
| server? The discount in favor of AMD just became 50%.
|
| So has AMD done the unthinkable? Beaten Intel by such a
| large margin that there is no contest? For now, based on
| our preliminary testing, that is the case. The launch of
| AMD's second generation EPYC processors is nothing short
| of historic, beating the competition by a large margin in
| almost every metric: performance, performance per watt
| and performance per dollar."
|
| Like every review of Rome is like this. AMD released an
| incredible product. Credit where credit is due is not
| fanboyism.
| bmelton wrote:
| I mean, TFA is about an exploit exclusive to Intel SGX
| processors, which of course includes E3 Xeons.
| bayindirh wrote:
| Mine is not about "Fanboyism". I'm going to upgrade my system
| after 7 years and will go for a multi-core performance system
| for parallel software development.
|
| I consider AMD for its new Infinity Fabric and multi-core
| performance. I also use performance counters a lot to
| optimize my code and improve my understanding of modern
| processors even further.
|
| This will be my 5th build and I've built 2 AMD and 3 Intel
| systems for long-term use in a span of ~20 years. I think
| it's logical to go for a high-performance system with lower
| attack count/surface to reduce the chance of getting
| performance-crippling uCode or Kernel patches in the future.
|
| I was probably a fanboy while overclocking my 1433MHz 1700+
| to 2.2GHz with ABIT ultra mother boards. These days and
| mindset has long gone, at least for me.
|
| OTOH, I have more than enough cutting edge hardware from
| major vendors to manage and play with. So, I'm not hungry for
| anything really.
| spectramax wrote:
| I'm sorry, I was alluding to the general trend, not
| specifically inclined to your message although it appears
| so. Bad wording on my part.
| bayindirh wrote:
| No problem. We're discussing stuff here. I also didn't
| want to sound angry or aggressive. I'm sorry if I did
| (English is not my native language).
|
| I also did root for AMD when I was younger however, in a
| more down-to-earth fashion. AMD was providing 90% of the
| performance of a comparable Intel system and, Intel was
| so dominating that AMD was at the brink of collapse.
|
| I rooted for AMD because I wanted them to survive. I
| wanted competition. I wanted to see more interesting
| ideas from more vendors. I also reacted to that infamous
| "AMD's thermal management doesn't work" video from Tom's
| Hardware because my and my friends' AMD systems' thermal
| management features were working fine.
|
| I rooted for AMD because they were more dynamic when
| compared to Intel. They allowed overclocking,
| experimenting. They had more chipset choices and some of
| these chipsets did interesting things that Intel was not
| daring to try.
|
| Intel was a company wearing suits even in weekends, while
| AMD was going to work putting on jeans and, it was
| exciting for young enthusiasts.
|
| AMD still has this in its gene though. They were _kind
| and open_ enough to revise their GPU silicon to _enable
| truly open source drivers_ sans HDCP. Their company
| culture is different and I root for the underdogs
| sometimes because, I root for competition.
| roca wrote:
| The headline and a lot of the writeup is very confusing. This
| attack does not let you modify _architectural_ state, only
| speculative state. The headlines sound like you can corrupt the
| values that the program actually ends up using, but you can 't.
| You can only modify speculative state and use those changes to
| get more control over what data is leaked through side channels.
| the_duke wrote:
| Could we change the link to the source?
|
| https://lviattack.eu
|
| It has a good explanation, videos and FAQ.
|
| (the Techcrunch post is just horrible)
| mzs wrote:
| I concur, it also links to the paper and repo
|
| https://lviattack.eu/lvi.pdf
|
| https://github.com/jovanbulck/sgx-step
| [deleted]
| TekMol wrote:
| I often think Techcrunch should be banned on HN.
|
| When I click on a Techrunch link, it tries to redirect me to
| some tracking url on advertising.com. That would probably
| collect data about me, set cookies and send me back to
| Techcrunch. Since I do not allow that, I cannot read Techcrunch
| articles at all.
|
| Lets see what others think. I made an Ask HN from this:
|
| https://news.ycombinator.com/item?id=22539255
| option wrote:
| Same here, doesn't even work in Firefox focus with the
| settings I have
| cheeze wrote:
| Agree. Techcrunch is almost always just a poorly written
| article that fails to link to the real source.
| bobobob420 wrote:
| How bout we first ban articles behind paywalls?
| 3pt14159 wrote:
| It definitely shouldn't be banned. Techcrunch has many
| stories where there was something really interesting that
| they were the first to report. That said, the long tail of TC
| articles that are rehashes of what's already been written
| elsewhere do get tiring.
| aSplash0fDerp wrote:
| Would buffered connectivity mitigate what is becoming a Swiss
| cheese infrastructure of hardware (security holes in everything)?
|
| Direct connectivity (on Internet 1.0) seems to be playing with
| fire nowadays.
|
| Security admins probably love the fact that they are guarding
| their assets from unknown threats/vulnerabilities that major
| manufactures have included in their products.
| baybal2 wrote:
| Quite sensational.
|
| I think very few mortals out there use SGX, Intel apparently
| dropping public tooling support for it just shows for it.
|
| Biggest scare is coming to DRM users, but even they I think are
| not much impressed as insecure trustlets for 845 in the wild
| already made then to give up few years ago.
| jokoon wrote:
| Yes I just don't understand, most big vulnerabilities that make
| the headlines, even if they involves a lot of people, the vuln
| scenario looks it's still crumbs.
|
| Of course the crumbs of many users can add up to a lot, so it's
| a still a concern, it's not really nothing.
|
| Of course what matters is the PR involved, not the actual vuln.
| Hardware vulns are pretty bad since they can't be fixed. But
| still, it still sounds like worse than it really is.
| sf_rob wrote:
| [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?
| chandlerc1024 wrote:
| 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 wrote:
| 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.... 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"
| gowld wrote:
| "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.
| blihp wrote:
| 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.
| cesarb wrote:
| 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 wrote:
| 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 wrote:
| >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.
| akiselev wrote:
| 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 wrote:
| Interestingly, there was a 1998 paper about speculative
| execution that basically outlined all of Spectre/Meltdown.
| cpach wrote:
| And 'cperciva found some weird stuff long before Spectre.
| He reported to Intel and their reply was basically "meh".
| cperciva wrote:
| Intel is a very different company in 2020 than they were
| in 2005.
| cpach wrote:
| Alright! What are the most significant changes they have
| made?
| cperciva wrote:
| They've gone from "try to get someone fired to get them
| to shut up" to "offer millions of dollars of bounties to
| researchers". It's a completely different attitude.
| saagarjha wrote:
| Are they better, or worse?
| akga wrote:
| Sounds interesting. Do you have a link to it?
| Kurakuan wrote:
| 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.sema...
| kevin_thibedeau wrote:
| > sensationalist Micro story
|
| Considering it was published with the intent to "move
| markets" I would consider it a fraudulent Micro story.
| ngneer wrote:
| Right, but side channels in Intel products were known. It is
| unreasonable to expect the literature to account for every
| single aspect of your design. Had the side channel threat
| been taken more seriously at the time, it would presumably
| have led to more robust designs.
| willis936 wrote:
| 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 wrote:
| Computers were also a lot less connected to communications
| channels that could be used to break in.
| gitgudnubs wrote:
| 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.
| piinthesky wrote:
| 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.
| josh2600 wrote:
| 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.
| Causality1 wrote:
| As far as I know there's never been an in the wild system
| compromised based on Spectre either.
| josh2600 wrote:
| I don't think this entire class of processor attacks have
| ever been seen outside of academia (yet).
| sulam wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I mean, you'd expect verified data to sell for more than
| unvetted bulk dumps, yeah?
| tomc1985 wrote:
| Most of the real sales are on carder forums.
| https://krebsonsecurity.com/ writes in-depth from
| infiltrating some of them if you're curious
| dnautics wrote:
| 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 wrote:
| 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 wrote:
| 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.
| [deleted]
| Twirrim wrote:
| 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 wrote:
| 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.
| Lind5 wrote:
| Good background info:New Security Risks Create Need For Stealthy
| Chips https://semiengineering.com/new-security-risks-create-
| need-f... Determining What Really Needs To Be Secured In A Chip
| https://semiengineering.com/determining-what-really-needs-to...
| pengaru wrote:
| also https://www.zdnet.com/article/intel-cpus-vulnerable-to-
| new-l...
| popotamonga wrote:
| I wonder what would happen if a flaw were found that would render
| an entire line of expensive CPUs useless.
| metalliqaz wrote:
| the closest I can think of was the famous floating point error
| that caused Intel to recall lots of parts[1]. Even that didn't
| render the CPUs useless for most users, only some scientific
| and business use cases really had problems.
|
| [1] https://en.wikipedia.org/wiki/Pentium_FDIV_bug
| alex_free wrote:
| >Thomas Nicely, a professor of mathematics at Lynchburg
| College, had written code to enumerate primes, twin primes,
| prime triplets, and prime quadruplets. Nicely noticed some
| inconsistencies in the calculations on June 13, 1994, shortly
| after adding a Pentium system to his group of computers, but
| was unable to eliminate other factors (such as programming
| errors, motherboard chipsets, etc.) until October 19, 1994.
| On October 24, 1994, he reported the issue to Intel.
|
| Can you imagine debugging this for that many months only to
| find out there was nothing on your end to fix.
| 2J0 wrote:
| My memory is hazy but I'm sure I recall the problem during
| summer 94, but I stand corrected. Was there any normal way
| for the information to reach us? That was the year intel
| took down Vlsd Pentkovskis profile page.. I loved to tease
| everyone that Pentium was named tribute to him...
|
| Edit:typo fixed for pentium
| sarah180 wrote:
| I had a similar experience when doing my first serious work
| in a compiled language. I found and reported a compiler bug
| in double-precision division (in a commercial C compiler).
| It took me years to stop blaming the compiler for my bugs.
| snovv_crash wrote:
| I had the same, an embedded system with GCC 3.something.
| Managed to get a toolchain together with 4.something and
| suddenly our uptime and random corruption issues
| disappeared.
| hermitdev wrote:
| I spent an entire summer as an intern, constantly on the
| phone with IBM support trying to get DB2 Connect to work in
| a Windows cluster only to be told "this is not a supported
| configuration" despite it being clearly supported in the
| documentation. Gave up. Years later, ran into my former
| boss randomly (at a liquor store of all places) and he
| mentioned they were finally able to get it to work.
|
| Another confounding one was where I was trying to bulk copy
| some data to Sybase using Python. Started getting some
| really strange DB errors. Couldn't figure it out for a
| while. Turns out, it was a bug in the DB module and it was
| using uninitialized memory in certain conditions. Was a
| 1-line fix, but took about 6 weeks to find.
|
| Yet another one was when I was working on porting my C++
| services from 32 to 64-bit. Sockets were timing out
| immediately sometimes. Couldn't reproduce in the debugger.
| Was a bug in a 3rd party framework. It was improperly using
| the rtdsc instruction in some inline ASM. Worked fine on
| 32-bit, but the register layout was different on 64-bit.
| So, it was effectively reading a garbage upper 32-bits for
| the high-res timer. Only found that one because I noticed
| in my logs that my timers were reporting that some
| operations had taken >200 years. I forget how long it took
| to track that one down, but it was months of off and on
| hunting.
|
| I've also hit internal compiler errors. The one I remember
| was that an anonymous namespace at global scope would cause
| an ICE. I was about to file a bug report once I'd a minimal
| reproduction, but it'd already been reported and fixed.
| NortySpock wrote:
| And as I recall Linux had a kernel patch that would bypass
| the affected hardware and run all floating point operations
| in software (splitting floats into two integers, etc), so you
| could bypass the flaw at the cost of performance.
| wahern wrote:
| I remember Linux having floating-point emulation for 486
| processors without a floating point unit. But at least
| according to this early message from Torvalds, Linux didn't
| implement this for FDIV:
|
| > It wouldn't be impossible, but it's not something I will
| do: this isn't a problem to be solved by the OS, but by
| Intel or the user. The fdiv bug isn't a problem for most
| people, and for those that it is, it's more efficient to
| make the compiler do the bug work-around instead.
|
| > Note that doing it in the kernel would mean trapping for
| _every_ fp operation, and that 's not good for a fp-
| intensive program: and the main programs which /would/ care
| about the fdiv bug are the fp-intensive ones.
|
| https://groups.google.com/d/msg/comp.os.linux.development/4
| o...
|
| Googling around it seems the typical solution, other than
| just doing nothing, was to recompile, as GCC had a patch to
| detect the FDIV bug and emulate division much more
| efficiently.
|
| I only had a 486SX (no FPU) at the time so it was never
| really on my radar. Non-scientific software didn't really
| do floating-point arithmetic precisely because FPUs weren't
| very common on consumer hardware. Most of the people burnt
| by the FDIV bug were already well positioned to either
| recompile their software or receive patches from their
| vendors.
| flatiron wrote:
| not OP but i always assume Linux had a workaround. But
| you are right, it just prints you got the bug and that's
| that
|
| https://github.com/torvalds/linux/search?q=X86_BUG_FDIV&u
| nsc...
| __jal wrote:
| "Render useless" makes me think of something more like the
| F00F bug - hard lockup until a reboot.
|
| https://en.wikipedia.org/wiki/Pentium_F00F_bug
|
| OS vendors worked around it in software.
| 2J0 wrote:
| Seriously this isn't humor, we're running a "abandoned "
| processor for authentication and a operating system decidedly
| unattractive unless you want to win capture the flag at deacon.
| We abandoned the secure operating system version very
| reluctantly so it was formerly B book.
| saagarjha wrote:
| I'm having difficulty understanding this comment, would you
| mind explaining it a bit more?
| brenden2 wrote:
| Intel has already had so many flaws and vulnerabilities that I
| think nothing will change. People would prefer to ignore the
| problem and do nothing because they don't want their businesses
| to implode.
| metalliqaz wrote:
| I wish the updates for Spectre/Meltdown were optional on my
| Windows machine. They posed no real risk to my single-user
| gaming machine and the fixes had an unacceptable performance
| burden IMHO.
| swift532 wrote:
| Are you sure they are not optional? I remember disabling
| various security updates at the time, but unfortunately I
| wasn't testing whether performance in games was affected
| positively after removing them. I can only say that it felt
| as it had been faster, but I hadn't measured FPS.
| metalliqaz wrote:
| My understanding is that newer Windows version contain
| microcode updates for the processors, and once they are
| applied, they are in there for good.
| mgiampapa wrote:
| Microcode doesn't flash the CPU, it's loaded at boot
| time, you can remove it and disable the software
| mitigation.
| kllrnohj wrote:
| > They posed no real risk to my single-user gaming machine
| and the fixes had an unacceptable performance burden IMHO.
|
| Where are you seeing a performance burden? The
| spectre/meltdown patches had no impact to game performance:
| https://www.tomshardware.com/reviews/gaming-performance-
| melt...
| agloeregrets wrote:
| Same on my Chromebook Pixel LS too. They were optional but
| now they added all kinds of additional mitigations and are
| also adding linux throttling and in the last 6 months or so
| I probably have gained ~60% compile time.
| saagarjha wrote:
| Do you not browse the web on that machine?
| skierguy wrote:
| There's a performance mode that Google has a support
| article for. Google exactly "Change your Chromebook's
| performance setting", and you should see it.
|
| If lscpu still shows some offline cpus (let's say cpu 1
| and 3 are offline), echo 1 >>
| /sys/devices/system/cpu/cpu<1 or 3>/online. Run lscpu
| again, and you should see all CPUs online and 2 threads
| per core.
| mgiampapa wrote:
| They are, you can disable them in the registry.
| jimmaswell wrote:
| You can toggle/check mitigations with a program called
| InSpectre.
| atq2119 wrote:
| People patch, or seriously consider patching, their compilers
| -- unfortunately. See for example:
| https://bugzilla.mozilla.org/show_bug.cgi?id=1596565
|
| Maybe it doesn't quite fit your criteria completely, since
| there is also a microcode workaround. Still...
| kijiki wrote:
| The driver for recalls is demand from the largest customers. In
| Intel's case, mostly big cloud operators.
|
| They have a strong vested interest in pretending that sharing
| compute resources across customers is a safe thing to do, so
| they're unlikely to rock the boat.
| MauranKilom wrote:
| I understand how they turn incorrect store forwarding into an
| attack, but can somebody summarize what causes the store
| forwarding to be wrong in the first place?
| redrabbyte wrote:
| short version: only the lower bits of an address are compared
| at first, because the rest might take a while to resolve so the
| cpu can speculate that the rest is gonna match as well and
| start to work with the data, and then either keep it or throw
| it away once the rest of the address is known
| driverdan wrote:
| An 11 month embargo for a widespread security flaw like this is
| unacceptable. Researchers need to refuse to comply with this. 90
| days by default and an extra 90 on request is more than enough.
| If they can't get their shit together in six months they won't be
| able to in 12.
| 3pt14159 wrote:
| We need an industry standard shut-up-and-pay-me system. First
| 90 days free. Then some sort of quadratic formula for every
| month after that.
| yjftsjthsd-h wrote:
| I'd prefer 90 days and then unconditional publishing. I grant
| that making companies' desire for silence actually affect the
| bottom line has appeal, but 1. some companies have deep
| pockets, and 2. I'm not ethically comfortable with anything
| of the form "pay me to not disclose this bad thing".
| mzs wrote:
| much better link https://lviattack.eu/
| remind_me_again wrote:
| Excuse my irrelevant question, but I can't hold myself to ask.
| Why do they think it's a flaw but not an intentional mistake to
| open a backdoor to government agencies?
| nneonneo wrote:
| There was a CTF this weekend (UTCTF) featuring a task to exploit
| a program running in a secure SGX enclave. As part of solving
| that task I spent some time looking into the design of SGX, and I
| gotta say it doesn't sound promising.
|
| The basic idea is to be able to run code on an Intel processor
| that cannot be tampered with or even examined by any other part
| of the system, including the OS, hypervisors, etc. The entire
| code and data segment of this program runs in its own world, the
| "secure enclave", in user mode (ring 3). The attack model is that
| every piece of software executing on the CPU (user code, OS code,
| hypervisors) and every bit of hardware outside the CPU (network
| interfaces, hardware buses, memory interfaces) could be
| compromised and attempting to leak data from your Secure Enclave,
| and the enclave code/data should still remain tamper proof and
| unreadable. The SGX implementation even includes an attestation
| system, using a trusted server operated by Intel, which will
| attempt to verify that the CPU itself is not compromised.
|
| The entire thing depends on a lot of cryptography. Sealing keys
| to encrypt data that will be persisted to disk from the enclave.
| Memory protection keys to encrypt everything going to RAM. Page
| encryption keys to encrypt any memory that the OS tries to page
| out. Attestation keys to cryptographically verify that the CPU
| measured itself to be OK. Cryptographic signatures to validate
| the initial enclave code and data to protect against tampering of
| the initial state. Session keys to protect the enclave's
| communication with whatever application server is providing the
| code/data for the enclave's computation. The OS and even the ring
| 3 application hosting the enclave have a MITM position on
| absolutely everything the enclave does, so the disclosure of just
| one of these keys breaks the security of the whole system.
|
| I am not surprised at all that SGX wound up being vulnerable to a
| low-level CPU attack. The attack surface is way too big and there
| are too many points of failure.
| warkdarrior wrote:
| > I am not surprised at all that SGX wound up being vulnerable
| to a low-level CPU attack.
|
| Most secure systems assume that the CPU is functioning
| correctly. It is not clear that you can do anything securely if
| the CPU is buggy.
| ngneer wrote:
| What is correctly? You have to understand that SGX was built
| on an existing infrastructure, without rebuilding the chip.
| Intel architects ignored side channels for years. So the
| security specification was being met, except it had ignored a
| crucial threat. Small comfort. My point is that "correctly"
| for security can only be defined in the context of a threat
| model. If the model is incomplete, then you are exposed. I am
| not aware of a complete threat model for TEE design. And the
| reason is clear. The threats develop over time, springing
| into existence as an emergent property of complex designs
| rewarded by a market that is not keen on incentivizing secure
| design.
| olah_1 wrote:
| Signal is planning on using Intel's SGX enclaves.
| https://signal.org/blog/secure-value-recovery/
|
| Not sure how much of a risk this plays in that plan, though.
| kijiki wrote:
| Signal already uses SGX for Contact Discovery, and has for many
| months.
|
| In all cases, Signal only uses SGX to improve cases where data
| previously was stored in plaintext. The idea is to change the
| required attack from "compromise signal servers" to "compromise
| signal servers _and_ compromise SGX".
| AndrewBissell wrote:
| OK, but if compromising SGX is pretty easy, that just leaves
| the servers (hosted on AWS) for someone to be able to observe
| and decrypt all Signal traffic, right?
| v4dok wrote:
| It is anything but easy. I guess that is why you get
| downvoted. The fact that only this academic group was able
| to come up with these attacks shows the amount of knowledge
| you need to have to carry them out.
| AndrewBissell wrote:
| OK, but how hard is it for a state-backed intelligence
| agency to come up with that knowledge? The Vault 7 leaks
| showed that the CIA has all kinds of very deep
| capabilities in this area. I'm not thinking of some
| random script kiddies doing this.
| redrabbyte wrote:
| it's fairly easy (with the available publications) once
| you have the prerequisites: a compromised operating
| system
|
| which is of course exactly what sgx is supposed to defend
| against, but at the same time that kind of access is a
| pretty big problem on its own
| g_sch wrote:
| Signal already does use SGX for quite a bit:
| https://signal.org/blog/private-contact-discovery/
|
| Some people here (and elsewhere) have pointed out this recent
| tendency of Signal to put a lot of eggs in the same SGX basket.
| I hope they take a closer look at the risks of this strategy.
| totaldude87 wrote:
| [security noob here]can anyone explain this in layman terms, i.e
| can these be exploited remotely, what we can do to protect etc!
|
| In short, who should be worried, a common Windows user, a *nix
| system admin or everyone who uses intel chips..
| redrabbyte wrote:
| not really / update / no, unless you rely on sgx to protect
| high value data
| saagarjha wrote:
| This vulnerability targets SGX enclaves (although I believe it
| would affect all memory loads?), which run code that is meant
| to be isolated from the rest of your computer and is probably
| currently only being used by DRM on your computer. This is a
| flaw in your processor and at the moment you probably cannot do
| anything to protect against this, although work is being done
| to come up with mitigations. Currently, it seems like they'll
| be the kind that'll slow down your computer.
| redrabbyte wrote:
| it affects all loads, but for sgx the attacker scenario is
| that you have compromised the OS, which makes it
| significantly easier to create the conditions
| (faults/microcode assists) that cause the LVI than if you
| were just another userspace program (but it's not impossible
| there either)
| d--b wrote:
| Do all these vulnerabilities mean that manufacturers will have to
| remove those optimizations, rendering the cpu slower?
|
| It seems to me that extracting or injecting data that way is very
| hard to do, and is likely to return very little information.
|
| Is the tradeoff something like: we should prevent the one in a
| hundred billion chance that my cpu leaks a critical password to
| some intruder one day at the cost of rendering all my processes
| 30% slower?
| 2J0 wrote:
| Can I restate the go question as "is complexity of the machine
| effectively security by obscurity and effective in practice for
| reliance upon?"
|
| Really how much unnecessary complexity is traversing boundaries
| we can shut down or at least gate effectively?
|
| My company has used CICS for this purpose since forever and
| we're not so much a legacy that you will think about our
| architecture in this way if we talked about it, but CICS is a
| very rare interface in this era.
| ghaff wrote:
| We call it serverless now :-) (I'm joking a bit but there are
| similarities.)
| cesarb wrote:
| What's probably going to happen is more isolation. SGX is a
| target for these vulnerabilities because it's a separate mode
| of the same processor core which runs normal software; were it
| on a dedicated core, it wouldn't be vulnerable. In the same
| way, the kernel can be attacked by user processes (and
| processes can attack each other) only because they share the
| same core. So I'd expect to see for instance the kernel running
| on a set of cores separate from user software (probably using a
| ring buffer interface for most system calls, like io_uring),
| and the hardware state being totally flushed when switching a
| core to another process.
| saagarjha wrote:
| (This is also slower.)
| gameswithgo wrote:
| Going to be worse than 30% slower by a lot.
| BoorishBears wrote:
| What does this statement even mean?
|
| 30% slower for what? What workload? What environment?
|
| I can't even ask what your source on it being "worse than
| 30%" because that statement doesn't mean anything... people
| keep attaching percentages to these vulnerabilities that
| really mean nothing for any general use case, to the point
| you can't even compare them to each other!
|
| I imagine your answer is going to be "well these mitigations
| are going to be more slower than the last ones"
|
| Do these vulnerabilities and the last live on the same hot
| paths?
|
| Are you privy to some information we're all lacking here that
| lets you just throw out a statement like this?
| redrabbyte wrote:
| there are some (non-optimal) estimates in the paper, tl;dr
| it's not great ;)
|
| some more technical info here
| https://software.intel.com/security-software-
| guidance/insigh...
| rishabhd wrote:
| I think it already happened, where the flaw itself was critical
| and the performance impact was substantial. See Zombieload for
| reference.
|
| 1) https://venturebeat.com/2019/05/14/intel-zombieload-flaw-
| for...
|
| 2) https://zombieloadattack.com/
| aibrahem wrote:
| This is a shameless plug, but I'm really hoping to increase the
| awareness and the level of understanding about these kind of HW
| bugs.
|
| I made a blog post trying to explain the Intel ME hardware bug.
|
| Understanding the Intel CSME Vulnerability for Mere Mortals -
| https://news.ycombinator.com/item?id=22534259
| gjsman-1000 wrote:
| I'm not a technical expert, but check out the guy who made the
| fake movie trailer's channel. He has written parody songs for
| almost all of the Intel execution attacks there are, which is
| quite hilarious.
| redrabbyte wrote:
| he happens to be an author/co-author of all of those papers ;)
| guerrilla wrote:
| If anyone's interested, I recently started a youtube playlist
| collecting talks on exploiting and securing x86 hardware and
| firmware:
| https://m.youtube.com/playlist?list=PL7Jsn37GlvSwYGaetkukERO...
|
| Anything I should add?
| Lind5 wrote:
| https://www.youtube.com/playlist?list=PL4RrBxLcT1nZThUvIFjS0...
___________________________________________________________________
(page generated 2020-03-10 23:00 UTC)