I was recently experimenting with Asahi Linux on my Mac and went through multiple reinstalls testing different desktop environments and window managers. Unfortunately, after a while, I encountered issues preventing further installations.
Following online guidance, After some search I was told to run the “wipe-linux” command in Recovery Mode which I executed something similar to:
curl alx.sh/wipe-linux | sh
(I ran this 2-3 month ago, now you can’t run this). While the script appeared to function correctly by removing extra volumes, I’m now concerned about a potential typo during the process.
Questions:
Are there any documented instances of typosquatting websites mimicking “alx.sh” that could have delivered a malicious script even within the limited access of macOS Recovery Mode?
Assuming I unintentionally ran a malicious script, could it have bypassed the read-only protections and injected malware into my main data partition or the recovery partitions (apple_apfs_isc and apple_apfs_recovery )? They seem to be writable under Recovery Mode.
I understand these partitions are designed to be tamper-proof, but I’m hoping to confirm the extent of potential risk.
Unfortunately, after a while, I encountered issues preventing further installations.
Run curl -L https://alx.sh/cleanbp | sh in RecoveryOS. Apple has a bug where they never clean up old stale boot policies, and SEP starts timing out and crashing when you have too many. It happens after 20 or so installs.
wipe-linux used to do this in RecoveryOS too (when it was available). cleanbp still does it, but does not attempt to wipe any installs, that’s up to the user.
Are there any documented instances of typosquatting websites mimicking “alx.sh” that could have delivered a malicious script even within the limited access of macOS Recovery Mode?
There are no documented instances, but evidently it is possible for people to typosquat.
Assuming I unintentionally ran a malicious script, could it have bypassed the read-only protections and injected malware into my main data partition or the recovery partitions (apple_apfs_isc and apple_apfs_recovery )? They seem to be writable under Recovery Mode.
Malware running on your machine in RecoveryOS could in theory:
Inject malware/tamper with Linux installations (since we don’t have full secureboot yet), and
Inject malware/tamper with macOS installations that do not have FileVault enabled, and
Generally destroy data or make the machine unbootable (up to requiring a DFU restore to recover).
With FileVault enabled and the relevant partition not unlocked, in principle macOS installations are safe from malware tampering like this since you need the FileVault password to do anything. Without FileVault you would have the same level of exposure as malware running on macOS as a root process (it still wouldn’t be able to bypass SIP or run malware in kernel mode, due to secureboot).
Linux can have similar guarantees with SEP-backed FDE and full secureboot, but we’re not there yet.