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.
> 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.
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.
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.
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.
> 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
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. ¯\_(ツ)_/¯
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).
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.
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.
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.
> 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
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!
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!
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.
> 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.
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...
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.
> 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.
> 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 :-)
> 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?
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.
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.
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.
> 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.
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.
It seems like there's a partial mitigation available to the OS here. When scheduling a task, write a random value to the two user-writable bits. When the task is unscheduled, if the bits do not match, terminate the task. This effectively makes writing to the register an OS-enforced illegal operation with a 75% chance of being caught within 10 ms if the channel is being used at full bandwidth. (The writer can reduce the chance of it being caught proportional to reduced use of channel bandwidth by resetting it to the OS-chosen value after a bit is transmitted.) The reader can't be detected this way, but since the channel requires cooperation between the writer and reader, catching either is fine. Not a perfect fix, but would help, and would also give visibility into whether this is used in the wild -- e.g., report to Apple via crash reporting mechanism if a process is terminated this way, which would allow prompt discovery of app store apps that abuse the channel.
[+] [-] umanghere|4 years ago|reply
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|4 years ago|reply
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|4 years ago|reply
[+] [-] Angostura|4 years ago|reply
*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.
[+] [-] m3kw9|4 years ago|reply
[+] [-] gostsamo|4 years ago|reply
Edit: fixed name of the chip.
[+] [-] denysvitali|4 years ago|reply
>
> 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.
[+] [-] soedirgo|4 years ago|reply
I don't know about that... https://news.ycombinator.com/item?id=25679907
[+] [-] xmprt|4 years ago|reply
> 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
[+] [-] hans1729|4 years ago|reply
Its ok George, we love you and you know it
[+] [-] tardyp|4 years ago|reply
[+] [-] kbenson|4 years ago|reply
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. ¯\_(ツ)_/¯
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).
[+] [-] notaplumber|4 years ago|reply
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
[+] [-] culturestate|4 years ago|reply
[+] [-] bombcar|4 years ago|reply
[+] [-] meowface|4 years ago|reply
[+] [-] vignesh_warar|4 years ago|reply
>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
[+] [-] tectonic|4 years ago|reply
[+] [-] galgalesh|4 years ago|reply
Am I missing something or is it somewhat likely this will be "abused" by games?
[+] [-] eyelidlessness|4 years ago|reply
I was not expecting such an entertaining FAQ. Good job, very informative, very amusing!
[+] [-] madis|4 years ago|reply
[+] [-] Rantenki|4 years ago|reply
Also, I am still not sure if this is a disclosure, performance art, or extremely dry comedy, but it certainly covered all the bases.
[+] [-] __d|4 years ago|reply
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|4 years ago|reply
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.
[+] [-] tonyedgecombe|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] planb|4 years ago|reply
[+] [-] tyingq|4 years ago|reply
[+] [-] marcan_42|4 years ago|reply
[+] [-] thinkloop|4 years ago|reply
>Can malware use this vulnerability to take over my computer? No.
>Can malware use this vulnerability to steal my private information? No.
[+] [-] fnord77|4 years ago|reply
> 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.
[+] [-] Iv|4 years ago|reply
> 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 :-)
[+] [-] fulafel|4 years ago|reply
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?
[+] [-] alberth|4 years ago|reply
Are the chip registers not protected? What's the mechanism that's allowing this data sharing to happen?
[+] [-] josephcsible|4 years ago|reply
[+] [-] peter422|4 years ago|reply
If you don’t have misbehaving programs on your computer that want to secretly communicate than it doesn’t matter.
[+] [-] phnofive|4 years ago|reply
> 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.
[+] [-] peteretep|4 years ago|reply
> 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.
[+] [-] lasagnaphil|4 years ago|reply
[+] [-] breck|4 years ago|reply
[+] [-] 0xakhil|4 years ago|reply
[+] [-] NobodyNada|4 years ago|reply
> 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|4 years ago|reply
[+] [-] volta83|4 years ago|reply
> 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|4 years ago|reply
[+] [-] addaon|4 years ago|reply