[HN Gopher] New speculative attacks on Apple CPUs
___________________________________________________________________
New speculative attacks on Apple CPUs
Author : cylo
Score : 1030 points
Date : 2025-01-28 18:31 UTC (1 days 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.
| positr0n wrote:
| What is the threat model if I run lots of untrusted
| JavaScript, but I only have a small amount of memory in
| other processes worth reading and I would notice sustained
| high CPU usage?
|
| Is there an example in the wild of a spectre exploit
| stealing my gmail cookie and doing something with it?
| (Would be difficult since it's tied to other fingerprints
| like my IP)
|
| Or stealing credit card numbers when they're in memory
| after I place an online order?
| umanwizard wrote:
| If you're not sure, just keep the mitigations on.
| coldpie wrote:
| In the context of a regular end-user desktop machine, this
| seems overly paranoid to me. The odds of encountering a
| real, JS-based spectre attack in the wild are basically
| zero (has anyone _ever_ seen a browser-based Spectre attack
| outside of a research context? even once?), and the odds of
| it then being able to retrieve actual sensitive data are
| also basically zero. That 's two astonishingly tiny numbers
| multiplied together. The threat just isn't there.
|
| For regular end-user desktop machines, the mitigations only
| decrease performance for no real benefit. Spectre is a
| highly targeted attack, it's not something you can just
| point at any random machine to retrieve all their bank
| passwords or whatever.
| 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.
| spydum wrote:
| I got bad news: those systems were NOT secure
| Gigachad wrote:
| Unix systems protected against a physical person trying
| to read or modify another persons file. They did not stop
| programs run by the user reading the users own data
| unexpectedly which is now considered unacceptable but was
| previously the norm.
| umanwizard 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.
|
| This gets repeated on every thread about speculative
| execution exploits, but I think people who say this are
| underestimating how huge the difference would be. I
| suspect processors without speculative execution would be
| many times slower, not "a bit".
| fsflover wrote:
| > Google refuses to even show search results, a bunch of
| literal hyperlinks, without javascript being enabled.
|
| DuckDuckGo works fine with no JS.
| autoexec wrote:
| It mostly works. I get a lot of "No results." and !images
| doesn't work
| 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.
| umvi wrote:
| my specific use case where I see significant performance
| improvement is image segmentation pipelines (which involve
| opencv-style image processing and AI inference). YMMV
| depending on your CPU I suppose.
| AHTERIX5000 wrote:
| If mitigations include disabling SMT and the workload is
| compiling code, then the difference is easily in double
| digits.
| kllrnohj wrote:
| What OS ships the mitigation of disabling SMT by default?
| Surely they just meant things like the retpoline
| mitigations in syscalls?
| 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.
| avianlyric wrote:
| Are you sure about your statement
|
| > 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.
|
| Normally those types of compute heavy processes, data
| streamlined, processes _don't_ see much benefit from SMT.
| After all SMT only provides a performance benefit by
| allowing the CPU to pull from two distinct chains of
| instructions, and fill the pipeline gaps from one thread,
| with instructions from the other thread. It's effectively
| instruction-by-instruction scheduling of two different
| threads.
|
| But if you're running an optimised and efficient process
| that doesn't have significant unpredictable branching, or
| significant unpredictable memory operations. Then SMT
| offers you very little because the instruction pipeline
| for each thread is almost fully packed, offering few
| opportunities to schedule instructions from a different
| thread.
| astrange wrote:
| Compression is inherently unpredictable (if you can
| predict it, it's not compressed enough), which is vaguely
| speaking how it can help x264.
| avianlyric wrote:
| I agree that compression is all about increasing entropy
| per bit, which makes the output of a good compressor
| highly unpredictable.
|
| But that doesn't mean the process of compression involves
| significant amounts of unpredictable branching
| operations. If for no other reason than it would be
| extremely slow and inefficient, because many branching
| operations means you're either processing input pixel-by-
| pixel, or your SIMD pipeline is full of dead zones that
| you can't actually re-schedule, because it would desync
| your processing waves.
|
| Video compression is mostly very clever signal processing
| built on top of primitives like convolutions. You're
| taking large blocks of data, and performing uniform
| mathematical operations over all the data to perform what
| is effectively statistical analysis of that data. That
| analysis can then be used to drive a predictor, then you
| "just" need to XOR the predictor output with the actual
| data, and record the result (using some kind of variable
| length encoding scheme that lets you remove most of the
| unneeded bytes).
|
| But just like computing the median of a large dataset can
| be done with no branches, regardless of how random or the
| large the input is. Video compression can also largely be
| done the same way, and indeed has to be done that way to
| be performant. There's no other way to cram up to 4k *
| 3bytes per frame (~11MB) through a commercial CPU to
| perform compression at a reasonable speed. You must build
| your compressor on top of SIMD primitives, which
| inherently makes branching extremely expensive (many
| orders of magnitude more expensive than branching SISD
| operations).
| astrange wrote:
| > You're taking large blocks of data, and performing
| uniform mathematical operations over all the data to
| perform what is effectively statistical analysis of that
| data.
|
| It doesn't behave this way. If you're thinking of the DCT
| it uses that's mostly 4x4 which is not very large. As for
| motion analysis there are so many possible candidates
| (since it's on quarter-pixels) that it can't try all of
| them and very quickly starts trying to filter them out.
| daneel_w wrote:
| _> Are you sure about your statement_
|
| Yes. From actual experience.
| hansvm wrote:
| It usually speeds up basically everything parallelizable
| that looks kind of like a parser, lexer, tokenizer, ....
| Unless somebody goes out of their way to design a format
| with fewer data dependencies, those workloads are
| crippled on modern CPUs. That includes (de)compression
| routines, compilers, protobuf parsing, ....
|
| The only real constraint is that you can actually
| leverage multiple threads. For protos as an example, that
| requires a modified version of the format with
| checkpoints or similar (which nobody does) or having many
| to work on concurrently (very common in webservers or
| whatever).
| 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.
| iforgot22 wrote:
| Depends how automated it can be. I know some non-spectre
| 0-days were used broadly, either via viruses or port-
| scanning. Is it possible to craft some JS that'll use a
| spectre-like vuln to reliably grab something important
| like Chrome passwords or credit cards? Idk, it's hard to
| prove otherwise, and hackers have more time to think
| about this than I do.
| avianlyric wrote:
| > Is it possible to craft some JS that'll use a spectre-
| like vuln to reliably grab something important like
| Chrome passwords or credit cards?
|
| Probably, but there's a huge luck element involved, at
| least with spectre. It's difficult to guide the
| speculative execution to read exactly what you want it to
| read, assuming you even know where it is. As a result you
| need to spend quite a bit of time on a single target
| before you're likely to actually get the data you want.
| Even then, there's likely a significant element of human
| analysis to assemble something useful from all the noise.
|
| So yes, it's almost certainly possible. But exploits
| don't exist in a vacuum. If you're expending that much
| effort to get credit card numbers, then quite frankly
| you're a fool, because good old phishing attacks and
| other social engineering attacks are easier, more
| reliable, and above all, cheaper.
|
| At the end of the day, crime is a business like any
| other, profitability and margins are king. You don't
| waste time perfecting attacks that have significantly
| smaller margins than your existing attacks. The only
| exception to that is nation states, because they aren't
| motivated by directly extracting cash from victims, and
| ultimately that's what makes nation state actors so
| dangerous.
| paulddraper wrote:
| > double-digit-%
|
| In the early days there was a ~10% hit, but that's changed a
| lot since then.
| umvi wrote:
| It depends on the CPU, think. The most dramatic improvement
| I've seen is 20-30%+ improvements in python run times for
| numpy/pytorch heavy workloads on c2-standard-16 VMs in GCP
| with spectre mitigations disabled
| 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.
| 99catmaster wrote:
| Where and how do you disable these mitigations?
| umvi wrote:
| Not sure about Windows, but on Linux I used:
| https://unix.stackexchange.com/a/554922
| 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/
| sabas123 wrote:
| Keep in mind that getting meltdown to work might be very
| difficult depending on your setup. I wouldn't have been
| able to at least when starting out my teacher didn't
| provide us with targetable hardware.
|
| A spectre (particularly RSB-based ones) are nice to start
| out with imo.
| mettamage wrote:
| Yea fair, this is obviously a high level overview. I
| think I found with meltdown that I needed the assembly
| code. I also was able to reproduce it with actual C code
| if I recall correctly but that was way more finnicky.
| 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.
| hashstring wrote:
| The vendor requested embargo timelines can get pretty
| crazy.
|
| Intel requested an embargo for 21 months for
| SRBDS/Crosstalk.
|
| For Downfall, a more recent one, Intel requested a 12
| month embargo to release a microcode update.
| tptacek wrote:
| For all I know, that might be a reasonable ask for these
| kinds of vulnerabilities --- not that researchers have to
| honor them.
| 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.
| ForOldHack wrote:
| It has a power button, which effectively reduces the
| microarchitectural attack surface to zero.
| lxgr wrote:
| That's vulnerable to DMP-based side channel attacks though
| (like GoFetch [1]), which you can only protect against in
| software [2] on the M3 and beyond.
|
| [1] https://gofetch.fail/
|
| [2] https://developer.apple.com/documentation/xcode/writing-
| arm6...
| 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.
| hashstring wrote:
| What about turn JS off on your favourite iOS browser?
| prmoustache wrote:
| That wouldn't prevent possible malware apps using
| WKWebview from getting out of the jail they are running
| out right?
| hashstring wrote:
| Yes, I agree.
|
| However I also expect that Swift-compiled apps can do
| this without a web browser component.
|
| It's a different threat model though, having installed a
| malicious app vs browsing a malicious site.
| prmoustache wrote:
| Which is the reason alongside telemetry I tend to favor
| using websites over apps.
|
| Having said that there are apps that are considered
| mainstream and not malicious by the general population
| but can become a convenient backdoor for, say, a state
| actor.
| tholdem wrote:
| No need to turn JS off. Turn on Lockdown mode which
| disables Javascript JIT and WASM, which might be enough
| jmkni wrote:
| So could this hypothetically open a mail client on your
| iPhone and read your emails?
| hmottestad wrote:
| I wonder if Lockdown Mode would help?
| dmitrygr wrote:
| IIRC, it disables jit and webassembly, so i think yes
| 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:
| To be fair, this is (relatively, compared to the age of the
| web) new behavior though.
|
| Even Chrome, which pioneered the "tab per process" model,
| didn't isolate same browsing group context sites for a long
| time, and still shares processes on Android as a resource
| optimization: https://chromium.googlesource.com/chromium/sr
| c/+/main/docs/p...
|
| Firefox only released their "Project Fission" in 2021, i.e.
| three years after Spectre.
| 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.
| wging wrote:
| That is a little different, though: those attributes are
| for if you're example.com linking to protonmail, the
| header is for if you're protonmail deciding on security
| policies for interactions with example.com.
| lxgr wrote:
| The header works in both directions; cf. the table on
| https://developer.mozilla.org/en-
| US/docs/Web/HTTP/Headers/Cr....
| 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.
| throwaway894345 wrote:
| I wasn't suggesting it would happen, only that the "users
| would stop updating their browsers" scenario seemed
| unlikely.
| 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.
| plufz wrote:
| Sure. I just got a vibe from this thread that breaking
| security changes in the browser is a totally unknown
| phenomenon, but we had changes to behavior from other
| origin headers, demanding ssl and changes to cookies.
| Somehow we survived. ;)
| lxgr wrote:
| A lot of people did complain very loudly about enforcing
| SSL, and it took decades to get here. Same for cookies.
|
| So yes, breaking changes for privacy/security reasons do
| happen, but they're very painful, and if there's a more
| secure alternative (in this case, still isolating
| communicating processes and providing communication via
| IPC, and providing an opt-out way of the legacy
| behavior), that's often the easier path.
| 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.
| junon wrote:
| We already have this with (iirc) postMessage API.
| lxgr wrote:
| That API is exactly one of the reasons Safari still runs
| some distinct origin sites in the same process together.
|
| Performantly implementing that API across processes is
| possible, but not quite trivial.
| brucehoult wrote:
| popup-based authentication does not actually need high
| performance.
| lxgr wrote:
| It's not used only for authentication, and figuring out
| what a website is trying to do heuristically doesn't
| sound easy either (although I believe Chrome on Android
| does just that, and enforces a site-locked process when
| they deem it important for security reasons).
| tails4e wrote:
| How often do tabs really need to communicate, and when
| they do, does it really need to be as fast as possible. I
| would say slower and secure would be a better design
| philosophy, especially as tab interaction is generally
| rare, and low bandwidth
| junon wrote:
| That, and "cyber security" wasn't really a formalized
| field. It arguably still isn't, depending on how the
| question's framed.
| indymike wrote:
| To be fair, there was no web in the 80s.
| 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. I
| had to stop using Firefox on my old ThinkPad because
| after opening a few windows, it churns the CPU so hard
| it's not usable for a solid minute+. Let that finish up,
| and I have to wait again if I dare to open another page.
| i5-3220m, 8gb of RAM (where the OS uses like 200mb of
| RAM)... there's no excuse for this to not be able to
| browse the web.
|
| 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...
|
| (my thesis is, not all web developers want this stuff,
| and usually when I talk to people in the industry they
| agree, it's excessive)
| lxgr wrote:
| Well, for better or worse, the web is an application
| platform these days.
|
| I consider it pretty great, since the alternative is
| installing native apps for things I'm using exactly once
| or very rarely.
|
| There's a case to be made though that maybe these things
| should only be available to PWAs, which is what Apple is
| already doing for some functionality on iOS, including
| push notifications.
| fennecbutt wrote:
| What? I thought Apple was trying to quietly kill pwas,
| probably bc they don't go thru their app store. And also
| bc if you make a good enough sandbox then you don't need
| to pay for "all the wooork we put in"
| lxgr wrote:
| They certainly don't have a lot of love for them as a
| first-class app development environment, but they are
| also their fig leaf of "open access" to the platform.
|
| Regardless of that, I do like the idea of PWAs getting
| access to a higher tier of web APIs, especially those
| increasing the attack surface, as "installing an app"
| makes even non-sophisticated users do more of a double
| take than "visiting a website" in terms of access to
| their system.
| indymike wrote:
| iOS just really improved support for pwas sometime in the
| last part of last years. It's much better.
| Khaine wrote:
| I agree with you, particularly when 90% of sites people
| visit are to read, watch, or engage with content.
| ChadNauseam wrote:
| Every web developer is fine with 10% of the feature set,
| it's just a different 10% for each dev. I am regularly
| annoyed by the inconsistent browser support for Web MIDI,
| something 99% of web devs probably don't care about at
| all.
|
| It would be easier to sandbox if there were fewer
| features of course, but in practice we rarely see
| exploits even in complicated low-level APIs like webgpu
| (which must be a nightmare to make secure given how many
| buggy drivers and different devices it has to support).
| So it seems like in practice we are able to sandbox these
| APIs securely, and having them provides an incredible
| benefit to users who are able to securely and easily run
| applications (how else do you recommend people do this on
| desktop platforms?).
| genewitch wrote:
| > we rarely see exploits
|
| I can't think of an analogy that doesn't come off crass.
|
| I posit the likelihood the morass that is webgpu not
| having exploitable bugs approaches 0 approximately 25
| seconds after the first public release of the code, if
| not months prior.
|
| Its only when one of two things occur that publishing
| happens, basically: intelligent frustration, and "for the
| lols".
|
| Someone hits a bug and gets pissed that the authors of
| the libraries blame everyone but the library authors.
| When working around the bug discover its not just a bug.
| Warn devs. Sometimes responsible disclosure means a quiet
| fix and then disclosure, but usually it means "here's the
| exploit they don't care ig"
|
| If there's not enough curious people poking things,
| exploitable stuff could remain hidden too long.
| not_kurt_godel wrote:
| > 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...
|
| There's an obscure use case for this called "Watching
| Video"
| mikepurvis wrote:
| Recipe sites will keep themselves awake also, which is
| nice.
| amatecha wrote:
| Dunno, that API has only been available since Firefox 126
| and I've been watching videos without having my screen go
| to sleep (or screensaver coming on) for like.. years and
| years (far before Firefox 126)
| withinboredom wrote:
| That's because there used to be this thing called
| flash/silverlight that could do this instead. Now, video
| is done completely differently than it was.
| iggldiggl wrote:
| > Now, video is done completely differently than it was.
|
| Which is a thing that happened long before Firefox 126,
| too. (Browsers have simply requested the screen wakelock
| themselves when a video was playing. So this API is
| mainly for use cases that _aren 't_ playing a video.)
| padenot wrote:
| Indeed. I work on the Firefox media stack and we have
| been grabbing wake locks when video playback is happening
| for a long time. Occasionally e.g. on some linux desktop
| variant this has malfunctioned and we're alerted in no
| time and fix it.
|
| The Wake Lock API is for other use cases, such as recipe
| websites, or other document for which you don't want the
| screen to go away / dim, the kind where you happen to
| need to look at the screen for long period of time
| without touching it/interacting w/ mouse and keyboard.
|
| Prior to this API being introduced, websites used to play
| an inaudible/almost invisible looping media file to keep
| the screen awake. This has power usage implication, a
| small single digit number of watts (1 to 3.5 depending on
| os, hardware, mobile or not) is required to keep audio
| running (because of high priority threads, frequent
| wakeups, and simply because the audio hardware itself
| needs power).
|
| One of those libraries source, for illustration: https://
| github.com/richtr/NoSleep.js/blob/master/src/index.j...
| jazzyjackson wrote:
| Bless you. I was driven a little mad once trying to
| figure out why certain websites would steal audio focus
| away from music playing on my phone, it must have been
| some clumsy implementation of this.
| collinmanderson wrote:
| > The amount of obscure APIs being added just boosts the
| surface area for vulnerabilities
|
| It's often the ancient APIs from around 1995-2001 that
| are the most vulnerable ones, with information leaking
| across origins (like todays) needing hacky fixes to stay
| secure and compatible.
|
| window.open(), target=_blank, cross site request forgery,
| etc.
|
| IE6 from 2001 had a ton of these modern security issues,
| and Netscape before it probably had them too.
|
| At that time there were tons of buffer overflow security
| holes so no on cared about side-channel attacks.
| pjmlp wrote:
| I fully agree, as someone also doing Web development in a
| similar timeframe, for plenty of stuff we would be better
| with native apps talking over Internet protocols, no need
| to transform a platform for interactive documents into a
| OS.
| kergonath 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)
|
| I am not a web developer but I completely agree with you.
| To me, adding more complex points of failure in humongous
| piles of code that we absolutely need to run in a modern
| life is not a great risk assessment. It's like we never
| learnt from the security issues with the JVM.
| phatskat wrote:
| The first two, screen wake lock and web serial have good
| use cases imo. I wouldn't be surprised if some in-use
| assistive technology uses serial communication - think
| screen readers or custom input devices. Keeping the
| screen from locking is also useful from a purely
| accessible standpoint as well for users who move slower
| or need more time to read things.
| 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.
| ameliaquining wrote:
| People are downvoting you, but Apple does actually offer
| this: https://support.apple.com/en-us/105120
|
| I think they've gotten away with it because it's a pretty
| obscure setting and they say a bunch of things like "most
| users should not enable this, and if you do enable it you
| should expect things to break".
| BobbyTables2 wrote:
| Expecting websites to defend themselves against CPU side
| channel attacks is also absurd!
| omcnoe wrote:
| But how much data are those popup based auth sending
| through? At the absolute most a few MB in a couple calls.
| Even if it's dramatically slower over IPC it's not going
| to cause issues.
| raxxorraxor wrote:
| Similar problem with third-party-cookies. They would make
| some auth cases easier and safer, but we shouldn't
| generally allow them because they are abused for
| tracking.
|
| Here I would agree with you though.
| fweimer wrote:
| Would it help to use separate processes and share the data on
| demand only, via IPC with a robust speculation barrier?
| lxgr wrote:
| Yes, and that's what Firefox and Chrome are already doing.
| 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.
| astrange wrote:
| You can't fork a GUI process on Apple OSes, most of the
| system can't handle it.
|
| It'd also weaken any security protection based on
| randomness (eg ASLR slide, pointer encryption keys).
| lxgr wrote:
| Huh, TIL Chrome on macOS might actually not be using the
| "zygote process" paradigm!
|
| https://source.chromium.org/chromium/chromium/src/+/main:
| con...
| bdd8f1df777b wrote:
| Not possible on Windows, where most Chrome users are on.
| nine_k wrote:
| Because long-inactive tabs should go to sleep.
|
| If Chrome itself is not aggressive enough, try the "Auto
| Tab Discard" extension.
| ksec wrote:
| There is now a Chrome Option "Memory Saver" which dictate
| how aggressive it is to put Tab into Sleep.
|
| Safari on the other hand doesn't even have Tab Sleep for
| whatever reason.
| 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."
| lxgr wrote:
| Yes, _in some special cases_ , which both embedded/opened
| and embedding/opening websites can avoid by setting the
| appropriate HTTP headers/HTML attributes.
|
| Of course it would be better if Safari would do the same
| thing as Chrome and Firefox and just provide a separate
| process for all contexts, including those that can
| communicate per specifications. But there's something
| sites can do today to avoid this potential information
| leak.
| danans wrote:
| > websites can avoid by setting the appropriate HTTP
| headers/HTML attributes.
|
| Individual sites plugging browser + CPU security holes
| seems like a violation of separation of concerns. Yes, I
| hope every bank out there puts this workaround into their
| site ASAP, but that's hardly a solution for the flaw
| itself.
| lxgr wrote:
| The permanent solution to the flaw is either a
| hardware/OS-side fix (i.e. disabling this particular kind
| of speculation via a chicken bit, if there is one), or
| Safari implementing site isolation in the same way Chrome
| and Firefox are already doing.
|
| But as the former might well be impossible (at least
| without ruining performance or requiring a hardware
| swap), and the latter might take a while, websites should
| still take the precautions they can. It's a good idea for
| other reasons anyway: Why keep around an inter-context
| messaging mechanism you possibly don't even need?
| danans wrote:
| > But as the former might well be impossible (at least
| without ruining performance or requiring a hardware
| swap), and the latter might take a while,
|
| According to the site they informed Apple in May 2024.
| Should that not have been enough time?
| lxgr wrote:
| It took Chrome and Firefox years to achieve complete tab
| separation, so yes, it does seem too close,
| unfortunately.
| KingOfCoders wrote:
| No. For fanboys, everything Apple does is the best thing
| anyone could ever do. So if Apple needs more time, then
| it is impossible to be faster. And last line of defense
| "Whataboutism". I wish people would not be so predictable
| and boring.
| 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
| lxgr wrote:
| Sorry, I was imprecise in my original post: It's definitely
| possible to isolate even sites in the same browsing context
| group, but it requires more work that Safari apparently
| just hasn't got around to yet.
| lxgr wrote:
| Can't edit my original post anymore: Firefox and Chrome do
| seem to isolate even same-browsing-context-group and bridge
| the required APIs via IPC, so hopefully Safari will catch up
| at some point.
|
| Basically, there are three scenarios:
|
| - Completely unrelated tabs (e.g. those you open manually,
| those opened via command-click, tabs opened via '<a
| target="_blank' ...>" or 'rel="noopener"' references etc.) -
| these are relatively easily isolated if the browser supports
| it at all. All major (desktop!) browsers now largely do this,
| including Safari.
|
| - "Same browsing context group" (but different origin) sites.
| These can communicate via various APIs, and historically that
| was achieved by just letting them run in the same rendering
| process. But in the face of attacks such as this one, this
| can be insecure. Firefox and Chrome provide sandboxing via
| separate processes; Safari does not.
|
| - Same origin sites (without any stricter policy). These can
| fully access each other's DOM (if they have an opener/opened
| relationship), so there's not really any point in having them
| live in different renderers except possibly for fault
| isolation (e.g. one of them crashing not taking the other
| down). As far as I know, all browsers render these in the
| same process.
|
| Sites can opt out of the second and third category into the
| first via various HTTP headers and HTML link attributes. If
| we were to design the web from scratch, arguably the default
| for window.open should be the first behavior, with an opt in
| to the second, but that's backwards compatibility for you.
| MikeHolman wrote:
| I worked on a browser team when Spectre/Meltdown came out,
| and I can tell you that a big reason why Firefox and Chrome
| do such severe process isolation is exactly because these
| speculative attacks are almost impossible to entirely
| prevent. There were a number of other mitigations including
| hardening code emitted from C++ compilers and JS JITs, as
| well as attempts to limit high precision timers, but the
| browser vendors largely agreed that the only strong defense
| was complete process isolation.
|
| I'm not surprised to see this come back to bite them if
| after like 7 years Apple still hasn't adopted the only
| strong defense.
| leeter wrote:
| To add to this and to quote a friend who has more NDAs in
| regards to microarchitecture than I can count and thus
| shall remain nameless: "You can have a fast CPU or a
| secure CPU: Pick one". Pretty much everything a modern
| CPU does has side effects that are something that any
| sufficiently motivated attacker can find a way to use
| (most likely). While many are core specific (register
| rename, execution port usage for example), many are not
| (speculative execution, speculative loads). Side channels
| are a persnickety thing, and nearly impossible to fully
| account for.
|
| Can you make a "Secure" CPU? In theory yes, but it won't
| be fast or as power efficient as it could in theory be.
| Because the things that allow those things are all
| possible side channels. This is why in theory the TPM in
| your machine is for those sorts of things (allegedly,
| they have their own side channels).
|
| The harder question is "what is enough?" e.g. at what
| level does it not matter that much anymore? The answer
| based on the post above this is based on quite a lot of
| risk analysis and design considerations. These design
| decisions were the best balance of security and speed
| given the available information at the time.
|
| Sure, can you build that theoretically perfect secure
| CPU? Yes. But, if you can't do anything that actually
| needs security on it because it's so slow; do you care?
| lazide wrote:
| This is also a fundamental property - if you can save
| time in some code/execution paths, but not in others
| (which is a very desirable attribute in most
| algorithms!), and that algorithm is doing something where
| knowing if it was able to go faster or slower has
| security implications (most any crypto algorithm, unless
| _very_ carefully designed), then this is just the way it
| is - and has to be.
|
| The way this has been trending is that in modern systems,
| we try to move as much of the 'critical' security
| information processing to known-slower-but-secure
| processing units.
|
| But, for servers, in virtualized environments, or when
| someone hasn't done the work to make that doable - we
| have these attacks.
|
| So, 'specialization' essentially.
| fsflover wrote:
| > I'm not surprised to see this come back to bite them if
| after like 7 years Apple still hasn't adopted the only
| strong defense.
|
| So the Apple's argument that iOS can't have alternative
| browsers for security is a lie.
| brookst wrote:
| Strange claim.
|
| Security isn't a one-bit thing where you're either
| perfectly secure or not. If someone breaks into your
| house through a window and steals your stuff, that does
| not make it a lie to claim that locking your front door
| is more secure.
|
| In any event, Apple's claim isn't entirely true. It's
| also not entirely false.
|
| Browsers absolutely require JIT to be remotely
| performant. Giving third parties JIT on iOS would
| decrease security. _And also_ we know Apple's fetish for
| tight platform control, so it's not like they're working
| hard to find a way to do secure JIT for 3P.
|
| But a security flaw in Safari's process isolation has
| exactly zero bearing on the claim that giving third party
| apps JIT has security implications. That's a very strange
| claim to make.
|
| Security doesn't lend itself to these dramatic
| pronouncements. There's always multiple "except if"
| layers.
| fsflover wrote:
| The alternative browsers have the required site isolation
| but aren't allowed. There's no fix for Safari and you
| must use it. I think it's very clearly decreasing the
| users' security.
| brookst wrote:
| Binary thinking is unhealthy.
|
| Alternative browsers would introduce other security
| concerns, including JIT. It's debatable whether that
| would be a net security gain or loss, but it's silly to
| just pretend it's not a thing.
|
| Security as the product of multiple risks.
|
| Discovering a new risk does not mean all of the other
| ones evaporate and all decision making should be made
| solely with this one factor in mind.
| fsflover wrote:
| "Decreasing the security" is not binary thinking. It's
| just a fact today. Also, ability to run software doesn't
| make you less secure. I never saw any real proof of that.
| It's the opposite: Competition between different browsers
| forces them to increase the security, and it doesn't work
| for Safari on iOS.
| raxxorraxor wrote:
| I think a detached and distanced perspective must come to
| the conclusion that vendor lock-in isn't healthy. For
| security, performance or flexibility it tends to fall
| short sooner or later.
|
| One could also talk about the relevance of a speculative
| attack that hasn't been abused for years. There can be
| multiple reasons for that, but we shouldn't just ignore
| the main design motivation of Apple here. That would be
| frivolous and that excludes serious security discussions.
| lxgr wrote:
| Can you provide any arguments that JIT would in fact
| decrease security other than "Apple says so"?
|
| Every major mobile and desktop OS other than iOS has
| supported it for over a decade. Apple is just using this
| as a fig leaf.
| lxgr wrote:
| > Giving third parties JIT on iOS would decrease
| security.
|
| Well, at least in this case it would have greatly
| increased security (since it would have allowed the
| availability of actual, native Chrome and Firefox ports).
|
| And otherwise: Does Apple really have zero trust in their
| OS in satisfying the basic functionality of isolating
| processes against each other? This has been a feature of
| OSes since the first moon landing.
| Rohansi wrote:
| If JIT is such a problem then Apple shouldn't use it
| themselves. Sure, they let you disable it but it's still
| enabled by default while everyone pushes the narrative
| that Apple is all about security.
| worthless-trash wrote:
| Are you really surprised, eventually the apple distortion
| field starts to wain around the edges but by then people
| have moved on to the new shiny.
| fortran77 wrote:
| So zealous to defend Apple that you didn't check Firefox and
| Chrome before posting?
| 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.
| Elfir3 wrote:
| They didn't mention the bounds were inclusive either.
| 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?
| ddtaylor wrote:
| AFAIK this only means the attacker has to dupe you into doing
| a UI event like scrolling or clicking or touching something
| on page. Very easy to do.
| yard2010 wrote:
| Safari is Internet Explorer of the 20'
| jabwd wrote:
| This is a flawed comparison in many ways. As you might not
| understand IE was problematic because of its massive install
| base and everyone only, and _only_ writing their websites for
| chrome oh wait. Typo 'd there, meant IE.
| 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.
| avianlyric wrote:
| That might be their point. As the OP quoted
|
| > any virtual address below 0x100, 000, 000 is invalid.
|
| That kinda suggests that all 32bit addresses are inherently
| invalid on 64bit MacOS
| astrange wrote:
| Not inherently, it's just a linker default. You can run
| 32-bit processes through WINE.
| saagarjha wrote:
| Only in Rosetta. On arm64 these binaries will not be
| allowed to load.
| saagarjha wrote:
| Grouping a hex address by threes is crazy
| hmry wrote:
| 3 hex digits = 12 bits = 4096 entries, the size of each
| address translation table on ARM. So it does make some
| (twisted) sort of sense. Assuming you're using 4k page size
| saagarjha wrote:
| macOS/iOS don't
| 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...
| hashstring wrote:
| Right, and "where two subdomains of the same site can be merged
| into one process" is normal right, given Site Isolation [?]
| Origin Isolation.
|
| A PSL flaw is important, but also a low-cost fix.
|
| Thanks for pointing this out.
| 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."_
| trompetenaccoun wrote:
| It's crazy that they were informed about this months ago and
| still have not fixed it yet. They're going to have to now
| that it's public but why would that pressure even be needed.
| I naively assumed if Apple still gets one thing right it's
| security updates. This is disappointing and concerning.
| remram wrote:
| Have you considered that it might be _difficult_?
| 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.
| talldayo wrote:
| > Did use cases exist? Sure. But not sufficiently to move
| the needle on app store usage.
|
| We can't say that for sure. There is no shortage of
| examples where Apple neglects a feature that might
| provide parity with their own services to avoid
| competition. Safari, being a mandatory feature of iOS, is
| reasonably implicated as part of the conspiracy to
| prevent users from buying and selling software without
| the assent of a corporate benefactor.
| 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
| kd913 wrote:
| Am curious if the problem impacts m4 given it came out after
| this was released and disclosed.
|
| That and it moved to Arm's 9.2 instructions.
| saagarjha wrote:
| Yes.
| jabwd wrote:
| Keep in mind that it takes at least 3 months to produce an
| M4, and the design has been finalized long before that. So
| most likely yes
| 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.
| nicce wrote:
| It also feels like that people who are highly determined to
| build high quality, secure software are not valued that much.
|
| It is difficult to prove their effort. One security-related
| bug removes everything, even if it happened only once in 10
| years in 1 million line code base.
| 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.
| hajile wrote:
| Getting funding and good job offers is mostly about
| marketing. Even worse, lots of people controlling the purse
| strings aren't domain experts. In a way, it's no different
| from getting published in specific high-profile publications
| or attending specific universities.
| 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.
| nicce wrote:
| In this case it is very generic domain name. Maybe more
| specific one would be okay, but this is not anymore.
| 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...
| bjackman wrote:
| > I'm pretty sure both AMD[^1] and Intel[^2] have had
| predictive store-to-load forwarding.
|
| IIRC this was how Spectre Variant 4 worked.
| adgjlsfhk1 wrote:
| from doing some work on GC a couple years ago, at that time
| apple was the only one with it. The performance is awesome, it
| makes graph traversal ~2x faster.
| adrian_b wrote:
| In many CPU ISAs, load value predictors are unlikely to be
| useful, because they cannot guess the value that will be loaded
| with an acceptable probability.
|
| The ARM ISA and also other ISAs with fixed-length instruction
| encoding are an exception. Because they have a fixed
| instruction length, typically of 32 bits, most constants cannot
| be embedded in the instruction encoding.
|
| As a workaround, when programming for such ISAs, the constants
| are stored in constant pools that are close to the code for the
| function that will use them, and the load instructions load the
| constants using program-counter-relative addressing.
|
| Frequently such constants must be reloaded from the constant
| pool, which allows the load value predictor to predict the
| value based on previous loads from the same relative address.
|
| In contrast with the Apple ARM CPUs, for x86-64 CPUs it is very
| unlikely that a load value predictor can be worthwhile, because
| the constants are immediate values that are loaded directly
| into registers or are directly used as operands. There is no
| need for constants stored outside the function code, which may
| be reloaded multiple times, enabling prediction.
|
| All fast CPUs can forward the stored data from the store buffer
| to subsequent loads from the same address, instead of waiting
| for the store to be completed in the external memory. This is
| not load value prediction.
| twoodfin wrote:
| Thank you, fantastic answer.
|
| I do wonder if there are other common code patterns that a
| practical LVP could exploit. One that comes to mind
| immediately are effectively constants at one remove: Think
| processing a large array of structs with long runs of
| identical values for some little-used parameter field. Or
| large bitmasks that are nearly all 0xFF or 0x00.
| eigenform wrote:
| > for x86-64 CPUs it is very unlikely that a load value
| predictor can be worthwhile
|
| I think you're making a good point about immediate encodings
| probably making ARM code more amenable to LVP, but I'm not
| sure I totally buy this statement.
|
| If you take some random x86 program, chances are there are
| still _many_ loads that are very very predictable. There 's a
| very recent ISCA'24 paper[^1] about this (which also happens
| to be half-attributed to authors from Intel PARL!):
|
| > [...] we first study the static load instructions that
| repeatedly fetch the same value from the same load address
| across the entire workload trace. We call such a load
| _global-stable_.
|
| > [..] We make two key observations. First, 34.2% of all
| dynamic loads are global-stable. Second, the fraction of
| global-stable loads are much higher in Client, Enterprise,
| and Server work-loads as compared to SPEC CPU 2017 workloads.
|
| [^1]: https://arxiv.org/pdf/2406.18786
| adrian_b wrote:
| Unfortunately what you say is true for many legacy
| programs, but it is a consequence of the programs not being
| well structured by the programmer, or not being well
| optimized by the compiler, or due to a defect of the ISA,
| other than the lack of big immediate constants.
|
| Some of the global-stable values are reloaded because the
| ISA does not provide enough explicitly-addressable
| registers, despite the fact that a modern CPU core may have
| 10 times to 20 times more available registers, which could
| be used to store the global-stable values.
|
| This is one of the reasons why Intel wants to double the
| number of general-purpose directly addressable registers
| from 16 to 32 in the future Diamond Rapids CPU (the APX ISA
| extension).
|
| In other cases the code is not well structured and it tests
| repeatedly some configuration options, which could be
| avoided by a proper partitioning of the code paths, where
| slow tests would be avoided and the execution time would be
| reduced, even at the price of a slight code size expansion
| (similarly to the effect of function inlining or loop
| unrolling).
|
| Sometimes the use of such global-stable values could have
| been avoided even by moving at compile time the evaluation
| of some expressions, possibly combined with dynamic loading
| of some executable objects that had been compiled for
| different configurations.
|
| So I have seen many cases of such global-stable values
| being used, even for CPU ISAs that do not force their use,
| but almost none of them were justified. Improving such
| programs at programming time or at compile time would have
| resulted in greater performance improvements, which would
| have been obtained with less energy consumption, than
| implementing a load-value predictor in the CPU.
| 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.
| alphabetting wrote:
| Is the statement from Apple just PR or is this not a usable
| exploit?
|
| "Based on our analysis, we do not believe this issue poses an
| immediate risk to our users."
|
| https://www.bleepingcomputer.com/news/security/new-apple-cpu...
| keyle wrote:
| Apple PR, which is unlike them; to wave it off.
| hashstring wrote:
| They carefully added "immediate".
| rasz wrote:
| >statement from Apple just PR
|
| remember the iphone 6 battery and butterfly keyboard gate we
| both "small number of users" according to Apple.
| bjackman wrote:
| CPU vendors always say this when an exploit is published before
| they mitigate.
|
| Sometimes they mean "no we don't think it's exploitable",
| sometimes the charitable reading is "we don't think anyone is
| exploiting this and we think developing an exploit will take
| quite some time".
|
| Unfortunately they never reveal exactly that they mean. This is
| very annoying, because when it's the former case, they're often
| right! Security researchers publish bullshit sometimes. But the
| vendors basically leave you to figure it out for yourself.
| philodeon wrote:
| Given that the researchers published working exploits that you
| can modify for your own use, it's PR.
| fulafel wrote:
| And from the paper seems like they played it interestingly in
| the researchers direction as well:
|
| "1.2. Responsible Disclosure
|
| 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. "
| anonymous1213 wrote:
| A great hack
| aucisson_masque wrote:
| > As pointed out by iLeakage, Safari lacks Site Isolation
|
| Well I'm shocked, for such a company that promotes security and
| privacy, apple not having put site isolation into safari seems
| amateurish.
| umanwizard wrote:
| Apple promotes privacy, sure. I'm not sure whether they promote
| security. Of course they are not _against_ security, but I don
| 't remember it being a significant theme in their marketing.
| aucisson_masque wrote:
| I believe it's implied when they say 'what happens on your
| iphone stays on your iphone'.
|
| You can have security without privacy but you can't have
| privacy without security, when they promote privacy they also
| claim to be secure.
|
| No website isolation goes against both of these principles.
| lern_too_spel wrote:
| I consider the world lucky that the Apple apologists haven't
| emboldened Apple to prevent its customers from using other
| browsers on their Macs... yet.
| wswin wrote:
| I'm penchant toward disabling js by default on untrusted sites.
| It's basically someone's programm that we run on our machine and
| apparently we not yet can do sandboxes
| tmshapland wrote:
| Great post, so interesting!
| phendrenad2 wrote:
| Seems like speculative execution is just fundamentally insecure.
| With SPECTRE/MELTDOWN mitigations, doesn't CPU performance drop
| below the same CPU performance with no branch prediction at all?
| Should we move back to CISC? Or maybe VLIW?
| andrewia wrote:
| I don't think so; speculative execution is the cornerstone of
| modern CPU performance. Even 15-year-old 32-bit ARM CPUs do it.
| The only phone/PC-grade processors without it are the first
| generation of Intel Atom, and I recall that early Atom
| processors sacrificed a ton of performance to keep power
| consumption low. I doubt this will change since mitigations are
| "good enough" to patch over major issues.
| happosai wrote:
| There is extremely popular Cortex-A53 which is in-order core.
| MindSpunk wrote:
| Yes and it's very slow as a result. In-order cores without
| speculative execution can't be fast. Not unless you have no
| memory and only operate out of something equivalent to L1
| cache.
|
| Memory is slow. Insanely slow (compared to the CPU). You
| can process stupid fast if your entire working set can fit
| in a 2KB L1 cache, but the second you touch memory you're
| hosed. You can't hide memory latency without out-of-order
| execution and/or SMT. You fundamentally need to be parallel
| to hide latency. CPUs do it with out-of-order and
| speculative execution. GPUs do it by being stupidly
| parallel and running something like 32-64 way SMT (huge
| simplification). Many high-performance CPUs do all of these
| things.
|
| Instruction level parallelism is simply not optional with
| the DRAM latency we have.
| happosai wrote:
| Cortex a53 may be slow, but it's fast enough for very
| many tasks. Once you design the your data structures to
| fit L1/L2 caches it actually is pretty damn fast. Best
| part of cache aware data structure design it also makes
| code run faster on Out Of Order CPUS. A53 is of course
| slow if you use modern layer-upon-layer-ware as your
| architecture.
|
| But I was just really trying to point that in-order cpus
| are still around, they did not disappear with in-order
| atom.
| dailykoder wrote:
| Maybe the boomers were right and we made computers way too
| complex? This might be a bit of a hyperbole, but seems like
| there will always be a security hole (even if mostly hard to
| exploit). But I also guess we can't get much faster without
| it either. So maybe we should reduce complexity. Atleast for
| safety critical systems.
| MagicMoonlight wrote:
| Now wait until the zoomers come along and take the lead on
| these products. They grew up with iPads and no file system.
| It's going to be chaos!
| saagarjha wrote:
| Boomers grew up without a filesystem too and things seem
| to have worked out fine.
| umanwizard wrote:
| > SPECTRE/MELTDOWN mitigations, doesn't CPU performance drop
| below the same CPU performance with no branch prediction at
| all?
|
| No. Processors with no branch prediction would be many times
| slower (up to dozens of times slower on workloads that don't
| fit in cache)
| rasz wrote:
| >speculative execution is just fundamentally insecure
|
| I dont think its inevitable, might be caused by greed. You
| could have small separate sections of cache (or additional tag)
| dedicated to per thread speculation, but no designer is willing
| to sacrifice real estate to something that will be thrown away
| the instantly.
| worthless-trash wrote:
| This isn't just limited to safari. I wonder if this apple fix
| this more thoroughly than spectre and meltdown.
| qquestionne wrote:
| Can browser side channel attacks be made less effective by
| running another compute/branch heavy process?
| akdor1154 wrote:
| Mine shitcoins in a web worker for extra protection?
| qquestionne wrote:
| Sure. Why not? It'd tick a couple of the boxes to possibly
| lower the exploit bitrate...
|
| "Side channel attacks are a class of exploit that infers
| secrets by measuring manifestations such as timing, sound,
| and power consumption"
| TheAtomic wrote:
| Tidal
| ingohelpinger wrote:
| So this attack is still possible even with lockdown mode on?
| saagarjha wrote:
| Yes.
| Malidir wrote:
| why?
| saagarjha wrote:
| It's a processor bug
| BobbyTables2 wrote:
| There are two times in a man's life when he should not speculate:
| when he can't afford it, and when he can.
|
| Mark Twain
| gpderetta wrote:
| CPUs on the other hand do nothing but speculate.
| kapitanluffy wrote:
| does it affect gecko browsers? firefox?
___________________________________________________________________
(page generated 2025-01-29 23:01 UTC)