[HN Gopher] M1racles: An Apple M1 covert channel vulnerability
___________________________________________________________________
M1racles: An Apple M1 covert channel vulnerability
Author : paulgerhardt
Score : 984 points
Date : 2021-05-26 03:02 UTC (19 hours ago)
(HTM) web link (m1racles.com)
(TXT) w3m dump (m1racles.com)
| vignesh_warar wrote:
| >I came here from a news site and they didn't tell me any of this
| at all!
|
| >Then perhaps you should stop reading that news site, just like
| they stopped reading this site after the first 2 paragraphs.
|
| This is my most favorite
| nazgulsenpai wrote:
| > OpenBSD users: Hi Mark!
|
| Ok I nearly fell out of my chair. A+
| bradleybuda wrote:
| Could this be fixed with a microcode update (he asks, not really
| having any idea what microcode is)?
| Operyl wrote:
| Does the M1 even have microcode updates? I haven't seen
| anything pointing to that yet.
| marcan_42 wrote:
| I don't think so, no. If it has microcode it's probably
| burned into sequencer tables, not updatable. I was kind of
| hoping Apple would have some chicken bit register up their
| sleeve as a last resource fix (e.g. "trap on instruction
| encodings matching this mask"), but given that they seem to
| have no useful mitigation for it, I don't think they do.
| londons_explore wrote:
| Is it possible Apple have the silicon functionality to fix
| this, but have decided it isn't worth fixing?
|
| After all, process isolation between cooperating processes
| is nearly impossible to do. If Apple close this loophole,
| there will be other lower bandwidth side channels like
| spinning up the fan in Morse code and the other process
| notices the clock speed scaling up and down...
| marcan_42 wrote:
| It doesn't really make sense not to fix it if they can in
| fact do so easily.
| londons_explore wrote:
| Except software-silicon patches usually have a limited
| number of filters, patch slots, etc. Might not be worth
| using one for this.
| marcan_42 wrote:
| They're using zero so far [0], and until they need it for
| something else it wouldn't make sense not to use it for
| this. The CPU tunables aren't fuses or anything, the OS
| configures them (m1n1 in our case)
|
| [0] https://github.com/AsahiLinux/m1n1/blob/main/src/chic
| kens.c
| 2OEH8eoCRo0 wrote:
| Security through obscurity + walled garden. Brilliant move.
| planb wrote:
| This is the best thing I've seen on the internet for a long time.
| Hopefully some people (tech journalists and twitter folks) will
| "fall for it" and learn along the way...
| kbenson wrote:
| _Was this responsibly disclosed?
|
| I tried, but I also talked about it on public IRC before I knew
| it was a bug and not a feature, so I couldn't do much about that
| part. -\\_(tsu)_/-_
|
| This whole site is a good read. A great mix of real information,
| jokes, and a good send-up of how some security releases appear
| these days (I understand to a degree the incentives that cause
| those sites to be as they are, and I don't think they area all
| bad, but it's still good and useful to poke fun them I think).
| vmception wrote:
| well this is a new genre of satire
| afandian wrote:
| Sorry if I missed it, but what is the defined purpose of the
| s3_5_c15_c10_1 register? Or is it just general purpose?
| marcan_42 wrote:
| It's an implementation-defined register, which means it's up to
| Apple to define it. We have no idea what it does; we haven't
| observed any visible effects from flipping those bits. Given
| that it's per-cluster, we can infer that it has something to do
| with cluster-specific logic. Perhaps memory interface or power
| control.
|
| There are hundreds of Apple implementation-defined registers;
| we're documenting them as we learn more about them [0] [1] [2]
|
| [0]
| https://github.com/AsahiLinux/m1n1/blob/main/tools/apple_reg...
|
| [1] https://github.com/AsahiLinux/docs/wiki/HW%3AARM-System-
| Regi...
|
| [2] https://github.com/AsahiLinux/docs/wiki/HW%3AARM-System-
| Regi...
| Cthulhu_ wrote:
| I googled it for you and err, came up blank, there's just two
| code references in some ASM code, the rest points to this
| resource. Weird, I would have thought things like this would
| have public documentation.
| pthariensflame wrote:
| https://news.ycombinator.com/item?id=27287519
| pthariensflame wrote:
| It's not a standard ARM register; it's implementation-defined
| and nobody gave it a meaningful name. It appears to do nothing
| much.
| exikyut wrote:
| Then why not unofficially standardize its use in GCC and
| Clang's register-pooling subsystem?
| saagarjha wrote:
| Because GCC and Clang don't get to decide what hardware
| does with the register...
| withinboredom wrote:
| I was actually planning to pick up a new Mac today and I've been
| on the fence over M1 or Intel for months. My biggest con for the
| M1 is how proprietary it is. With Intel, you know it's been
| battle-tested for years. Things like this (at best, is an
| oversight, at worst, it's the tip of the iceberg) make the
| decision a little bit easier...
| user-the-name wrote:
| Intel chips are chock full of these same kinds of mistakes.
| filleduchaos wrote:
| > With Intel, you know it's been battle-tested for years.
|
| This is quite an interesting statement to make in the wake of
| Spectre and Meltdown (and vulnerabilities in that class being
| discovered what seems like every couple of months or so).
|
| It's a bit amusing to me how much we overlook clear, even huge
| flaws in products and processes because they're old - sorry,
| Battle-Tested(tm) - while zeroing in on lesser flaws in newer
| ones.
| culturestate wrote:
| I'm almost as impressed that m1racles.com was available as I am
| with people who are good enough at this kind of reverse
| engineering that they can do it for fun.
| bombcar wrote:
| Quick register all words that start with MI for future
| vulnerabilities. I'm waiting for M1RAGE and M1TIGATE myself.
| culturestate wrote:
| You joke but somewhere there's a domainer doing this right
| now.
| dehrmann wrote:
| It'll have a short shelf life. Won't the M2 be out within a
| year?
| jonsen wrote:
| MeToo
| Cthulhu_ wrote:
| Soon enough we'll get the M9 and then the MX because of
| reasons. And SE / Lite / Pro versions.
| insaneirish wrote:
| I would suspect the final versions of M chips for _all_
| the first round Apple Silicon Macs are all taped out with
| no respins planned.
|
| And I further expect that they're already sampling the M
| chips for the subsequent round of products. Heck, they
| may even be completely done as well.
| jwr wrote:
| A "domainer" -- that must be one of the ultimate pejorative
| descriptions of a person.
| [deleted]
| steve_adams_86 wrote:
| Is it though? They refer to themselves as domainers quite
| often. (I work with them indirectly)
| cmehdy wrote:
| I'll give them a couple too: M1GHT, M1CRO*, M1ASMA
| (M1ASTHMA?), M1D*, M1FFED (with some 0xFFED somewhere?),
| M1GRATE (for some particularly pesky data extraction
| hack?), M1LES (for some unit conversion bug that makes the
| first MacOs-based spaceship crash)
| k_sze wrote:
| M1GRAIN for something about atomic ops.
| fooker wrote:
| M1LF
| not2b wrote:
| ... for those who like Apple a bit too much.
| jraph wrote:
| That would be a line feed related parsing vulnerability
| in a messaging app on M1.
| Cybotron5000 wrote:
| M1XOMATOSIS, M1G-29, M1XMASTRM1KE, M1CKEYM1CE,
| M1L1TTLEPWN1E...
| alexeldeib wrote:
| On a hunch I tried "myasthma.com" to see if that spelling
| were free. TIL that redirects to GlaxoSmithKline's en-gb
| homepage!
| arcticbull wrote:
| M1SASMA - for a particularly stinky bug.
| asddubs wrote:
| m1stake, m1aculpa
| ant6n wrote:
| Is m1aculpa like the mar1o spelling of the word? MamaM1a!
| meowface wrote:
| I'm constantly surprised what domains are still available. I've
| registered many 2/3-letter domains (with 3-4 letter TLDs) in
| the past year, as well as ones for very common nouns (some also
| 3 letters), almost always for under $40. Admittedly it's mostly
| for the newer TLDs, though.
| SpelingBeeChamp wrote:
| Similar story. I own a half-dozen relatively recently-
| registered three-letter domains at two-letter ccTLDs. I'm
| surprised every time one turns out to be available at normal
| rates.
| volta83 wrote:
| > in violation of the ARM architecture specification
|
| > Apple decided to break the ARM spec by removing a mandatory
| feature
|
| Is there a page documenting all incompatibilities / violations of
| the ARM architecture specification by the M1?
| saagarjha wrote:
| I wouldn't be surprised if the language gets loosened in the
| next revision of the standard, as it has in the past.
| [deleted]
| Simplicitas wrote:
| I wish all CVE were written this way :-)
| [deleted]
| eyelidlessness wrote:
| I checked this out to find out just... information I guess? I
| don't own an M1 but plan to get an ARM Mac when I can budget it.
| Good to be aware of the landscape.
|
| I was _not_ expecting such an entertaining FAQ. Good job, very
| informative, very amusing!
| madis wrote:
| Why would you spend money on crappy and locked down hardware
| that can't be fixed. A computer that you don't own but
| basically rent. Get a Lenovo Thinkpad and join the light side,
| you'll be amazed!
| princekolt wrote:
| "Aaaaa look at me I am right you are wrong aaaa"
| breakfastduck wrote:
| Whatever your opinions on Apples policies and behavior it's
| just ignorant to call the M1 'crappy' when it absolutely
| annihilates any processor in its class and doesn't at all get
| embarrassed when compared to high end desktop CPUs.
| smoldesu wrote:
| CPUs are a chump's game, and it's no surprise that Apple,
| the company with sole access to next-generation silicon,
| was able to reach last-generation performance on a laptop
| chip. Nobody freaked out when AMD's Ryzen 7 4800u hit 4ghz
| over 8 cores, I don't see a reason why I should freak out
| now when Apple's doing it with 10 less watts.
|
| Plus, that's only the CPU side of things. The M1's GPU is
| annihilated by most GPUs in it's class... from 2014. Fast
| forwards to 2021, and it's graphics performance is honestly
| pathetic. Remember our friend the 4800u? It's integrated
| GPU is able to beat the M1's GPU in raw benchmarks, and it
| came out 18 months before it.
|
| So yeah, I think there are a lot of workloads where the M1
| is a pretty crappy CPU. Unless your workload is CPU-bound,
| there's not really much of a reason to own one. And even
| still, the M1 doesn't guarantee compatibility with legacy
| software. It doesn't have a functional hypervisor, and it
| has lower IO bandwidth than most CPUs from a decade ago.
| Not really something I'd consider viable as a "daily
| driver", at least for my workload.
| breakfastduck wrote:
| Not being viable as _your_ daily driver does not make it
| crappy.
|
| But you heard it here first guys, building CPUs is a
| chumps game. And you see no reason to celebrate the first
| genuinely viable, power-efficient and fast non x86 CPU
| being a mass success. Fine I guess, but I don't agree.
|
| Also not sure why you wave away CPU bound workloads as
| though they don't exist or somehow lesser.
| BusTrainBus wrote:
| Lenovo is a Chinese company.
| mukesh610 wrote:
| So?
| raxxorrax wrote:
| > locked down hardware
|
| not every register!
| ImprobableTruth wrote:
| Well, the performance is pretty good...
| eyelidlessness wrote:
| Why would you let my computer preference affect you this
| much?
| Rantenki wrote:
| I've been stumbling through writing a pile of secure software
| development lifecycle management and disclosure practices
| documentation all evening, and desperately needed a bit of
| levity. This post delivered. Thank you.
|
| Also, I am still not sure if this is a disclosure, performance
| art, or extremely dry comedy, but it certainly covered all the
| bases.
| pokot0 wrote:
| It seems like a single bit available to all apps but that no one
| is really using now. I wonder if a easy software mitigation could
| be just polluting it intentionally.
| [deleted]
| tectonic wrote:
| > Wait. Oh no. Some game developer somewhere is going to try to
| use this as a synchronization primitive, aren't they. Please
| don't. The world has enough cursed code already. Don't do it.
| Stop it. Noooooooooooooooo
| galgalesh wrote:
| Cross-core communication without going through the kernel seems
| like a very useful performance feature for games.
|
| Am I missing something or is it somewhat likely this will be
| "abused" by games?
| jonny_eh wrote:
| Even if it were a performance saver (it isn't), it'd break
| when new silicon is released with this issue fixed.
| lilyball wrote:
| This thing communicates at 1MB/s. A "performance feature" it
| ain't.
| dijit wrote:
| throughput and latency are different measures.
|
| Games usually live in the realm of latency.
| smoldesu wrote:
| who cares, it's not like you're going to use it to send
| textures from one thread to another
| mukesh610 wrote:
| Synchronization primitives AFAIK don't need to transfer
| huge amounts of data in a short time. One bit for every
| "okay" signal would suffice. At the given speed you can
| perform 8 million syncs per second between two threads.
| [deleted]
| Matthias247 wrote:
| You can already communicate between apps without going
| through the kernel by using shared memory - with a much
| higher bandwidth. And even just the regular write/sendmsg/etc
| calls are probably more efficient despite going through the
| kernel due to being able to carry much more bytes.
|
| This was really just a good joke touching how the game
| industry in the past used non-common hardware features for
| optimization purposes.
| lasagnaphil wrote:
| Holy shit, just as I thought we've run out of novel ways of
| playing Bad Apple, here we are...
| breck wrote:
| https://www.youtube.com/watch?v=tO6sfku_1b8
| timeimp wrote:
| Heh, its "baked in" heh
|
| In all seriousness, I wonder what the actual issue is.
|
| Could anyone comment as to the implications of only supporting a
| Type 2 hypervisor that is (as said on the site) "in violation of
| the ARMv8 specification"?
| bombcar wrote:
| One implication is it prevents solutions to things like this.
|
| This one is a minor side note but there could be other
| vulnerabilities that could be resolved if the specifications
| were followed (I assume).
| marcan_42 wrote:
| You can still solve the issue in VHE mode, since you can
| still implement a Type 1 hypervisor in VHE mode. It's just
| that, well, nobody does that, because why would they? That's
| what non-VHE mode is for.
|
| So it's not that not following the spec prevents the
| workaround, it's just that had they followed the spec it
| would just take a single kernel command line argument (to
| force non-VHE mode) to fix this in Linux, while instead, now
| we'd have to make major changes to KVM to make the non-VHE
| code actually work with VHE, and really nobody wants to do
| that just to mitigate this silly thing.
|
| Had this been a more dangerous flaw (e.g. with DoS or worse
| consequences), OSes would be scrambling to make major reworks
| right now to mitigate it in that way. macOS would have to
| turn its entire hypervisor design on its head. Possible, but
| not fun.
| withinboredom wrote:
| Are there any legal ramifications for them not following
| the spec?
| marcan_42 wrote:
| The implications are just that OSes that assume otherwise won't
| run; Linux used to work (by chance) until a patch that just
| about coincided with our project went in that used the non-VHE
| ("type 1") mode by default, which broke it, and then we had to
| add an explicit workaround for the M1.
|
| It's just a very unfortunate coincidence that precisely that
| support would allow this bug to be trivially mitigated on
| Linux. (Wouldn't help macOS, as they'd have to implement this
| from scratch anyway; it's just that _existing_ OSes that
| support this mode could use it).
|
| The actual issue is just what I described: the hardware
| implementation of this register neglects to check for and
| reject accesses from EL0 (userspace). It's a chip logic design
| flaw. I don't know exactly where it is (whether in the
| core/instruction decoder, or in the cluster component that
| actually holds the register, depending on where they do access
| controls), but either way that's what the problem is.
| m1keil wrote:
| This doesn't look like an issue that deserves its own website
| tbh.
| rvz wrote:
| That's the whole point M1keil.
| floatingatoll wrote:
| The author agrees with you partway down the page.
| pthariensflame wrote:
| I think that was the point. XD
| jkaplowitz wrote:
| The content of the website basically makes that point itself.
| It's mocking the whole concept of these vulnerability websites,
| while also presenting a real (but not very impactful)
| vulnerability.
| m1keil wrote:
| Oh, right. sorry, I sort of bailed on the whole FAQ thing
| when it was silly joke after joke but I get it now. It's the
| onion news of CVEs.
| marcan_42 wrote:
| It's real though, The Onion is largely fake/jokes.
| rswail wrote:
| The Onion almost gave up in the 2016-2020 period because
| their satire was overtaken by the actual headlines.
| mnw21cam wrote:
| Ah, but did they write a story about that?
| [deleted]
| Woodi wrote:
| Wait, did he just, as exploit proof of concept, infiltrated some
| catch music&&video clip ? With life rendering on same CPU ? :>
|
| Anyway - Apple did it again ! In shiny, new hardware for
| "creative" ppl introduced hardware backdors... Like FireWire and
| Thunderbird. Seriously, there must be some market for spying on
| writers and painters. Or anyone who do thing and is rich...
| exikyut wrote:
| Bad Apple goes much deeper than that. IMHO this pretty much
| retires it.
| alberth wrote:
| ELI5, anyone.
|
| Are the chip registers not protected? What's the mechanism that's
| allowing this data sharing to happen?
| peteretep wrote:
| > So what's the real danger?
|
| > If you already have malware on your computer, that malware
| can communicate with other malware on your computer in an
| unexpected way.
|
| > Chances are it could communicate in plenty of expected ways
| anyway.
| [deleted]
| josephcsible wrote:
| There's two bits of a CPU's register that are shared between
| all of its processes and that any process can write to. The
| result is that two sandboxed processes that are supposed to be
| totally isolated from each other can use this to communicate
| anyway. One example of how this can be exploited is cross-app
| tracking: if you told one app your name and another your
| location, they could secretly communicate with each other so
| both apps end up with both pieces of information.
| acchow wrote:
| Sounds like this is by design and not really a newly
| discovered vulnerability. Maybe more of a discovery of
| deceptive advertising/documentation? Which is to say that
| Apple's engineers are reading this as non-news.
| SilverRed wrote:
| >they could secretly communicate with each other so both apps
| end up with both pieces of information
|
| The could also just both ping a server to exchange data.
| Aissen wrote:
| One has access to the internet, the other has not (but has
| less info).
| herpderperator wrote:
| Why couldn't a future OS update add access control to these
| registers?
| josephcsible wrote:
| Because the CPU doesn't provide a practical means to do so.
| herpderperator wrote:
| Doesn't the kernel control CPU access?
| marcan_42 wrote:
| The kernel doesn't get a say in what instructions a
| userspace program can run, other than what the CPU is
| designed to allow it to control. The bug is the CPU
| designers forgot to allow it to control this one.
| dezgeg wrote:
| Couldn't there be another register that controls whether
| access to the problematic register in EL0 is allowed,
| though?
| saagarjha wrote:
| Apple could "mitigate" this by refusing to sign code
| interacting with s3_5_c15_c10_1, I guess.
| josephcsible wrote:
| Doesn't Rice's theorem mean that they cannot?
| cokernel_hacker wrote:
| I believe that Rice's theorem is about computability, not
| about whether or not it is possible to validate which CPU
| instructions a program can contain.
|
| With certain restrictions, it is possible to do this:
| Google Native Client [1] has a verifier which checks that
| programs it executed did not jump into the middle of
| other instructions, forbade run-time code generation
| inside of such programs, etc.
|
| [1]: https://en.wikipedia.org/wiki/Google_Native_Client
| saagarjha wrote:
| Jumping in the middle of other instructions is not a
| problem on ARM.
| josephcsible wrote:
| Yes, but then you're not just blocking instructions that
| touch s3_5_c15_c10_1; you're also blocking a bunch of
| other kinds of instructions too.
| ynik wrote:
| There's three cases:
|
| 1) the program does not contain an instruction that
| touches s3_5_c15_c10_1
|
| 2) the program contains an instruction that touches
| s3_5_c15_c10_1, but never executes that instruction
|
| 3) the program contains an instruction that touches
| s3_5_c15_c10_1, and uses it
|
| Rice's theorem means we cannot tell whether a program
| will touch the register at runtime (as that's a dynamic
| property of the program). But that's because we cannot
| tell case 2 from case 3. It's perfectly decidable whether
| a program is in case 1 (as that's a static property of
| the program).
|
| Any sound static analysis must have false positives --
| but those are exactly the programs in case 2. It doesn't
| mean we end up blocking other kinds of instructions.
| anyfoo wrote:
| (What other kinds of instructions? Genuinely asking.)
|
| I don't think Rice's Theorem applies here. As a
| counterexample: On a hypothetical CPU where all
| instructions have fixed width (e.g. 32 bits), if
| accessing a register requires the instruction to have,
| say, the 10th bit set, and _all_ other instructions don
| 't, _and_ if there is no way to generate new instructions
| (e.g. the CPU only allows execution from ROM), then it is
| trivial to check whether there is any instruction in ROM
| that has bit 10 set.
|
| The next part I'm less sure how to state it rigorously
| (I'm not in the field): In our hypothetical CPU, I think
| disallowing that instruction either lets you remain being
| Turing Complete or not. In the former case, it's still
| the case that you can _compute_ everything a Turing
| Machine can.
| josephcsible wrote:
| You'd have to add one extra condition to your
| hypothetical CPU: that it can't execute unaligned
| instructions. Given that, then yes, that lets you bypass
| Rice's theorem, even though it is indeed still Turing-
| complete.
|
| But the M1 does have a way to "generate new instructions"
| (i.e., JIT), so that counterexample doesn't hold for it.
| johncolanduoni wrote:
| With the way Apple allows implementation of JIT on the M1
| (with their custom MAP_JIT flag and
| pthread_jit_write_protect_np) it is actually possible to
| do this analysis even with JIT code. Since it enforces
| W^X (i.e. pages cannot be writable or executable at the
| same time) it gives the OS opportunity to inspect the
| code synchronously before it is rendered executable.
| Rosetta 2's JIT support already relies on this kind of
| inspection to do translation of JIT apps.
| saagarjha wrote:
| M1 enforces W^X through SPRR, which does not involve the
| kernel.
| johncolanduoni wrote:
| It does when running native ARM code (but not x86 code),
| but AFAIK nothing stops Apple from changing this to being
| kernel mediated by updating libSystem in the ARM case as
| well. Of course I doubt they would take the performance
| hit just to get rid of a this issue.
| josephcsible wrote:
| https://news.ycombinator.com/item?id=27286771
| anyfoo wrote:
| Yes, indeed, I should have stated "cannot execute
| unaligned instructions". Or have said 8 bit instead, then
| it would be immediately obvious what I mean. (You cannot
| jump into the middle of a byte because you cannot even
| address it.)
|
| But I wanted to show how Rice's Theorem does not
| generally apply here. You can make up other examples: A
| register that needs an instruction with a length of 1000
| bytes, yet the ROM only has 512 bytes space etc...
|
| As for JIT, also correct (hence my condition), though
| that's also a property of the OS and not just the M1 (and
| on iOS for example, it is far more restricted what code
| is allowed to do JIT, as was stated in the thread
| already).
| marcan_42 wrote:
| Only on iOS. On macOS, JITs are allowed (as is ad-hoc
| signed code if you click through the warnings).
|
| However, this would be prone to false positives, as
| constant pools are in the executable section on ARM.
| SheinhardtWigCo wrote:
| Let's say someone submits a malicious keyboard with the
| bad instructions hidden in a constant pool.
|
| Apple can't just scan for a bad byte sequence in
| executable pages because it could also represent
| legitimate constants used by the program. (not sure if
| this part is correct?)
|
| If so, doesn't that make detection via static analysis
| infeasible unless LLVM is patched to avoid writing bad
| byte sequences in constant pools? Otherwise they have to
| risk rejecting some small number of non-malicious
| binaries, which might be OK, depending on the likelihood
| of it happening.
| [deleted]
| kevingadd wrote:
| Registers aren't resources you access through syscalls,
| there's no way for the kernel to control them unless
| you're running under virtualization or the CPU
| architecture specifically allows access control for the
| register. (As the site notes, virtualization allows
| controlling access to this register)
| kolbusa wrote:
| Can kernel scan each page it maps as executable and
| return an error if it finds instructions interacting with
| the 'bad' register? Assuming the kernel requires
| executable pages to be read-only (W^X), this may even be
| doable (but probably very very slow).
| josephcsible wrote:
| > Assuming the kernel requires executable pages to be
| read-only (W^X)
|
| Which macOS's kernel doesn't.
| marcan_42 wrote:
| It does require that, but it allows flipping between RX
| and RW at will (for JITs), and the M1 actually has
| proprietary features to allow userspace to do this
| without involving the kernel, so the kernel couldn't re-
| scan when those flips happen (plus it would kill
| performance anyway).
|
| Plus, as I said above, this is prone to false positives
| anyway because the executable section on ARM also
| includes constant pools.
| josephcsible wrote:
| Can't a MAP_JIT region be writable by one thread and
| executable by a different thread at the same time?
| anyfoo wrote:
| https://developer.apple.com/documentation/apple-
| silicon/port...
| josephcsible wrote:
| That link confirms that it can:
|
| > Because pthread_jit_write_protect_np changes only the
| current thread's permissions, avoid accessing the same
| memory region from multiple threads. Giving multiple
| threads access to the same memory region opens up a
| potential attack vector, in which one thread has write
| access and another has executable access to the same
| region.
| marcan_42 wrote:
| Ah, yes, I forgot about that. So indeed there is no non-
| racy hook point for the kernel to do such a check, even
| if it made sense and the RX/RW switch went through the
| kernel, which it doesn't.
| CGamesPlay wrote:
| There's more specific answers here, but in general the
| answer to this question is "only partly". The kernel is
| what initially gives your process a time slice on the
| CPU, by setting an alarm for the CPU to return control to
| the kernel at the end of the time slice, and then just
| jumping into your code. During your time slice, you can
| do anything you want to the CPU, and in general only
| interrupts (timer interrupts, hardware interrupts, page
| faults, etc) will cause the kernel to get involved again.
| There are some specific features that CPU designers add
| to give extra control to the kernel, but that's a feature
| of the CPU and it's only when the CPU has explicitly
| added that type of control.
| saagarjha wrote:
| > The kernel is what initially gives your process a time
| slice on the CPU, by setting an alarm for the CPU to
| return control to the kernel at the end of the time
| slice, and then just jumping into your code.
|
| Somewhat critically, it will also drop down to EL0.
| anyfoo wrote:
| Because the OS has no say. A running program issues an
| assembly instruction to the CPU to read or write this
| register, and the CPU complies.
|
| For the OS to have a say, the CPU would need to provide a
| way where the OS tells it (usually by setting certain
| values in other registers) that the CPU should not allow
| access, at least under certain circumstances.
|
| The article actually does go into certain situations where
| the access is more restricted (search for "VHE"), but also
| in how that does not really apply here.
| amelius wrote:
| The OS can scan the program for instructions that access
| these bits. If necessary on a per-basic-block basis.
| saagarjha wrote:
| Of course, this only works if you can't introduce new
| code without the kernel noticing.
| amelius wrote:
| Yes, you can introduce new code but the kernel should
| also watch for that (JIT compilation etc.) and check the
| resulting code. It's quite involved, and the whole
| process looks more like a sandbox or emulator, but it's
| possible.
| saagarjha wrote:
| Doing this performantly is going to be very prohibitive.
| amelius wrote:
| Perhaps (depends also on CPU support), but on the other
| hand: in today's world with untrusted apps, the kernel
| will have to do some sandboxing anyway.
| Wowfunhappy wrote:
| Could the OS intentionally clear or write dummy data to
| the register instead?
| josephcsible wrote:
| No. The author explained why not:
|
| > originally I thought the register was per-core. If it
| were, then you could just wipe it on context switches.
| But since it's per-cluster, sadly, we're kind of screwed,
| since you can do cross-core communication without going
| into the kernel.
| slver wrote:
| You gotta access those bits though some instructions
| though. What if the command pipeline filters those
| instructions.
| x0054 wrote:
| You are working here with CPU registers. At this point
| the OS has no say, it's a hardware bug. Not a
| particularly serious one though.
| slver wrote:
| I didn't say the OS filters the pipeline. Modern CPUs
| have a lot of updateable microcode, including how it
| handles its command pipeline.
| throwaheyy wrote:
| Modern x86/x64 CPUs. The M1 might not have updatable
| microcode.
| dev_tty01 wrote:
| Apple might consider microcode a vulnerability. Certainly
| a double-edged knife.
| marcan_42 wrote:
| There is no indication that the M1 has updatable
| microcode, nor any other features that might allow such
| mitigation. (If it did, Apple would've fixed it; I did
| give them a 90 day disclosure warning and they're not
| lazy about fixing actual fixable bugs.)
| ncr100 wrote:
| Aw - that was what I was worried about - without
| updatable microcode :nuke:.
| tomerdmann wrote:
| https://news.ycombinator.com/item?id=27286918
| [deleted]
| anyfoo wrote:
| Can you elaborate what you mean? What is the "command
| pipeline" here?
| BoorishBears wrote:
| Your computer might spontaneously combust.
| peter422 wrote:
| There is a small bit of memory that all programs on your
| computer share that isn't protected in any way. If two
| misbehaving programs on your computer wanted to communicate in
| a really really secret way, they could use it.
|
| If you don't have misbehaving programs on your computer that
| want to secretly communicate than it doesn't matter.
| [deleted]
| phnofive wrote:
| > So what's the real danger?
|
| > If you already have malware on your computer, that malware
| can communicate with other malware on your computer in an
| unexpected way.
|
| > Chances are it could communicate in plenty of expected ways
| anyway.
| [deleted]
| [deleted]
| 0xakhil wrote:
| How about randomising/reset these bits from kernel whenever there
| is a syscall? Not a great workaround but this should limit the
| effectiveness of leaking. Yeah, there will be tiny perf hit due
| to extra register read and write.
| NobodyNada wrote:
| > Wait, didn't you say on Twitter that this could be mitigated
| really easily?
|
| > Yeah, but originally I thought the register was per-core. If
| it were, then you could just wipe it on context switches. But
| since it's per-cluster, sadly, we're kind of screwed, since you
| can do cross-core communication without going into the kernel.
| Other than running in EL1/0 with TGE=0 (i.e. inside a VM
| guest), there's no known way to block it.
|
| In other words: this register is shared between cores, so if
| the two processes are running simultaneously on different
| cores, they can communicate by reading & writing directly to &
| from this register, without any operating system interaction.
| CJefferson wrote:
| Unfortunately, you can use this to send thousands of bits
| between syscalls, so the simplest error correction would fix
| that, with very little effort or overhead.
| marcan_42 wrote:
| The demo already uses error correction (I'm not sure exactly
| what causes the errors, but I'm guessing the processes
| sometimes end up briefly scheduled on the other core cluster)
| __d wrote:
| > Newton OS users: I guess those are technically Apple Silicon
| but...
|
| The Newton wasn't really Apple Silicon: The
| OMP/MP100/MP110/MP120/MP130 ran an ARM610. The eMate300 ran an
| ARM710. The MP2000/MP2100 ran a DEC StrongARM SA-110 CPU.
|
| None of which were designed or manufactured by Apple.
| phire wrote:
| At the time, Apple owned 50% of ARM.
|
| ARM, the company only existed because Apple wanted them to
| manufacture a CPU for it's Newton project.
|
| While Apple might not have designed the ARM610, but they
| technically owned it.
| klelatti wrote:
| > At the time, Apple owned 50% of ARM.
|
| Nope, Apple never owned 50% of ARM.
|
| > ARM, the company only existed because Apple wanted them to
| manufacture a CPU for it's Newton project.
|
| Who knows what would have happened had Apple not invested but
| Apple was never ARM's only customer.
|
| > While Apple might not have designed the ARM610, but they
| technically owned it.
|
| If I own some Apple shares reasonably sure that doesn't mean
| that "technically" I own the M1.
| __d wrote:
| I did say "designed or manufactured" ... but I'll concede the
| point that they had some ownership of the 610/710, at least.
|
| On 27 Nov 1990, ARM was formed with Apple owning 43%
| alongside Acorn (the designer), and VLSI Technology (the
| manufacturer).
|
| Funny thing: I've found two articles that claim two different
| purchase prices for that 43%: one $3M [0] and the other $1.5B
| [1]. That's quite a difference!
|
| [0] https://appleinsider.com/articles/20/06/09/how-arm-has-
| alrea...
|
| [1] https://www.cultofmac.com/97055/this-is-how-arm-saved-
| apple-...
| [deleted]
| tonyedgecombe wrote:
| ARM was a joint venture between Acorn Computers, Apple Computer
| and VLSI Technology so it's not that clear cut.
| blendergeek wrote:
| My favorite part of the entire page:
|
| > So what's the point of this website?
|
| > Poking fun at how ridiculous infosec clickbait vulnerability
| reporting has become lately. Just because it has a flashy website
| or it makes the news doesn't mean you need to care.
|
| > If you've read all the way to here, congratulations! You're one
| of the rare people who doesn't just retweet based on the page
| title :-)
| meowface wrote:
| In case anyone was confused by this comment: it's not a
| hoax/joke site. It's a real bug; just a low-severity one that's
| intentionally overhyped.
| lamontcg wrote:
| Heh, I couldn't get through it because of the toxic levels of
| self promotion and was about to get very ranty about it all.
| philbert101 wrote:
| Maybe you missed the disclaimer at the top?
|
| "CVE-2021-30747 Should you be worried? Probably not."
| lamontcg wrote:
| Yes, I got that from the top comment here.
| umanghere wrote:
| While Marcan has written in a very entertaining fashion, there is
| perhaps one application of this vulnerability that wasn't
| considered.
|
| If this can be reproduced on the iPhone, it can lead to 3rd party
| keyboards exfiltrating data. By default, keyboard app extensions
| are sandboxed away from their owning applications [0], but they
| may communicate with the app over this channel and leak data.
| It's not as easy as I describe because the app would have to be
| alive and scheduled on the same cluster, but it's within the
| realm of possibility.
|
| [0]:
| https://developer.apple.com/library/archive/documentation/Ge...
| GuB-42 wrote:
| This exact use case is touched on in the article.
|
| Here is the follow-up
|
| > However, since iOS apps distributed through the App Store are
| not allowed to build code at runtime (JIT), Apple can
| automatically scan them at submission time and reliably detect
| any attempts to exploit this vulnerability using static
| analysis (which they already use). We do not have further
| information on whether Apple is planning to deploy these checks
| (or whether they have already done so), but they are aware of
| the potential issue and it would be reasonable to expect they
| will. It is even possible that the existing automated analysis
| already rejects any attempts to use system registers directly.
| marcan_42 wrote:
| Full disclosure: I added this after the parent comment (and
| others) mentioned this case. :)
| ncr100 wrote:
| Thanks - yeah that is a real flaw.
|
| Obfuscated malware where the malicious part is not obvious;
| it's distributed and requires a separate process/image.
|
| Curious to see if some smart Apple-ers can invent a fix for
| this, though it seems like "no way" given the
| vulnerability.
| Angostura wrote:
| Possibly, the article has been updated in the last couple of
| hours, but it now says:
|
| *What about iOS?*
|
| iOS is affected, like all other OSes. There are unique privacy
| implications to this vulnerability on iOS, as it could be used
| to bypass some of its stricter privacy protections. For
| example, keyboard apps are not allowed to access the internet,
| for privacy reasons. A malicious keyboard app could use this
| vulnerability to send text that the user types to another
| malicious app, which could then send it to the internet.
| gostsamo wrote:
| IPhones use A12/13/14 chip and the vulnerability is not
| confirmed there. Also, the post mentions that if you have two
| malware apps on your device, they can communicate in many other
| ways, so I'm not sure what's new here.
|
| Edit: fixed name of the chip.
| Closi wrote:
| iPad contains an m1 chip so that might be a similar better
| example.
| saagarjha wrote:
| I just tested it on the A14 and it seemed to work there.
| withinboredom wrote:
| I wonder if it would have passed Apple's review process?
| saagarjha wrote:
| At this point I would hope that App Store ingestion would
| filter for this.
| umanghere wrote:
| iPhones do not use the A1 chip as of quite a few years ago.
| Besides, the M1 and the A12+ have significant
| microarchitectural similarities, to the point that the DTK
| used the A12Z.
|
| Furthermore, the keyboard app extension and the keyboard app
| are installed as a single package whose components are not
| supposed to communicate, hence why I brought this up.
| dfox wrote:
| I believe that only significant difference between A14 and
| M1 (apart from package) is number of cores.
| gostsamo wrote:
| The only 1 in the name of the chip is typo. The rest I'm
| still not sure if it is significant.
| m3kw9 wrote:
| There would be code signatures that can detect this use by
| apple?
| api wrote:
| Detection is very hard if the developer employs very clever
| obfuscation. See: halting problem.
| eloff wrote:
| Only if detection requires solving the halting problem. It
| does not. You just look for certain instructions that
| normal code shouldn't use. JIT isn't allowed (which means
| all instructions the program uses can be checked
| statically), so it should be easy enough.
| sangnoir wrote:
| > JIT isn't allowed
|
| So, it's basically an honor system. You cannot detect
| JIT, because there aren't "certain instructions" that
| aren't allowed - it's just certain registers that
| programs shouldn't access (but access patterns can be
| changed in branching code to ensure Apple won't catch it
| in their sandboxes).
|
| Besides, even if certain instructions are not allowed, a
| program can modify itself, it's hard to detect if a
| program modifies itself without executing the program
| under specific conditions.
| eloff wrote:
| You're missing the point, JIT not allowed means programs
| may not modify themselves. They're in read+execute only
| memory and cannot allocate writable+executable memory.
| SheinhardtWigCo wrote:
| Marcan said elsewhere in the thread that the executable
| section on ARM also includes constant pools, so if I
| understand correctly, you can hide instructions in there
| and make it intractable for a static analyzer to
| determine whether they are really instructions or just
| data.
|
| The real saving grace here is that iOS app binaries are
| submitted as LLVM IR instead of ARM machine code.
| jshier wrote:
| Only on watchOS is Bitcode required (to support the
| watch's 32-bit to 64-bit transition), on all other
| platforms it's optional and often turned off, as it makes
| a variety of things harder, like generating dSYMs for
| crash reporting.
| SheinhardtWigCo wrote:
| Oh. Then I don't see how this can be reliably mitigated,
| other than patching LLVM to avoid writing the `msr
| s3_5_c15_c10_1` byte sequence in constant pools and then
| rejecting any binary that contains the byte sequence in
| an executable section. That seems difficult to get done
| before someone is able to submit a PoC malicious keyboard
| to the store, potentially turning this "joke" bug into a
| real problem. What am I missing?
| eloff wrote:
| That's problematic. Allowing the constant pools in
| executable memory is a bad idea.
|
| Data segments should go in read only memory with no write
| or execute permission.
| a1369209993 wrote:
| > you can hide instructions in there and make it
| intractable for a static analyzer to determine whether
| they are really instructions or just data.
|
| Uh, no? This is very tractable - O(N) in the size of the
| binary - just check, for every single byte offset in
| executable memory, whether that offset, if jumped to or
| continued to from the previous instruction, would decode
| into a `msr s3_5_c15_c10_1, reg` or `mrs reg,
| s3_5_c15_c10_1` instruction.
|
| IIUC, the decoding of a M1 ARM instruction doesn't depend
| on anything other than the instruction pointer, so you
| only need one pass, and you only need to decode one
| instruction, since the following instruction will occur
| at a later byte address.
|
| Edit: unless its executable section isn't read-only, in
| which case static analyzers can't prove much of anything
| with any real confidence.
| sangnoir wrote:
| > JIT isn't allowed
|
| So, it's basically an honor system. You cannot detect
| JIT, because there aren't "certain instructions" that
| aren't allowed - it's just certain registers that
| programs shouldn't access (but access patterns can be
| changed in branching code to ensure Apple won't catch it
| in their sandboxes).
|
| Besides, even if certain instructions are not allowed, a
| program can modify itself, it's hard to detect if a
| program modifies itself without executing the program
| under specific conditions, or running the program in a
| hypervisor.
| marcan_42 wrote:
| I expect Apple to include checks for this in their App Store
| static analyzer, if they aren't already rejecting sysreg
| instructions, which mitigates the issue. Obviously JIT isn't
| allowed in the App Store, so this should be an effective
| strategy.
| rmst wrote:
| How convenient for Apple. Now they finally have a good
| argument to keep forbidding JIT compilation and side-loading.
| inetknght wrote:
| > _Now they finally have a good argument to keep forbidding
| JIT compilation and side-loading._
|
| The argument was there the entire time. Some people just
| buried their heads in the sand though.
| notaplumber wrote:
| > "OpenBSD users: Hi Mark!"
|
| This is Mark Kettenis, who has despite comments made jokingly by
| marcan, been working with a few other OpenBSD developers to
| bring-up OpenBSD/arm64 on the Apple M1. At least on the Mac Mini
| the Gigabit Ethernet works, Broadcom Wi-Fi, and work on the
| internal NVMe storage is progressing.
|
| There was an early teaser dmesg posted in Feburary showing
| OpenBSD booting multi-user (on bare metal):
| https://marc.info/?l=openbsd-arm&m=161386122115249&w=2
|
| Mark has also been adding support for the M1 to the U-Boot
| project, which will not only benefit OpenBSD, but also Asahi
| Linux.
|
| Another OpenBSD developer posted these screenshots and videos on
| Twitter.
|
| https://twitter.com/bluerise/status/1359644736483655683
|
| https://twitter.com/bluerise/status/1354216838406823936
| ncr100 wrote:
| Is the risk that malicious software can be split into multiple,
| obfuscated components?
|
| Without such a silicon vulnerability the malicious process would
| need all its components within a single process/image?
| Iv wrote:
| > So what's the point of this website?
|
| > Poking fun at how ridiculous infosec clickbait vulnerability
| reporting has become lately. Just because it has a flashy website
| or it makes the news doesn't mean you need to care.
|
| > If you've read all the way to here, congratulations! You're one
| of the rare people who doesn't just retweet based on the page
| title :-)
| ddtaylor wrote:
| That's reassuring to read. I opened the page, read a bit of it,
| pressed play on the video and scrubbed around a bit, got
| irritated and closed the tab. I figured if it mattered I would
| wait until better coverage came out.
| ulzeraj wrote:
| I love the choice of music. Very appropriate.
| 1f60c wrote:
| > Was this responsibly disclosed?
|
| >
|
| > I tried, but I also talked about it on public IRC before I knew
| it was a bug and not a feature, so I couldn't do much about that
| part. -\\_(tsu)_/-
|
| That seems... _unwise_ to admit publicly.
| peteretep wrote:
| "So you're telling me I shouldn't worry? Yes."
| wejkfwe wrote:
| So, all the great performance of M1 was achieved due to the poor
| security?
| saagarjha wrote:
| They are entirely unrelated.
| fulafel wrote:
| > It violates the OS security model. You're not supposed to be
| able to send data from one process to another secretly.
|
| I'd argue this is not the case. What mainstream operating systems
| have made credible attempts to eliminate covert channels from eg
| timing or resources that can be made visible by cooperating
| processes across user account boundaries?
| zozbot234 wrote:
| > What mainstream operating systems have made credible attempts
| to eliminate covert channels from eg timing or resources that
| can be made visible by cooperating processes across user
| account boundaries?
|
| The answer will depend on whether you consider Multi-Level
| Security (MLS)
| https://en.wikipedia.org/wiki/Multilevel_security "mainstream".
| It's certainly a well-established approach if only in an
| academic sense, and the conflux of new use cases (such as
| secretive, proprietary "apps" being expected to manage
| sensitive user data) and increasingly-hard-to-mitigate info
| disclosure vulnerabilities has made it more relevant than ever.
| angrygoat wrote:
| Yes, exactly. Multics actually tried, here's a memo from 1974
| discussing the issue: https://multicians.org/mtbs/mtb696.html
|
| Paged shared libraries, signalling by ramping up and down CPU
| usage, there are an enormous number of possible covert
| channels.
| geocar wrote:
| > I'd argue this is not the case. What mainstream operating
| systems have made credible attempts to eliminate covert
| channels from eg timing or resources that can be made visible
| by cooperating processes across user account boundaries?
|
| All of them.
|
| A piece of software able to read my mail but not use the
| Internet could _credibly_ be a tool to help me index and find
| my email using search keywords. It promises to not use the
| Internet, and indeed nm /objdump shows no use of networking
| tools.
|
| Another piece of software able to monitor RSS feeds I am
| interested in and alert me to their changes is _expected_ to
| use the Internet, but not the filesystem, and surely not the
| part of the filesystem that contains my email. I can use strace
| /dtruss to verify it never touches the filesystem, and use
| chroot/jail to keep it honest.
|
| This being said, I agree that "mainstream operating systems"
| (meaning Windows and macOS, but not perhaps iOS) don't do
| enough and _it might be impossible for them_ without changing
| user expectations[1], but I think they 're trying. Web browsers
| disabled high resolution timers _specifically_ to protect
| against this sort of thing. iOS doesn 't permit arbitrary
| background tasks from running to protect battery and ostensibly
| privacy. But they could all do better.
|
| [1]: For example, for me high CPU load is a red flag - a
| program that does this to me regularly gets put into a VM so
| that I can mess with its time-- Zoom now loses about a minute
| every three if it's not focused which is annoying because it
| messes with the calendar view, but I'm pretty sure it can't do
| anything else I don't want it to. Who should do this work? My
| operating system? Zoom? Neither will do it if users don't
| demand it.
| fulafel wrote:
| So my point as it applies to this example: the email indexing
| program could communicate towards the rss program using cpu
| or storage load spikes. And no widely used multitasking OS
| tries to prevent this.
| londons_explore wrote:
| Indeed.
|
| Without this vulnerability, there would still be a million ways
| to send data between cooperative processes running as different
| users on Mac OS X.
|
| For example, a process could start subprocesses at a
| deterministic rate and the other end of the covert link
| observes how fast the pid counter is going up.
|
| This is a non-vulnerability, because it targets something there
| was no effort to protect.
| Cthulhu_ wrote:
| It's not really a vulnerability as the FAQ states, but it
| violates the operating system's own application isolation
| policies. If you don't want your Facebook app to talk to your
| Instagram app (e.g. different accounts for different
| purposes), you should be able, as a user, to block
| communication between the two. This is a backdoor to
| circumvent that.
|
| I mean not that anyone has a native Facebook or Instagram app
| on their device, but just to name an example.
| vbsteven wrote:
| > I mean not that anyone has a native Facebook or Instagram
| app on their device, but just to name an example.
|
| The M1 is used in the iPad Pro so your example is
| definitely possible. (or your comment was sarcasm in which
| case: woosh to myself)
| [deleted]
| apetresc wrote:
| Out of curiosity, which public IRC channel was this being
| discussed in, before it was understood to be a bug? That sounds
| like a fun channel.
| apetresc wrote:
| Ah, looking more into it, I'm going to guess it was #asahi or
| #asahi-dev.
| marcan_42 wrote:
| Yup, here's the log if you're curious :-)
|
| https://oftc.irclog.whitequark.org/asahi/2021-02-24#29220558
| [deleted]
| sebmellen wrote:
| Actually not a bad song [0]. Thanks to whoever made this, I guess
| :D
|
| [0]: https://www.youtube.com/watch?v=i41KoE0iMYU
| marcan_42 wrote:
| I had to use that one for this demo for obvious reasons, but if
| I'm allowed the shameless plug, I actually make my own music in
| the same genre (Touhou rearrangements) [0]. I'm actually very
| much looking forward to moving my music production to M1 and
| seeing what the real-time performance is like, though that will
| depend on us having at least a usable Rosetta-like thing on
| Linux to run x86 Windows apps (which will allow me to bridge
| the few x86 Windows plug-ins I rely on with yabridge, as I do
| today on x86) :-)
|
| [0]
| https://www.youtube.com/playlist?list=PL68XxS4_ek4afs0eXwRiY...
| NobodyNada wrote:
| That's awesome! I'm definitely thinking about getting an M1
| for realtime keys, though I'm all set up in Logic/MainStage
| so I'll probably stick with macOS for now :)
|
| On the Linux side, would qemu user-mode emulation work for
| that (maybe with a patch to take advantage of the M1's
| switchable-memory-order thing)?
| marcan_42 wrote:
| I think qemu would work fine, but it's pretty slow, so I'm
| hoping it can either be improved or another project more
| focused on this use case can do it better.
|
| If nothing else though, I plan to expose at least the TSO
| feature of the M1 so qemu can reduce the overhead of its
| memory accesses.
| sebmellen wrote:
| Awesome! I'll take a listen and play it during my all-nighter
| tonight. Best of luck getting that M1 Mac working, I'm really
| liking mine so far!
| fbcpck wrote:
| Wow I can't believe I just realized why Bad _Apple_ is used
| for this, 2-3 hours after reading the article...
| sneak wrote:
| Marcan's posts, comments, and now websites are always fun to
| read, and this one is no exception.
| arunc wrote:
| Not to miss his YouTube channel where he does live hacking
| sessions. Invaluable for beginners.
|
| https://www.youtube.com/watch?v=hLQKrEh6w7M
| nayuki wrote:
| I love the two puns in the title: "M1RACLES: Bad Apple!! on a
| bad Apple (M1 vulnerability)"
| fnord77 wrote:
| > So what's the point of this website?
|
| > Poking fun at how ridiculous infosec clickbait vulnerability
| reporting has become lately. Just because it has a flashy website
| or it makes the news doesn't mean you need to care.
| slver wrote:
| > If you already have malware on your computer, that malware can
| communicate with other malware on your computer in an unexpected
| way.
|
| > Chances are it could communicate in plenty of expected ways
| anyway.
|
| This site is basically if Douglas Adams instead had a career in
| security research.
| Sparkyte wrote:
| Real? I'm confused by a particular infosec quote.
| krrrh wrote:
| TL;DR and he really buried the lede
|
| > So what's the real danger?
|
| > If you already have malware on your computer, that malware can
| communicate with other malware on your computer in an unexpected
| way.
|
| > Chances are it could communicate in plenty of expected ways
| anyway.
|
| > That doesn't sound too bad.
|
| > Honestly, I would expect advertising companies to try to abuse
| this kind of thing for cross-app tracking, more than criminals.
| Pretty sure Apple could catch them if they tried, though (for App
| Store apps).
| bombcar wrote:
| > So what's the point of this website?
|
| >Poking fun at how ridiculous infosec clickbait vulnerability
| reporting has become lately. Just because it has a flashy
| website or it makes the news doesn't mean you need to care.
|
| >If you've read all the way to here, congratulations! You're
| one of the rare people who doesn't just retweet based on the
| page title :-)
|
| Heh my initial take at the top was confirmed.
| mhh__ wrote:
| Do Apple actually maintain a list of errata
| sanxiyn wrote:
| I couldn't find one from search and this Linux kernel
| documentation:
| https://www.kernel.org/doc/html/latest/arm64/silicon-
| errata.....
| mhh__ wrote:
| I also had a look a while back but I was hoping they had one
| for Apple devs or whatever.
|
| Some documentation would be nice...
| saagarjha wrote:
| Internally they certainly do.
| xucheng wrote:
| Given M1 is in iPad Pro now, I think there could will be Apps
| seriously exploiting this to circumvent Do No Track in iOS 14.5.
| marcan_42 wrote:
| Thankfully, Apple should be able to statically analyze apps to
| look for this on App Store submission, as the App Store does
| not allow dynamic code (JITs).
| edgyquant wrote:
| How? They'd have to communicate with an app that does have
| those permissions
| xucheng wrote:
| At the core, DO NOT TRACK prevents Apps having access to the
| Advertising Identifier. So different Apps cannot aggregate
| their analytics data about the users.
|
| This vulnerability enables different Apps to communicate a
| super cookie for cross-app tracking. A possible exploit would
| be to implement this feature in an AD SDK to be used by
| different Apps.
| intricatedetail wrote:
| But does it actually do anything? Apps can surely identify
| users by other means, e.g. IP, behaviour...
| denysvitali wrote:
| > I came here from a news site and they didn't tell me any of
| this at all!
|
| >
|
| > Then perhaps you should stop reading that news site, just like
| they stopped reading this site after the first 2 paragraphs.
|
| Marcan is a genius, in every aspect. He is on my top list of
| people I could read all day long without getting annoyed.
|
| Pretty much everything he posts on Twitter is interesting and
| curious. I'm a huge fan!
|
| The other person I have similar feelings for is Geohot.
|
| These guys are really, really smart.
| hans1729 wrote:
| >The other person I have similar feelings for is Geohot. These
| guys are really, really smart.
|
| Its ok George, we love you and you know it
| soedirgo wrote:
| > The other person I have similar feelings for is Geohot.
|
| I don't know about that...
| https://news.ycombinator.com/item?id=25679907
| yannoninator wrote:
| > But it is no surprise that George Hotz, working alone as
| team tomcr00se, would rise to the top of the CTF.
|
| So then this has to be fake then, obviously. Apparently
| George Hotz (geohot/tomcr00se) won a few CTFs _single
| handedly_ [0][1].
|
| I'm sure that marcan is also genius as well, unfortunately
| though Hotz is somehow still able to stay relevant,
| continuously.
|
| [0] https://www.koscom.co.kr/eng/bbs/B0000043/view.do?nttId=1
| 040...
|
| [1] https://www.prnewswire.com/news-releases/nyu-poly-cyber-
| secu...
| comboy wrote:
| You gave denysvitali some serious cognitive dissonance.
| denysvitali wrote:
| Indeed. Lol
|
| The only difference between the twos is that Geohot does a
| lot of thing for the fame (or at least it seems so), and
| marcan does that only for fun.
|
| I'm okay with both tbh, if you are at this level you
| deserve some fame
| throwkeep wrote:
| Yes, he's a great self promoter and a genius level engineer.
| You can watch his livestreams to see both for yourself.
| jonny_eh wrote:
| Hearing an S-Tier hacker call a fellow S-Tier hacker B-Tier
| is certainly entertaining, but from my lowly perspective
| they're still far more capable than 99% of devs I'll ever
| encounter.
| xmprt wrote:
| I also really liked this line
|
| > Wait. Oh no. Some game developer somewhere is going to try to
| use this as a synchronization primitive, aren't they. Please
| don't. The world has enough cursed code already. Don't do it.
| Stop it. Noooooooooooooooo
| ohazi wrote:
| m1racle-mutex:
|
| https://twitter.com/LunaFoxgirlVT/status/1397441284487401478.
| ..
| tardyp wrote:
| Ah! I'm not sure he would really like the comparison with
| geohot.
| tyingq wrote:
| I suppose you could use it to create a "covert suite" of apps for
| the M1 iPad that talk to each other where they aren't supposed
| to. Sharing permission X from app 1 with app 2 that isn't
| supposed to have permission X, etc.
| marcan_42 wrote:
| Thankfully Apple can, in principle, statically analyze for this
| on the iOS App Store, as they do not allow JIT mappings on
| those devices.
| tyingq wrote:
| Do you need JIT though? Does Xcode support inline ASM, or
| various compilers extensions that can read/write a cpu
| register?
| marcan_42 wrote:
| If you put this in your app directly, Apple can just find
| it and reject it at submission time. If JIT were an option,
| that wouldn't be enough, because the app could do it at
| runtime. Since it isn't, there is no way to "hide"
| something like this from the App Store static analyzer.
| tyingq wrote:
| Hrm. It seems like inline ASM allows for passing the
| register name dynamically, though I can't tell for sure.
| If that's the case, it seems like it would be hard to
| tell ahead of time, other than "app calls msr/mrs".
| saagarjha wrote:
| Inline assembly must resolve register names at compile
| time.
| e_proxus wrote:
| Can they guarantee no JIT code via static analysis as well?
| Or could someone sneak in a tiny bit of disguised JIT code
| just to get to this register?
|
| I would assume a huge JITed VM implementation would show up
| easily in analysis.
| [deleted]
| phire wrote:
| They don't provide anyway to mark memory as executable.
| saagarjha wrote:
| Well, they do, because they have to run your code :P You
| just can't make a new page of code and mark it
| executable.
| marcan_42 wrote:
| The OS only makes pages executable if they come from a
| signed app. There is no way for the app itself to do
| that.
| saagarjha wrote:
| If it makes it more clear, my comment was mostly "if your
| code page has a valid signature you can mark it as
| executable".
| thinkloop wrote:
| The attackers already have whatever data you are intending them
| to steal/share. The author says this bug is no big deal:
|
| >Can malware use this vulnerability to take over my computer?
| No.
|
| >Can malware use this vulnerability to steal my private
| information? No.
| tyingq wrote:
| This is a bit different. Skirting app store policy/rules
| thysultan wrote:
| Sounds like a killer feature. They're going to announce this at
| wwdc21.
| mxcrossr wrote:
| No definitely a big, but I expect that they will announce the
| swarm of nanobots they plan to release to fix all the affected
| chips.
| gostsamo wrote:
| > Am I affected?
|
| > * OpenBSD users: Hi Mark!
|
| Yes, "Hi Mark", whoever you are and no matter that I'm not an
| OpenBSD user.
| psy-q wrote:
| I took it as a reference to The Room. Isn't it? :|
| gostsamo wrote:
| I'm not aware of the referenced material. :)
| meowface wrote:
| https://www.youtube.com/watch?v=ZdzmKwKN3n8
| psy-q wrote:
| Oooo! Depending on your taste you're in for either a very
| boring movie or the experience of a lifetime. Complete with
| an associated rabbit hole of mystery surrounding the
| director: https://en.wikipedia.org/wiki/The_Room
|
| If you do end up watching and liking it, there is book and
| a film about the filming of the film to enjoy :D
| https://en.wikipedia.org/wiki/The_Disaster_Artist
| gostsamo wrote:
| Thanks both of you for the info.
| delroth wrote:
| Context: Mark Kettenis has been porting OpenBSD to the M1 SoC,
| and is probably the only current user of that code.
| marcan_42 wrote:
| Precisely :)
| gostsamo wrote:
| That was my initial suspicion as well.
|
| If you are the author _, thanks for the read.
|
| _ Twitter handle matches.
| martini333 wrote:
| That demo made me vomit
___________________________________________________________________
(page generated 2021-05-26 23:02 UTC)