MacOS Recovery Mode Risk

disk-utilitypartitionrecoverySecurity

(A related question was previously posted in the Asahi Linux forum, I didn't get an answer there; see https://discussion.fedoraproject.org/t/question-and-worries-about-wipe-linux-in-recovery-mode/117284)

I've been experimenting with Asahi Linux on my MacBook and performed multiple reinstallations. To remove leftover volumes (normally read-only), I ran a 'wipe-linux' command in Recovery Mode. While the script seemed to work by deleting the volumes, I'm now concerned about a possible typo during execution.

My question:

If the script I ran was malicious, could it have bypassed the read-only protections and injected malware into my main data partition or the recovery/boot partitions (apple_apfs_isc and apple_apfs_recovery)? These partitions appear writable in Recovery Mode (recovery/boot partitions are usually read only), which worries me.

I am aware that MacOS has a pretty robust virus/malware detection, and virus/malware are uncommon on MacOS anyways. However, it seems that in Recovery Mode there is too much power given and I am afraid something could go south.

Best Answer

Short answer: yes, it's extremely dangerous. Almost all of macOS' normal protections are disabled (or disable-able) in recovery mode.

Recovery mode is intended to allow you to perform basic setup and repairs to your system, like reinstalling macOS, repairing or formatting the disk, and changing security settings. It is NOT intended to be a mode where you'd run any non-Apple software, and it's a really bad idea to run anything you don't completely trust in recovery mode.

In fact, the script you linked prints this message when you run it:

THIS SCRIPT IS DANGEROUS!
DO NOT BLINDLY RUN IT IF SOMEONE JUST SENT YOU HERE.
IT WILL INDISCRIMINATELY WIPE A BUNCH OF PARTITIONS
THAT MAY OR MAY NOT BE THE ONES YOU WANT TO WIPE.

You are much better off reading and understanding this guide:
https://github.com/AsahiLinux/docs/wiki/Partitioning-cheatsheet

That said, while the script is certainly dangerous in that it may delete things you really didn't mean to delete, I don't see any sign that it does anything malicious. It only deletes things, it doesn't install anything or modify anything (except for creating a temporary file of UUIDs that'll vanish when you reboot).

So I don't think you need to worry that it's compromised your system, but it would be a really good idea to have a backup (or better yet, two) of anything you don't want to lose.

Related Solutions

CoreStorage – Volume Not Detected on macOS

Your GUID partition table and the MBR are bogus. Your second partition disk0s2 has the wrong partition type. Instead of FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF the type should be 53746F72-6167-11AA-AA11-00306543ECAC.

To modify the partition table destroy and create a new proper one. Afterwards you have to re-add the partitions in the old boundaries but with proper types.

Preparation:

Restart to Internet Recovery Mode by pressing alt cmd R at startup.

The prerequisites are the latest firmware update installed, either ethernet or WLAN (WPA/WPA2) and a router with DHCP activated.
On a 50 Mbps-line it takes about 4 min (presenting a small animated globe) to boot into a recovery netboot image which usually is loaded from an Apple/Akamai server.

I recommend ethernet because it's more reliable. If you are restricted to WIFI and the boot process fails, just restart your Mac until you succeed booting.

Alternatively you may start from a bootable installer thumb drive (preferably Yosemite or El Capitan) or a thumb drive containing a full system (preferably Yosemite or El Capitan). If you boot to a full system and login as admin you have to prepend sudo to execute some commands like gpt ... or newfs_hfs ...!

Remove the bogus MBR/GPT and re-add the partitions

Open in the menubar Utlities->Terminal
Enter diskutil list and gpt -r show /dev/disk0 to get an overview

Destroy the bogus GUID partition table/MBR and recreate a fresh one:

diskutil umountDisk /dev/disk0
gpt destroy /dev/disk0
diskutil umountDisk /dev/disk0
gpt create -f /dev/disk0

Re-add the partitions but with a different type for the 2nd partition (i=2):

gpt add -b 40 -i 1 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk0
gpt add -b 488966144 -i 3 -s 1267712 -t 426F6F74-0000-11AA-AA11-00306543ECAC /dev/disk0
gpt add -b 409640 -i 2 -s 332728384 -t 53746F72-6167-11AA-AA11-00306543ECAC /dev/disk0

The logical volume should mount automatically if not encrypted. If not you may have to unlock it.
Verify the disk and the volume

Your disk contains some uncommon free space. Please ask a second question how to solve this or check other questions and answers here.

Load kext in recovery mode

I think that is quite simple just make sure you mount your Main drive in disk utility in recovery then make more of your Main drive name then quit Diskutilty and click on Utilties on the upper menu bar and then click terminal and to load your kext simply type kextload -b /Volumes/Maindrivename/Library/Extensions/kextbundle Just make sure you replace the command I provided accordingly.

Best Answer

Related Solutions

CoreStorage – Volume Not Detected on macOS

Load kext in recovery mode

Related Question