While Marcan has written in a very entertaining fashion, there is perhaps one application of this vulnerability that wasn't considered.<p>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.<p>[0]: <a href="https://developer.apple.com/library/archive/documentation/General/Conceptual/ExtensibilityPG/CustomKeyboard.html" rel="nofollow">https://developer.apple.com/library/archive/documentation/Ge...</a>
> I came here from a news site and they didn't tell me any of this at all!<p>><p>> Then perhaps you should stop reading that news site, just like they stopped reading this site after the first 2 paragraphs.<p>Marcan is a genius, in every aspect. He is on my top list of people I could read all day long without getting annoyed.<p>Pretty much everything he posts on Twitter is interesting and curious. I'm a huge fan!<p>The other person I have similar feelings for is Geohot.<p>These guys are really, really smart.
<i>Was this responsibly disclosed?<p>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. ¯\_(ツ)_/¯</i><p>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).
> "OpenBSD users: Hi Mark!"<p>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.<p>There was an early teaser dmesg posted in Feburary showing OpenBSD booting multi-user (on bare metal): <a href="https://marc.info/?l=openbsd-arm&m=161386122115249&w=2" rel="nofollow">https://marc.info/?l=openbsd-arm&m=161386122115249&w=2</a><p>Mark has also been adding support for the M1 to the U-Boot project, which will not only benefit OpenBSD, but also Asahi Linux.<p>Another OpenBSD developer posted these screenshots and videos on Twitter.<p><a href="https://twitter.com/bluerise/status/1359644736483655683" rel="nofollow">https://twitter.com/bluerise/status/1359644736483655683</a><p><a href="https://twitter.com/bluerise/status/1354216838406823936" rel="nofollow">https://twitter.com/bluerise/status/1354216838406823936</a>
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 came here from a news site and they didn't tell me any of this at all!<p>>Then perhaps you should stop reading that news site, just like they stopped reading this site after the first 2 paragraphs.<p>This is my most favorite
> 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.<p>I was <i>not</i> expecting such an entertaining FAQ. Good job, very informative, very amusing!
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.<p>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...<p>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.<p>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.
> So what's the point of this website?<p>> 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.
> So what's the point of this website?<p>> 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.<p>> 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.<p>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?
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.
> in violation of the ARM architecture specification<p>> Apple decided to break the ARM spec by removing a mandatory feature<p>Is there a page documenting all incompatibilities / violations of the ARM architecture specification by the M1?
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.
Heh, its "baked in" heh<p>In all seriousness, I wonder what the actual issue is.<p>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"?
Actually not a bad song [0]. Thanks to whoever made this, I guess :D<p>[0]: <a href="https://www.youtube.com/watch?v=i41KoE0iMYU" rel="nofollow">https://www.youtube.com/watch?v=i41KoE0iMYU</a>
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.
Is the risk that malicious software can be split into multiple, obfuscated components?<p>Without such a silicon vulnerability the malicious process would need all its components within a single process/image?
My favorite part of the entire page:<p>> So what's the point of this website?<p>> 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.<p>> 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 :-)
> If you already have malware on your computer, that malware can communicate with other malware on your computer in an unexpected way.<p>> Chances are it could communicate in plenty of expected ways anyway.<p>This site is basically if Douglas Adams instead had a career in security research.
TL;DR and he really buried the lede<p>> So what's the real danger?<p>> If you already have malware on your computer, that malware can communicate with other malware on your computer in an unexpected way.<p>> Chances are it could communicate in plenty of expected ways anyway.<p>> That doesn't sound too bad.<p>> 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).
> Was this responsibly disclosed?<p>><p>> 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. ¯\_(ツ)_/¯<p>That seems... <i>unwise</i> to admit publicly.
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…
Wait, did he just, as exploit proof of concept, infiltrated some catch music&&video clip ? With life rendering on same CPU ? :><p>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...