[HN Gopher] New speculative attacks on Apple CPUs
___________________________________________________________________
New speculative attacks on Apple CPUs
Author : cylo
Score : 498 points
Date : 2025-01-28 18:31 UTC (4 hours ago)
(HTM) web link (predictors.fail)
(TXT) w3m dump (predictors.fail)
| anotherhue wrote:
| For any yung'uns seeing this for the first time, the spectre and
| meltdown attacks (and accompanying papers) are worth reading.
|
| https://spectreattack.com/
| ajross wrote:
| Hm... as I read it this is much worse. Spectre/Meltdown were
| data isolation vulnerabilities. You could exploit side channel
| (mostly timing) information to intuit state about memory across
| a protection boundary. Basically you can prime the CPU state to
| allow you to tell which of multiple code paths the
| kernel/hypervisor/whatever took, and then go from there to
| reading arbitrary data. Which is bad, obviously.
|
| Here, they claim to have a remote exploit vulnerability. It's
| not that Apple is leaking data, it's that the CPUs have a bug
| where they appear to be actually executing code based on
| incorrectly-loaded ("predicted") data.
|
| Though the details are, as is usually the case, thin. I await
| further analysis.
| saagarjha wrote:
| They're speculatively executing code. It's not traditional
| code execution. (You can, of course, read the papers for full
| details.)
| omcnoe wrote:
| It's not remote code execution, it's the same flavor of "out
| of bounds read through speculation" as previous
| vulnerabilities. It's terrifying because they have a working
| proof of concept from untrusted JS in Safari, but there have
| been speculative execution in browser JS engines before now
| also.
| ajross wrote:
| The language seems to argue otherwise: SLAP "allows the
| adversary to jump the LAP to the target webpage's string
| and trick the CPU into operating on it" and FLOP "allows us
| to run a function with the wrong arguments". That's
| absolutely not mere data exfiltration.
|
| Now, maybe this is because of a trampoline based on pre-
| existing Safari bugs and not the CPU misfeature itself.
| Again, the details are slim.
|
| But "the same flavor of vulerability" seems to be a
| mischaracterization.
| saagarjha wrote:
| No, they're correct.
| loeg wrote:
| Only speculatively. The end result is the same as not
| executing that code, other than observable side effects.
| yencabulator wrote:
| My read: the attack gets 600 cycles of CPU time to
| execute its code (JITted Javascript, in web context) on
| the speculated data, and to use some side channel to
| communicate results back out of the speculated parallel-
| world.
|
| Some of the earlier speculation attacks didn't get to do
| arbitrary compute on the speculated data, they could only
| for example influence whether something was loaded into
| cache or not.
|
| This makes an attack easier to write.
| midtake wrote:
| A browser-based attack, in theory, could have happened with
| Spectre/Meltdown as well. I seem to recall a PoC for Spectre
| in the browser, actually. I believe it's also a reason that
| microsecond precision in the browser was made a bit more
| opaque since that era.
| mettamage wrote:
| GLitch was a Rowhammer browser based attack [1]. It's not
| Spectre/Meltdown but still, for a while people thought it
| couldn't be done.
|
| [1] https://www.vusec.net/projects/glitch/
| umvi wrote:
| Is it bad that I disable spectre mitigations on all my PCs to
| get a free double-digit-% performance boost?
| baq wrote:
| Only if you don't care if baddies see you go fast
| thijsr wrote:
| It depends on your threat model. If you don't run any
| untrusted code on your hardware (including Javascript), you
| can safely disable the mitigations. If you do run untrusted
| code, keep them enabled.
| basementcat wrote:
| If your machine is air gapped and/or not running random
| downloaded code, I think it is a possible reasonable option.
| autoexec wrote:
| It's a tragedy that so many websites insist on having the
| ability to run random downloaded code on our systems to do
| basic things like displaying simple text and images. Things
| browsers are capable of with nothing but HTML. Google
| refuses to even show search results, a bunch of literal
| hyperlinks, without javascript being enabled.
| ribcage wrote:
| The real tragedy is that our processors try to win a bit
| more speed by sacrificing simplicity and therefore
| increasing the chances of such exploits. The other
| tragedy is that our operating systems are obsolete and
| have worthless security. Back in the day when UNIX was
| relevant, a hundred people could use it at the same on a
| mainframe with no fear of it breaking, now one person
| cannot safely use a single computer.
| fsflover wrote:
| > Google refuses to even show search results, a bunch of
| literal hyperlinks, without javascript being enabled.
|
| DuckDuckGo works fine with no JS.
| kllrnohj wrote:
| What are you doing where you see anything remotely close to
| double-digit-% gains from disabling spectre mitigations?
| iforgot22 wrote:
| Video editing maybe? Which is not going to involve running
| untrusted code.
| kllrnohj wrote:
| It's not going to hammer on syscalls, either, so it won't
| have any spectre-related regressions.
| daneel_w wrote:
| You're not getting a boost, you're avoiding a penalty. In
| some (but not all) cases you can avoid the penalty _and_ the
| exploits by disabling SMT. Remember, SMT isn 't twice as many
| cores, just twice as many half-cores. You'll be fine.
| umanwizard wrote:
| In my experience SMT is still faster for most workloads
| even with the mitigations.
| daneel_w wrote:
| It's a common misunderstanding that the CPU suddenly has
| twice as large performance envelope when SMT is enabled.
| Only specialized software/scenarios will tangibly benefit
| from the parasitic gains of SMT-induced extra
| parallelization, e.g. video encoders like x264 or CPU-
| bound raytracers to name a few examples. These gains
| typically amount to about 15-20% at the very extreme end.
| In some cases you'll see a performance drop due to the
| inherent contention of two "cores" sharing one actual
| core. If you're stuck with a dual-core CPU for your
| desktop setup you should absolutely enable SMT to make
| your general experience feel a bit more responsive.
| umanwizard wrote:
| > It's a common misunderstanding that the CPU suddenly
| has twice as large performance envelope when SMT is
| enabled.
|
| Perhaps, but I am not under this misunderstanding and
| never expressed it.
|
| > Only specialized software/scenarios will tangibly
| benefit from the parasitic gains of SMT-induced extra
| parallelization
|
| In my experience it also speeds up C++/Rust compilation,
| which is the main thing I care about. I can't find any
| benchmarks now but I have definitely seen a benefit in
| the past.
| thijsr wrote:
| Disabling SMT alone isn't enough to mitigate CPU
| vulnerabilities. For full protection against issues like
| L1TF or MDS, you must both enable the relevant mitigations
| and disable SMT. Mitigations defend against attacks where
| an attacker executes on the same core after the victim,
| while disabling SMT protects against scenarios where the
| attacker runs concurrently with the victim.
| viraptor wrote:
| In practice probably not, as long as general population keeps
| it enabled. I mean, looking at effort required, it's not
| worth spending time exploiting spectre these days, because
| virtually everyone is protected. If you're not likely to be
| directly targeted, "herd immunity" will work.
| iforgot22 wrote:
| If just visiting a webpage with some JS will let them do
| ACE on even 0.1% of visitors, hackers are probably still
| motivated enough to try it. But I vaguely remember these
| kinds of vulns can be patched in-browser for a perf hit
| instead of taking the hit system-wide, which sounds like an
| ok compromise.
|
| Edit: Arbitrary memory access, not ACE
| bawolff wrote:
| > If just visiting a webpage with some JS will let them
| do ACE on even 0.1% of visitors
|
| Spectre is not an arbitrary code execution kind of
| attack.
| iforgot22 wrote:
| Oops, I meant arbitrary memory access.
| viraptor wrote:
| Linux on its own isn't even 0.1% visitors normally. We're
| talking multiple orders of magnitude less for disabled
| mitigations. And on top of all that, it's possible that
| exploiting on that machine is going to be harder due to
| custom software with uncommon memory layout - i.e. it's
| probably not a stock Ubuntu. And finally, for accessing
| data outside of the page, you really want to have some
| specific target, so they'd have to guess that too.
| iforgot22 wrote:
| If only Linux is affected then sure. Was talking about
| spectre in general. Maybe only Linux users are turning
| the spectre mitigation flags off, but there are plenty of
| outdated Windows systems too.
| ActorNightly wrote:
| >hackers are probably still motivated enough to try it.
|
| The amount of actual exploit crafting that is needed to
| actually do something meaningful with a hack is pretty
| much not worth doing for any financial reason. The only
| time this happens now is when state funded actors or
| prominent groups with lots of manpower really want to
| take down an individual person.
| paulddraper wrote:
| > double-digit-%
|
| In the early days there was a ~10% hit, but that's changed a
| lot since then.
| jorvi wrote:
| You shouldn't disable Spectre mitigations, but Retbleed and
| Downfall (Intel) are much more of a "lab" exploit, and the
| fall-out for Retbleed is much more severe on cloud boxes than
| your personal PC. Easy 20-40% performance uplift on AMD
| Zen1-Zen2 and Intel 6th-11th gen.
| LPisGood wrote:
| I'd highly recommend reading Flush+Reload first since the cache
| side channel is key to any of these miceoarchitectural attacks.
| mettamage wrote:
| As someone who followed a course on all of this, this is
| indeed how we started out.
|
| 1. Read Flush + Reload
|
| 2. Then reproduce it in C
|
| 3. Then read Meltdown
|
| 4. Reproduce it in C
|
| 5. Read Spectre
|
| 6. Reproduce it in C
|
| After that we had to implement a VUSEC paper. I chose GLitch
| [1].
|
| [1] https://www.vusec.net/projects/glitch/
| tptacek wrote:
| Aside: I feel like RUB has become kind of a global center for
| this kind of high-end offensive security work. Was I just not
| paying enough attention 10 years ago or is this a new-ish thing?
| jf wrote:
| What is RUB?
| pulvinar wrote:
| Ruhr-University Bochum, in Germany
| stoneforger wrote:
| https://www.ruhr-uni-bochum.de/de
| dooglius wrote:
| Ruhr University Bochum, the third author's University
| bobnamob wrote:
| Idk if it's RUB or Yuval, he was credited on spectre and
| meltdown as well (if I recall correctly), but he was at data61
| or Uni adelaide at the time
| r9295 wrote:
| They've also consistently put out some of the best fuzzing
| research
| tptacek wrote:
| Their offensive crypto work is also on point.
| pbsd wrote:
| It goes way back; check the work of the likes of Thorsten Holz
| or Christof Paar. TU Graz is another one.
| remus wrote:
| Interesting that the researchers have gone public before a
| mitigation is in place from Apple. Seems in pretty stark contrast
| to the industry-wide coordination that went into patching and
| mitigating spectre.
| dartos wrote:
| Does Apple pay bug bounties?
| InTheArena wrote:
| Yes, they do.
| saurik wrote:
| They claim to, but they drag their feet, demand terms most
| researchers find so unacceptable as to be a bit immoral (the
| point of "responsible disclosure" isn't, in fact, to hold
| secrets from the public arbitrarily long), and often end up
| paying only a fraction of what was expected, if anything.
|
| https://pxlnv.com/linklog/apple-bug-bounty-troubles/
|
| https://www.marketplace.org/shows/marketplace-
| tech/looking-f...
|
| https://mjtsai.com/blog/2021/07/13/more-trouble-with-the-
| app...
| tptacek wrote:
| The vibe I got talking to people like Mark Dowd about this
| is that they're running something closer to an exploit
| bounty program, and it's pretty focused on patterns of
| vulnerabilities common to some pretty specific threat
| actors.
| threeseed wrote:
| Your links are all from 2021. I remember there was a lot of
| criticism at the time and so they updated their bug bounty
| program which quite a number of changes:
|
| https://security.apple.com/blog/apple-security-bounty-
| upgrad...
|
| Would be interesting to see if it made a difference.
| phoe-krk wrote:
| _> We disclosed our results to Apple on May 24, 2024. Apple's
| Product Security Team have acknowledged our report and proof-
| of-concept code, requesting an extended embargo beyond the
| 90-day window. At the time of writing, Apple did not share any
| schedule regarding mitigation plans concerning the results
| presented in this paper._
|
| The vulnerability is over half a year old and over a quarter
| over the embargo window.
| sofixa wrote:
| I wonder if Apple are being slow due to the complexity of the
| potential fix, or because they're dragging their feet.
| kllrnohj wrote:
| Or it's a hardware issue and they don't have any way to do
| a microcode fix for this
| sebzim4500 wrote:
| It's could be unfixable without a significant performance
| penalty, but at minimum they could make safari do proper
| process isolation like every other browser does.
| umanwizard wrote:
| I could easily imagine such a refactor of Safari taking
| more than 90 days even if Apple made it the highest
| possible priority.
| goldsteinq wrote:
| The bug is open since 2018, so clearly they don't
| actually care about that.
|
| https://bugs.webkit.org/show_bug.cgi?id=184466
| umanwizard wrote:
| Right, but that was before they knew about this exploit.
| My point was that even if they decided they needed to
| urgently switch to a multiprocesses architecture because
| it's the only way to mitigate this exploit, they might
| not be done yet.
| goldsteinq wrote:
| This class of attacks is not new. Spectre demonstrated
| this possibility in 2018, and Apple was previously
| targeted by speculation attacks, e.g.
| https://gofetch.fail/ or https://ileakage.com/.
| alt227 wrote:
| Because the fix will most likely kill performance, like
| Spectre/Meltdown did, and then their pretty graphs wont
| look so impressive any more.
| latexr wrote:
| As someone who has reported several (software) security
| vulnerabilities to Apple, I couldn't care less. Some of the
| things I reported are trivial to fix, and dealing with
| their team has been a frustrating experience. They don't
| deserve extensions, they need to get their shit together
| and stop releasing new crap every year. Clearly they can't
| do it properly.
| tptacek wrote:
| The LVP vulnerability was reported in September, for what
| it's worth.
| gabeio wrote:
| That's still more or less 120 days ago. Well over the 90
| day typical window.
| tptacek wrote:
| I'm not saying it's bad (I'm pretty close to a disclosure
| absolutist), though I don't really know what the norms
| are for hardware attacks --- both papers are well past
| the normal coordinated disclosure window for software.
| nerflad wrote:
| > We disclosed SLAP to Apple on May 24, 2024, and FLOP on
| September 3, 2024
| IshKebab wrote:
| I think also this isn't fundamentally different to Spectre.
| Spectre introduced a whole new class of vulnerabilities (hence
| the name) and this is one of them. An impressive one, but
| still, it definitely doesn't deserve the coordination & secrecy
| that Spectre had.
|
| Most browsers have already switched to process-per-site because
| of Spectre.
| gjsman-1000 wrote:
| Bizarre the M1 is immune to both; I'm more secure by not
| upgrading. (Sure, there's still a few, but they are mostly minor
| by comparison, or newer chips are also affected.)
| sodality2 wrote:
| Newer CPUs use more and more "hacks" - out of order execution,
| caching, speculative execution, branch prediction, etc - to
| gain performance improvements. The further back you go, the
| less vulnerable CPUs generally are to these (but possibly more
| vulnerable to other kinds of attacks).
| badgersnake wrote:
| Indeed, my Apple Watch (series 3) has always been immune to
| all spectre type attacks, the CPU is too simple. It doesn't
| do speculative execution at all.
| hinkley wrote:
| I can't imagine taking a cpu design class in this more
| cynical era. So much of the speed these days seems to come
| down to distilling smoke and mirrors into physical form.
| sodality2 wrote:
| On the other hand, research into finding these
| vulnerabilities seems to be booming. Though presumably, so
| is the grey-hat market.
| umanwizard wrote:
| But M1 is squarely a modern CPU. It uses all the techniques
| you mention (as does every high-performance CPU since the
| Pentium Pro era).
| sodality2 wrote:
| For sure. But the further you go along, the _more_ of these
| tricks it uses and relies upon to improve performance. New
| vulnerabilities that are discovered are likely to take
| advantage of some feature on the spectrum of these "hacks",
| from new to old. Because older "hacks" are well-known and
| studied, newly discovered vulnerabilities are more likely
| to target features in the newer end of that spectrum (AKA
| newer CPUs).
| IshKebab wrote:
| Does it have a Load Value Predictor?
| umanwizard wrote:
| I don't know.
| saagarjha wrote:
| No.
| tptacek wrote:
| The M1 doesn't have load address or value predictors. It's less
| sophisticated, and so has a smaller microarchitectural attack
| surface.
| junek wrote:
| OK, fun. What can we do to mitigate this until it gets patched?
| thijsr wrote:
| From the FAQ:
|
| > _While FLOP has an actionable mitigation, implementing it
| requires patches from software vendors and cannot be done by
| users. Apple has communicated to us that they plan to address
| these issues in an upcoming security update, hence it is
| important to enable automatic updates and ensure that your
| devices are running the latest operating system and
| applications._
| omcnoe wrote:
| Serious answer, don't use Safari. Use a browser that properly
| separates webpages into isolated processes so that this kind of
| cross-site read is not possible.
| amelius wrote:
| Will that work? Isn't memory treated in a unified way between
| processes, at some point?
| goldsteinq wrote:
| It will work unless someone forgets to add a public suffix
| into the public suffix list (as described in the FLOP
| paper). Both of these attacks target virtual memory
| pointers.
| saagarjha wrote:
| Processors are not supposed to speculate across ASIDs
| goldsteinq wrote:
| There're no other browsers on iPhone. Every iPhone browser is
| a reskin of Safari. They're in theory supposed to allow other
| browsers in the EU, but AFAIK it has not happened yet.
| ragnot wrote:
| God I hate Apple sometimes
| prmoustache wrote:
| Then don't use an iPhone until it is patched.
| hmottestad wrote:
| I wonder if Lockdown Mode would help?
| omcnoe wrote:
| Their SLAP demo provides a great example of how defence-in-depth
| can make/break the viability of an exploit. That terrifying
| Safari demo is possible because Safari fails to isolate new
| windows in individual processes when calling `window.open` in js.
|
| All the other side channel magic presented here doesn't matter if
| the data you want to read is in a seperate process with
| sufficient separation from the "hostile" process in the address
| space.
| r00fus wrote:
| Do other browsers have process isolation for new tabs?
| tptacek wrote:
| Not necessarily for tabs on the same web site, but for
| different sites, yes. Hence "site isolation".
| lxgr wrote:
| That's not a failure of Safari, it's required by window.open
| API semantics, in particular by the default Cross-Origin-
| Opener-Policy of "unsafe-none" [1].
|
| By setting a different policy, sites can protect themselves
| against this.
|
| I guess technically browsers could open new windows in a new
| browsing context group regardless of this setting and relay the
| allowed types of messages via IPC (if any), but that would be a
| major performance hit, and I don't think any other browsers do
| it differently.
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/HTTP/Headers/Cr...
| wging wrote:
| So should Protonmail (and any other site with similarly
| sensitive data) be setting that header, then? It's probably
| hard to change the default. I bet some use cases (SSO
| popups?) depend on it.
| connicpu wrote:
| It's not unreasonable to set a different header value for
| the login page only, where it should be safe because no
| external user data is being rendered.
| lxgr wrote:
| Sites can also opt into the same behavior by setting the
| rel="noopener" or alternatively target="_blank" attributes
| on outgoing links (i.e. <a> tags).
|
| And yes, something like a webmail site should definitely be
| setting the header, or at lest these attributes for
| outbound content links.
| omcnoe wrote:
| Cross-Origin-Opener-Policy seems like a case of bad defaults
| where a less secure option has been selected so that we don't
| break some poorly maintained websites. Better to get the
| actual users of `window.open` to fix their code than to make
| every website insecure out of the box.
|
| I can't imagine there are many sites passing significant
| amounts of data through this, the small number of users where
| IPC poses too high a penalty can opt their sites into the
| "same process" flag if really needed.
| lxgr wrote:
| Forcing every website to adapt to a browser update is
| completely infeasible.
|
| > I can't imagine there are many sites passing significant
| amounts of data through this
|
| This is actually a quite common mechanism for popup-based
| authentication (which is much more secure than iframe-based
| one, as users can verify where they're potentially entering
| their credentials).
| dfedbeef wrote:
| It's super feasible if you own the API default.
| lxgr wrote:
| It's definitely a quick way to get all your users to
| switch to a different browser or figure out how to
| disable updates forever.
| throwaway894345 wrote:
| I mean, if all major browsers do it roughly once then
| users will complain to the few broken websites. They
| won't even think to blame the browser if every other site
| works fine and the broken site is broken on all browsers.
| lxgr wrote:
| Good luck trying to get Google or Microsoft to throw
| their paying enterprise users under the bus in the
| interest of slightly safer sandboxing defaults.
| connicpu wrote:
| One spot where safari is in an advantageous position to
| force a new default, as long as they roll it out on iOS
| first.
| dfedbeef wrote:
| You just announce you are making a change and then turn
| it on later.
| schrodinger wrote:
| After building enterprise APIs for a few years, you'd be
| amazed at how hard it is to get companies to make even
| minor changes; backwards compatibility is key. Often it's
| because they _can't_ make the change themselves since
| they outsourced the code to a consulting agency. So
| they'd have to sign a new contract and get an agency to
| make the change.
|
| They just won't, and you'll have a browser that people
| stop using.
| bee_rider wrote:
| It is probably outside the scope of what one company can
| do (although Apple is quite large...). But we need to fix
| our understanding of backwards compatibility. If a
| computer system provides the ability to keep doing
| something, but the way it provides that capability
| requires it to be insecure, then the system should not
| really be thought of as "backward compatible." Because
| reasonably prudent people can't actually keep doing the
| thing they were doing before.
|
| Of source, modern computers on the modern web don't
| really provide the ability to do much at all in a
| reasonably prudent fashion, so it is all a bit moot I
| guess.
| lxgr wrote:
| Announce what to whom? To the hundreds of millions of
| users out there that don't even know what a browser _is_
| , let alone why it's now talking to them about something
| called a "site isolation framework"?
| plufz wrote:
| I would guess you would use a deprecation message in the
| console? Like they have done over cookie changes, etc. A
| normal user would obviously not check the console, but
| the devs or admins of the site sure might.
| lxgr wrote:
| That's assuming there's still a dev around that has
| knowledge of, or even access to, the source code of a
| given webapp depending on the legacy functionality.
| zamalek wrote:
| We had the tech in the 80's for the browser to facilitate
| popup authentication with process isolation. It's this
| niche and esoteric tech called IPC[1], so niche that one
| really can't blame Apple for not hearing about it.
|
| It truly boggles the mind as to how all the other
| browsers pull it off.
|
| [1]: https://en.wikipedia.org/wiki/Inter-
| process_communication
| lxgr wrote:
| To be fair, there wasn't that much sensitive web content
| around in the 80s to leak (primarily due to the web not
| yet existing, nor browsers), so it's only fair that
| browsers didn't consider using IPC for site isolation
| back then.
| zamalek wrote:
| The point of my rather facetious comment is that IPC a
| well known thing (I struggle to even call it "tech") that
| has been around for 30-40 years. I don't understand why
| Apple needs people to make excuses for them, but this
| excuse would render Apple vastly more incompetent than
| neglecting to separate browser tabs in 2025.
| lxgr wrote:
| Browsers are incredibly complex, and moving them to an
| IPC model is not easy. Essentially, you need to ensure
| "same process like", performant JavaScript
| interoperability in some cases, often (but not always)
| due to backwards compatibility.
|
| Firefox has shared a lot about their efforts in moving
| there. If you're curious, there are a lot of blog posts
| and internal design docs under their project name
| "Project Fission".
|
| But yeah, the fact that both Chrome and Firefox have
| managed to do so does leave Apple looking slightly bad
| here.
| asoneth wrote:
| Why not a choice?
|
| Individuals could choose a "secure" browser or browser
| mode that provides increased protection from such attacks
| or a "compatible" one that is less likely to break old
| websites.
| jahewson wrote:
| That's not a real choice though. All it takes is one
| website that is essential to me not supporting the secure
| mode and I'm forced to opt-out. The upstream website is
| making the choice for me.
| kergonath wrote:
| > Individuals could choose a "secure" browser or browser
| mode that provides increased protection from such attacks
| or a "compatible" one that is less likely to break old
| websites.
|
| And then we get thousands of posts whining about Safari
| being broken because it is "not like Chrome" and
| developers moaning that their unsafe pet API is not
| supported. Web developers are _never_ going to play ball.
| amatecha wrote:
| idunno, as a professional web dev since 1998, I don't
| understand why Google, Apple and Mozilla are trying so
| hard to make the web browser like a complete OS (I
| technically understand why, I just think it's
| ridiculous). The amount of obscure APIs being added just
| boosts the surface area for vulnerabilities and makes
| low-resource web browsing nearly impossible. You either
| get "a web browser that works" or "a web browser that can
| load almost nothing", and basically nothing in between.
|
| Some fun examples of "your browser is an OS on top of
| your OS":
|
| The Screen Wake Lock API provides a way to prevent
| devices from dimming or locking the screen when an
| application needs to keep running.
| https://developer.mozilla.org/en-
| US/docs/Web/API/Screen_Wake...
|
| The Web Serial API provides a way for websites to read
| from and write to serial devices.
| https://developer.mozilla.org/en-
| US/docs/Web/API/Web_Serial_...
|
| The Window Management API allows you to get detailed
| information on the displays connected to your device and
| more easily place windows on specific screens, paving the
| way towards more effective multi-screen applications.
| https://developer.mozilla.org/en-
| US/docs/Web/API/Window_Mana...
|
| The Compute Pressure API is a JavaScript API that enables
| you to observe the pressure of system resources such as
| the CPU. https://developer.mozilla.org/en-
| US/docs/Web/API/Compute_Pre...
| kelnos wrote:
| Users don't want to make these kinds of choices, and
| generally there's no good way to educate them enough to
| figure out what they actually want.
| fweimer wrote:
| Would it help to use separate processes and share the data on
| demand only, via IPC with a robust speculation barrier?
| eptcyka wrote:
| Other browsers do site isolation, why can't Safari? (:
| zamalek wrote:
| Right, in what sane world would the website determine
| operating system process semantics? What next, syscalls?
| astrange wrote:
| Have you noticed how often people complain Chrome uses too
| much memory?
| lxgr wrote:
| Process-per-site isolation doesn't necessarily have to
| use (much) more memory.
|
| If you pre-initialize the renderer and JavaScript engine
| and then fork that pre-warmed instance for each site,
| every page of memory not written to remains shared in
| physical memory.
|
| Properly accounting for that in task managers is hard,
| though; on many OSes, Chrome's memory usage looks much
| scarier than it is in reality.
| nine_k wrote:
| Because long-inactive tabs should go to sleep.
|
| If Chrome itself is not aggressive enough, try the "Auto
| Tab Discard" extension.
| lxgr wrote:
| Safari definitely does use site isolation (if you check
| "Activity Monitor", you'll find Safari processes named
| after the sites they're displaying) in almost all cases.
|
| window.open, in some constellations, is an exception,
| because the opening and opened sites have an explicit
| communication facility available to them, unless at least
| one of the two explicitly opts out of it. As far as I'm
| aware, Safari also correctly implements that opt-out.
|
| The only thing that Chrome and Firefox seem to be doing on
| top of that, as far as I understand, is to actually enforce
| process-per-site even for sites from the same "browsing
| context group" (i.e. all that can hold programmatic
| references to each other, e.g. via window.opener), which
| requires using IPC.
| danans wrote:
| > Safari definitely does use site isolation (if you check
| "Activity Monitor", you'll find Safari processes named
| after the sites they're displaying) in almost all cases.
|
| From the FAQ:
|
| "For leaking secrets, both SLAP and FLOP are confined to
| the address space they are trained in. As pointed out by
| iLeakage, Safari lacks Site Isolation, a measure used to
| enforce that two different webpages not from the same
| domain can never be handled by the same process. Thus, in
| Safari it is possible for an adversary's webpage to be
| handled by the same process (and thus address space) with
| an arbitrary webpage, increasing the attack surface
| including LAP- and LVP-based exploits.
|
| On the other hand, although Chrome is equipped with Site
| Isolation, we demonstrate that it is not a perfect
| mitigation. We show the real-world existence of corner
| cases, where two subdomains of the same site can be
| merged into one process, again leading to LAP- and LVP-
| based attacks."
| davrosthedalek wrote:
| Would that performance hit be really that significant? I
| can't imagine there are more than a couple of calls total,
| and that's all dwarfed by any web access. Or do I
| misunderstand what's required?
| dadrian wrote:
| It is not required by window.open semantics, you can
| absolutely implement site isolation even in the presence of
| COOP unsafe-none
| kllrnohj wrote:
| The writing was on the wall for in-process sandboxing with
| Spectre, but that seems to have faded a bit. This just re-
| enforces that. Things like "safe in-process sandboxing with
| WASM" are just a fantasy, it can't be implemented.
| lxgr wrote:
| Safe in-process sandboxing is obviously possible and even
| trivial. It does get harder if you care about performance,
| though.
| saagarjha wrote:
| If the costs are high enough you're basically
| reimplementing multi-process isolation from first
| principles.
| willtemperley wrote:
| What I know as a developer is web security is really hard.
| Last week there was a DOM clobbering gadget deep in my
| TypeScript world and I really didn't have the energy to
| understand who wants to clobber my DOM and why they need a
| gadget. I want to build stuff and what worries me is this
| stuff is just simply not foreseeable.
| lxgr wrote:
| DOM security is a completely different beast from process
| isolation with WASM (in a web context or otherwise). The
| attack surface is vastly greater, due to the much larger
| API complexity.
| kllrnohj wrote:
| "trivial" how do you figure? Remember these exploits bypass
| your own code's conditionals over a _shockingly_ far
| duration. Unless you just mean for incredibly restrictive
| usages such as eBPF?
|
| _possible_ absent any performance concerns at all, yeah
| sure
| lxgr wrote:
| > Unless you just mean for incredibly restrictive usages
| such as eBPF?
|
| I was actually thinking something more like a bytecode
| interpreter that runs one operation and then sleeps until
| the next full wall clock second, but yes, that's my
| point: If you don't care about performance, you can make
| process isolation safe very easily.
| tptacek wrote:
| I think at the point where you're suggesting 1hz bytecode
| interpreters the onus is kind of on you to be clear
| you're not talking about plausible points in the design
| space.
| lxgr wrote:
| 1 Hz is probably a bit too slow for practical
| applications, but my point is that somewhere between
| that, and simulating a parallel universe at each data-
| dependent branch, is probably a reasonably-safe spot, or
| more likely a spectrum that application developers get to
| pick their tradeoffs from.
| tptacek wrote:
| I agree that 1hz is probably too slow for practical
| applications.
| throneaway1799 wrote:
| An identically useful comment would've been to place the
| bounds at 0 and infinity.
| lxgr wrote:
| A zero Hz machine is arguably not Turing complete,
| though.
| wbl wrote:
| That is actually still not secure. The cache will happily
| retain the trace of the access forever.
| lxgr wrote:
| Yeah, but unless a cache miss has a performance penalty
| of roughly one second, you should be fine.
| H8crilA wrote:
| No, only some of the side channel magic doesn't matter if you
| live in a different virtual memory space. Other past attacks
| didn't use virtual memory pointers and used physical memory
| pointers or didn't use any pointers at all - one could read
| data from another process, the kernel, another VM, the SGX
| enclaves or even proprietary CPU manufacturer code that runs on
| the CPU, like the CPU signing keys used for remote attestation.
| btown wrote:
| This, 100%. From the SLAP paper linked in the OP
| https://predictors.fail/files/SLAP.pdf :
|
| > Considerations for Safari. We emphasize the importance of
| site isolation [55], a mechanism preventing webpages of
| different domains from sharing rendering processes. Site
| isolation is already present in Chrome and Firefox [42, 55],
| preventing sensitive information from other webpages from being
| allocated in the attacker's address space. While its
| implementation is an ongoing effort by Apple [3, 4], site
| isolation is not currently on production releases of Safari. On
| the contrary, we also reflect on [Webkit's memory allocator]
| libpas's heap layout from Section 6.3, allowing sites to not
| only share processes, but also heaps. Partitioning JavaScript
| heaps by at least several memory pages per-webpage would
| prevent JavaScript strings from the target webpage from being
| allocated within the 255-byte reach of the LAP.
| cluckindan wrote:
| In Safari settings under Advanced, it's possible to enable
| "verify window.open user gesture". Does that help at all?
| tptacek wrote:
| Cool detail, in the section where they reverse-engineer the
| presence of an LVP on the M3: Remarkably, while
| all other load widths activate the LVP on any constant
| value fitting that width, we observe that acti- vation on
| 8-byte wide loads occurs only when the load value is
| zero. We conjecture that this may be a countermeasure for
| memory safety such that the LVP will not learn values of
| pointers. That is, with the M3 being a 64-bit CPU, pointers
| are 8 bytes wide. Furthermore, on 64-bit macOS executables,
| any virtual address below 0x100, 000, 000 is invalid.
| ijustlovemath wrote:
| wait, so does this mean that if an exploit tries to use a 32
| bit address it's immediately shut down?
| anyfoo wrote:
| There are usually no valid 32 bit addresses, i.e. the first
| 4GB are not mapped.
| saagarjha wrote:
| Grouping a hex address by threes is crazy
| sylware wrote:
| ... and another one...
| resource_waste wrote:
| Good reminder that Marketing is detached from reality.
| saagarjha wrote:
| > On the other hand, although Chrome is equipped with Site
| Isolation, we demonstrate that it is not a perfect mitigation. We
| show the real-world existence of corner cases, where two
| subdomains of the same site can be merged into one process, again
| leading to LAP- and LVP-based attacks.
|
| Did anyone spot where this is mentioned?
|
| Edit: it doesn't seem like they have a general attack. Rather,
| it's that some sites are not in the public suffix list.
|
| Edit 2: It's also interesting that they found that iPhone 13 and
| iPhone 13 mini (which have the same processor and came out at the
| same time) differ in LAP in that they observed only the latter as
| having it. Very curious...
| daneel_w wrote:
| Apple released minor-version updates to both macOS and iOS the
| past few days, both containing several security fixes. Has anyone
| been able to confirm if they address these exploits?
| layer8 wrote:
| They haven't yet. From
| https://www.bleepingcomputer.com/news/security/new-apple-
| cpu...:
|
| _Apple acknowledged the shared proof-of-concept and stated it
| plans to address the issues. However, at the time of writing,
| the flaws remain unmitigated.
|
| "We want to thank the researchers for their collaboration as
| this proof of concept advances our understanding of these types
| of threats," Apple told BleepingComputer.
|
| "Based on our analysis, we do not believe this issue poses an
| immediate risk to our users."_
| bawolff wrote:
| Hmm, one part i found interesting
|
| > In order to make cache hits distinguishable from misses in
| Safari, we reference the NOT gate-based cache amplifica- tion
| primitive from [29, Section 5], adjusting the speculation
| parameters for the M2 CPU. We run the amplifier 500 times when
| the target address is cached and 500 more times when it is
| evicted, in native and WebAssembly implementations. Table 3
| summarizes the timing distributions, with units in ms. We observe
| that they are clearly separable even in a web environment,
| allowing us to distinguish cache hits from misses with WebKit's 1
| ms timer.
|
| So i guess all the hub hub around disabling fine resolution
| timers and SharedArrayBuffer was for naught.
| kevingadd wrote:
| It delayed viable attacks by a few years, maybe?
|
| It doesn't hurt that setbacks for web app development
| coincidentally send developers into the open arms of Google and
| Apple's stores that collect a 30% cut of all revenue, so there
| was a good incentive to do it even if it didn't protect anyone.
| bawolff wrote:
| > It doesn't hurt that setbacks for web app development
| coincidentally send developers into the open arms of Google
| and Apple's stores that collect a 30% cut of all revenue, so
| there was a good incentive to do it even if it didn't protect
| anyone.
|
| That seems like a bit of a reach. Its an obscure feature that
| is rarely useful, and when it is all you have to do is send
| the right http header (if using chrome) and you get it back.
| kevingadd wrote:
| Multithreading may be an obscure feature to you but runtime
| developers get requests for it all the time. SAB becoming
| widely available was definitely delayed.
| bawolff wrote:
| I would still maintain that needing multithreading on a
| website is relatively rare, and specifically needing
| SharedArrayBuffer instead of just multiple proceses (e.g.
| webworkers) is even more rare.
|
| Did use cases exist? Sure. But not sufficiently to move
| the needle on app store usage.
| shevis wrote:
| One of the most significant use cases that gets impacted
| is game dev.
|
| Web games benefit significantly from SAB (see the Godot
| engine for example) and mobile games make up a pretty
| sizable chunk of app store usage, particularly in app
| purchases.
| yoshicoder wrote:
| Funny that I am seeing this now, because last Fall I had Daniel
| Genkin as my Intro to Cyber Security Professor (co-author of this
| result). Interesting class, but I remember him mentioning that
| they were working on a speculative attack for Apple CPUs after
| seeing the results of spectre and meltdown on Intel CPUs. I
| remember how he seemed almost paranoid about security, and I
| suppose I see why now (security is almost never guaranteed).
|
| Especially now that I have just bought an M4 mac
| artisanspam wrote:
| The marketing culture for announcing hardware exploits is so
| strange to me. The norm seems to be getting a custom domain,
| logos, demos, an FAQ... why do all this instead of just reporting
| the exploit and releasing a paper?
| 9283409232 wrote:
| Only academics read exploit papers. I don't see anything wrong
| with releasing the information is a more digestible way if it
| is something that affects the general populace. I only knew
| about heartbleed because of the website.
| https://heartbleed.com/
| caust1c wrote:
| Blame society. Businesses won't value security unless the fear
| of getting attacked is sufficiently strong and the losses
| significant. Otherwise why invest in it at all?
|
| Definitely not just hardware exploits though. Look at
| heartbleed for example. It's been going on a long time.
| Hardware exploits are just so much more widely applicable hence
| the interest to researchers.
| woodruffw wrote:
| Heartbleed et al. demonstrated conclusively that recognition
| matters; I don't begrudge researchers any technique that
| increases the relative visibility of their work.
| IshKebab wrote:
| It's a recent trend basically since Heartbleed had a cool name
| and lots of press. Why would you _not_ want your exploit to be
| well known and to get lots of credit for it? If anything it 's
| surprising it didn't happen earlier.
| porcoda wrote:
| It's happening in other parts of the research world too: a
| couple colleagues of mine were talking recently about a paper
| we found at a conference last year that had a web page to go
| along with it with a domain and fancy graphics and such. For a
| boring programming languages paper. We concluded this is the
| modern way to try to jack your citations by getting noticed for
| everything but the technical content of the work, which is a
| bit off putting.
| ipdashc wrote:
| The custom domains can be a little silly, but for all the rest,
| why not? Logos (and the associated fancy name) are a lot more
| memorable than CVE-2025-XXXX. Demos are and were always
| appreciated. FAQs are a lot more digestible for the average
| reader than a paper.
|
| I know it's kind of goofy, but I don't really see the downside
| to it.
| twoodfin wrote:
| This introduced me to the idea of load value predictors. Is Apple
| the only chip designer using these in commercially released
| microarchitecture?
| eigenform wrote:
| Probably not, but I don't think anyone has talked about it
| explicitly.
|
| Otherwise, there _are_ known examples of related-but-less-
| aggressive optimizations for resolving loads early. I 'm pretty
| sure both AMD[^1] and Intel[^2] have had predictive store-to-
| load forwarding.
|
| edit: Just noticed the FLOP paper also has a nice footnote
| about distinguishing LVP from forwarding during testing (ie.
| you want to drain your store queue)!
|
| [^1]:
| https://www.amd.com/content/dam/amd/en/documents/processor-t...
|
| [^2]:
| https://www.intel.com/content/www/us/en/developer/articles/t...
| 10000truths wrote:
| Related is Casey Muratori's explanation of the GoFetch
| speculative attack on Apple's M-series CPUs:
|
| https://www.youtube.com/watch?v=uZEBkOrfUzM
| api wrote:
| I bet you could construct a hard proof that any kind of
| speculation is insecure in the sense that it cannot be proven
| secure.
|
| If that's not true, then someone's going to figure out exactly
| how to set bounds on safe speculation and that will become part
| of future CPU designs.
| ______ wrote:
| > This research was supported by the Air Force Office of
| Scientific Research (AFOSR)
|
| I wonder if this is the kind of grant that is no longer being
| funded (or at least "paused")
| WhyNotHugo wrote:
| If I understand correctly, this also affects Asahi Linux, right?
| saagarjha wrote:
| It's a processor attack so yes
| everfrustrated wrote:
| Yes. They even used Asahi Linux to develop their techniques on
| as it gave better access to cpu controls. The exploit was
| tested on Safari (IE not a Linux fault but a CPU one).
| hk1337 wrote:
| I'd really be curious to recreate this or to know if any of their
| results included using private browsing mode?
|
| I only bring it up because one of the reasons I use Safari with
| private browsing as a default is because, if I were to login to a
| site like Facebook in one tab, open a new private tab in the same
| window and try going to Facebook, it would not recognize that I
| had already logged in from the other tab. Chrome nor Firefox do
| that.
| peterburkimsher wrote:
| Could this attack be used to jailbreak the latest iPhone?
| saagarjha wrote:
| No.
___________________________________________________________________
(page generated 2025-01-28 23:00 UTC)