Security glitch exposes OS X account passwords

Apple has confirmed a security glitch that, in many situations, will let someone with physical access to a Macintosh computer gain access to the password of the active user account.

The vulnerability arises out of a programming error that stores the account password in the computer's memory long after it's needed, meaning it can be retrieved and used to log into the computer and impersonate the user.

"This is a real problem and it needs to be fixed," said Jacob Appelbaum, a San Francisco-area programmer who discovered the vulnerability and reported it to Apple. He said he disagreed with the company's response: "They won't put it in the latest security update or release a security update just for this issue."

Appelbaum is one of the team of researchers who published a "cold boot" paper last week describing unrelated vulnerabilities in encrypted filesystems, including Apple's FileVault, Windows Vista's BitLocker, and a number of open-source ones.

Unlike the security concerns reported last week, this vulnerability is specific to OS X. It's also more sweeping because it offers--at least in OS X's default configuration--full access to passwords stored in the Keychain, which can include passwords to wireless networks, Web sites, accounts accessed via SSH, network-mounted volumes, and so on.

Apple spokesman Anuj Nayar told me: "We're aware of this locally exploitable vulnerability, and we're working to fix it in an upcoming software update. While no operating system can be 100 percent immune, Apple has a great track record of addressing potential vulnerabilities before they can affect users."

The security glitch works like this: The OS X subsystem that asks for a username and password to log into an account is, reasonably enough, called loginwindow.app. In the default configuration, the account password unlocks the user's keychain and the encrypted FileVault volume (if one is in use).

But instead of immediately erasing the password from memory once the unlocking process is complete, OS X keeps it around. That means someone with physical access to the computer can use multiple methods to extract the contents of the computer's DRAM chips.

Last week's paper described some of those techniques. They include: plugging an iPod into a Firewire port to extract the contents of memory, rebooting the computer and running a memory-extractor over the network or from removable media, or physically ripping out the DRAM chips and inserting them into another computer. (Setting a firmware password can guard against the rebooting-attack threat.)

Turning off your computer and waiting a minute or more protects you from this attack by giving the contents of DRAM time to decay.

Although it's possible that the password stays in RAM even after the user logs out--which would be even more dangerous--Appelbaum hasn't tested that theory.

Trust, but verify

I invited Appelbaum over to News.com headquarters in downtown San Francisco and asked him to demonstrate the vulnerability on my laptop. He showed up with Seth Schoen of the Electronic Frontier Foundation and William Paul, who also worked on last week's paper.

I gave them an Intel-based MacBook with a password-protected account called "Breakme." FileVault was turned on, encrypted swap was activated, and the computer was locked through the screen saver. There was a file on the Desktop called "canyoureadthis"--if they could read its contents, I figured, they proved their attack worked.

What they did first, as you can see in the photographs below, was run an Ethernet cable from the MacBook to one of their laptops. Their next step was to convince the MacBook to run an "EFI memory scraper" program (written by Paul) found over the network through Apple's NetBoot service by holding down N while rebooting. That extracted the contents of the MacBook's memory to a 1.25 GB file. Then they scanned through it for likely passphrases.

It took them a few minutes, but they found the passphrase, "impressive"--as in, if they could find it, the attack was impressive. Once they had the password, they could easily log into the account and read the secret file on the desktop, which contained a relevant quotation from Thomas Jefferson. (They're planning to release the EFI memory scraper and other utilities some time in the next few months, so other people will be able to do this, too.)

Appelbaum reported the problem to Apple on February 5, but Apple didn't fix it in the security update released on February 11. "They should be concerned because it means that things that require password authentication do query this information," he said.

Because Apple wouldn't divulge details, it's a little unclear exactly what happened. But because loginwindow.app dates back to NeXTSTEP in the late 1980s, when nobody was even thinking about this kind of attack, it's possible that the origin of some of the code in use is older than some News.com readers who are reading this article today.*

Rebooting the target MacBook in a studio at CNET on Second Street in San Francisco. From left to right: Paul, Schoen, Appelbaum, and yours truly. We had planned on making a video, which is why we were using the fifth-floor studio, but the plan was nixed by a problem with the output from the camera you can see to the right. These are still images taken from the video.

(Credit: CNET)

Paul is skimming through the contents of the extracted memory--dumped from the Macintosh to his laptop--for possible passwords.

(Credit: CNET)

Eureka! There it is. The account name is 'Breakme' and the password I gave it is 'impressive.'

(Credit: CNET)

With the password, it was easy enough to log into the 'Breakme' account and read the secret file on the Desktop. These are the contents of it.

(Credit: CNET)

* Full disclosure: I worked at NeXT Computer during that time. Yes, that probably makes me old.