14

I always wondered how my Mac could connect to the internet when the recovery partition is booted and my main system partition is locked (filevault2).

Some googling revealed today (e.g. here, here, and also on askdifferent) that the WiFi password is apparently stored in NVRAM and that needs to be reset to remove the password. As a security conscious person this is unacceptable to me. When using Full Disk Encryption (i. e. Filevault2) I expect the system to be safe, also against my network.

So is there a way to prevent OS X from making the password available in the recovery partition? I am not sure how or when it gets into NVRAM in the first place.

UPDATE1: The NVRAM contains the following keys: (nvram -p) :

BootCampHD
SystemAudioVolume
SystemAudioVolumeDB
aht-results
backlight-level
bluetoothActiveControllerInfo
bluetoothInternalControllerInfo
boot-gamma
efi-apple-recovery
efi-boot-device
efi-boot-device-data
fmm-computer-name
good-samaritan-message
gpu-policy
prev-lang:kbd

The keys efi-apple-recovery and efi-boot-device look like they could contain encrypted data.

| improve this question | |
  • Going by one of your recent posts you have a MacBook Pro (mid2012) right? If yes, this is an Intel Base Mac and does not have PRAM as that was with PowerPC based Mac's. Intel based Mac's have NVRAM. Please provide a link to the article you mentioned. – user3439894 Jul 13 '15 at 20:57
  • @user3439894 thanks for the history lesson :) Updated the question. I guess this issue is independent of the Mac and OS X (noticed it first in 10.7). – n1000 Jul 13 '15 at 21:18
  • 1
    You asked "So is there a way to prevent OS X from storing the password on the recovery partition?" and from the links you provided it appears the password is being stored in NVRAM not the Recovery HD partition, two different things. If in a Terminal you use nvram -p can you tell from the output which firmware variable is holding the Wi-Fi password? If yes you can clear just that one variable without reseting the entire NVRAM. Use sudo nvram -d variable_name in a Terminal. – user3439894 Jul 13 '15 at 22:04
  • @user3439894 Interesting. I updated the question. – n1000 Jul 14 '15 at 6:25
17

I've always wondered the same thing: how to keep OS X from storing the WPA passphrase (or PSK) in NVRAM.

Using 'nvram' I could never find the variable that I thought held these credentials. Today, I tried booting to a USB live image of Linux and running Chipsec. Its command to list EFI variables has many more results than I was getting by running nvram within OS X. Among the variables in my MacBook Pro (mid-2010) were:

  • current-network
  • preferred-networks
  • security-password

The current-network variable's data includes the SSID of my home router, in plaintext. Then it is padded with 0-bytes up until the end, which is 32 bytes, and represents the 64 hex digits of the Pre-Shared Key (PSK).

The preferred-networks variable looks like the same contents as current-network.

The security-password variable holds exactly the same number of bytes as the EFI password I set, so I assume this is the Firmware Lock password. I suspect it uses some kind of masking/encoding. One theory I had is that these passwords are stored as keyboard scan codes or something, but I don't have enough info yet.

Perhaps using Chipsec or another EFI tool, you can zero out these EFI variables and set an access control / permissions flag on them so that they cannot be rewritten. Perhaps even just zeroing them out will be a workaround for you (if you just need to resell the laptop or something). It's unknown to me whether OS X rewrites them regularly or just when you change your WPA credentials.

EDIT: I just learned of a command for retrieving wifi passwords from NVRAM: /usr/libexec/airportd readNVRAM

Also, by attaching the GUID, nvram can actually read these values:

  • nvram 36C28AB5-6566-4C50-9EBD-CBB920F83843:current-network
  • nvram 36C28AB5-6566-4C50-9EBD-CBB920F83843:preferred-networks
  • nvram 36C28AB5-6566-4C50-9EBD-CBB920F83843:preferred-count

So, maybe you can blow those variables away and see how it goes.

EDIT 2: as mentioned by an earlier comment, the method to delete an EFI variable is as follows (sudo required to delete): sudo nvram -d 36C28AB5-6566-4C50-9EBD-CBB920F83843:current-network

It's unclear as of yet whether the variable will return.

| improve this answer | |
  • Interesting insights. Please keep us updated if you learn more! IMHO a complete answer to this question would ideally provide some instruction to delete the password... When I do /usr/libexec/airportd readNVRAM there is the current network listed but the Recovery Networks list is empty. – n1000 Jul 15 '15 at 5:54
  • Thanks. I added an edit with a note on how to delete the variable, but I don't know how to prevent it from returning. – Mike Myers Jul 15 '15 at 17:09
  • Don't you have to be running as root to access nvram? It looks like they encrypt the password. Shouldn't it be enough from security perspective? – videoguy Oct 12 '15 at 20:11
  • You do not need to be running as root to read nvram, but you do need it to delete. – Mike Myers Oct 16 '15 at 0:36
  • 1
    As for whether they encrypt the password: the wireless network credentials are not stored as the password/passphrase, but actually the PSK, which is in binary. It may look encrypted when it is displayed, but it is not. It's an encoded hex string. It's easier to read with the airportd command than when you run the nvram command. I just tested with OS X 10.11, and the nvram command method still works. As for airportd, it seems to ignore the "readNVRAM" command now whether you are root or not. I'm not sure what they changed. Its man page still says the command exists, but it no longer works? – Mike Myers Oct 16 '15 at 0:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .