Mac OS X Lion Login Passwords Extracted With Ease | Hacker News Reader

Mac OS X Lion Login Passwords Extracted With Ease

securityweek.com

57 pointsprivacyguru27 comments

I think the headline should be, "FireWire is insecure and can be used to dump the contents of your RAM." But that's always been true, regardless of OS.

Edit: the WinLockPwn tool has been available since 2008, you can just plug one computer into another and dump the RAM. You can then use "signatures" to search for passwords for various systems, including Windows. http://web.archive.org/web/20090402130220/http://storm.net.n...

I like this part:

I'm also pleased to note... the guy who did it by plugging a Cardbus Firewire card into a laptop that didn't have firewire, waiting for it to auto install it (while at the locked screen!) then winlockpwning it. That's awesome. :)

So, even if your laptop doesn't currently have firewire, you're still not safe.

A Debian Developer has a good set of articles[1] on this vulnerability. It's really a pretty astonishing aspect of FireWire.

Time to whip out the epoxy, I reckon.

[1]: http://www.hermann-uwe.de/blog/physical-memory-attacks-via-f...

> It's really a pretty astonishing aspect of FireWire.

Not really. Note that LightPeak/Thunderbolt has the exact same issue. I believe it can be mitigated by the right IOMMU implementation (if the OS takes advantage of the feature).

I think this is a much better article to read, because it covers a variety of platforms, instead of grabbing headlines by talking about Lion, and it contains links to a variety of preexisting papers and tools, instead of regurgitating the contents of a press release

Here is another interesting method dubbed KonBoot.

Kon-Boot is an prototype piece of software which allows to change contents of a linux kernel (and now Windows kernel also!!!) on the fly (while booting). In the current compilation state it allows to log into a linux system as 'root' user without typing the correct password or to elevate privileges from current user to root. For Windows systems it allows to enter any password protected profile without any knowledge of the password. It was acctually started as silly project of mine, which was born from my never-ending memory problems :) Secondly it was mainly created for Ubuntu, later i have made few add-ons to cover some other linux distributions. Finally, please consider this is my first linux project so far :) Entire Kon-Boot was written in pure x86 assembly, using old grandpa-geezer TASM 4.0.

http://www.piotrbania.com/all/kon-boot/

I'm no security expert but it was always my understanding is that once an attacker has physical access to a computer it can no longer be considered secure, no matter what. Also, my understanding is that this is a widely accepted fact in the security community. How can a website called "Security Week" ignore this very relevant piece of knowledge then?

With proper precautions, systems can be secured properly and with quite good security. Anytime a computer doesn't have encrypted data it's insecure, assuming an attacked has physical access. Installing a new operating system while keeping old data is cake. If a laptop is stolen or attempted to access data that is encrypted with proper security measures, it's pretty tough to break. Nothing is ever 100% secure but with proper security measures and encryption (either full disk or of sensitive data) it's pretty tough.

Nah, if the computer is left on I could use a cold boot attack to dump the memory and find the encryption key in there somewhere. If you really want to secure devices against physical intrusion you'll need to do a bunch of TPM, anti-intrusion, and smartcard work.

If this is reported correctly, it sounds like passwords are stored in memory for quite a while in their unhashed, clear text form. This is not good for people that depend on FileVault as a way to assume that physical access doesn't necessarily compromise their data.

It's a little hard to believe this as there's really no need to have the password kept in memory; it could be the exploit requires the device to be plugged in while you're typing your password--which is more believable and also less interesting.

If you have the autologin feature enabled, which would you prefer: keep the password in RAM, where most people can't get it, or put it on the hard drive, which is a much easier target?

But why would the autologin implementation need access to the cleartext password ? And then why is the cleartext password stored at all ?

These seems like big holes.

On OSX, probably to unlock keychain.

Yep: http://www.brock-family.org/gavin/perl/kcpassword.html

Mac OS X 10.6 and 10.7 do store clear-text passwords in memory, long after login.

It uses them, too. For convenience's sake (because everything else is locked under other passwords) I use the same usernames/passwords for my local machines, and without prompting me my new Mini was able to access SMB shares on other machines. I'm not terribly worried about it because this password is unique to local logins on my own network, but it was a little unnerving.

If you have full disc encryption enabled, you'll need to keep the encryption key in memory somewhere (encrypted or not). Basically, if an attacker gets hold of your running computer and you don't have serious hardware security then you're screwed.

That's one of those useless truisms, since preventing casual access to a physical attacker is definitely still important.

Do you really think there are security experts who don't bother with screensaver passwords or whole disk encryption?

Is there any way to get around this? If so, is it implemented in any OS?

I'm no encryption expert, but it seems like you would need to store decryption keys (or in this case, the login password) in plaintext so they could be used by the OS.

An explanation from an expert would be appreciated.

Given that FireWire gives you direct, unsecured access to memory, the most secure solution would be to fill your FireWire port (as well as any other interface that has direct memory access, such as ExpressCard or Thunderbolt) with glue or otherwise render it unusable.

> Given that FireWire gives you direct, unsecured access to memory

FireWire asks for it, but in recent years CPUs have started implementing IOMMUs, which should be useable to "lie" to devices and sandbox DMA'd memory, preventing full memory access to even low level busses (such as FireWire or Thunderbolt)

On linux you can remove the firewire driver temporarily with 'rmmod firewire_ohci' or permanently by adding 'blacklist firewire_ohci' to /etc/modprobe.d/blacklist.conf.

Turning on the firmware password (Either EFI or Open Firmware on PPC machines) disables firewire DMA.

This is a well known and common lockdown procedure for security focused Mac admins, especially as it also prevents booting off of alternate media.

"Passware says the security risk is easy to overcome by simply turning off the computer instead of putting it to sleep, and disabling the "Automatic Login" setting. This way, passwords will not be present in memory and cannot be recovered."

Hm, isn't automatic login now disabled by default in the installation process of Lion? The last install I did seemed to have it disabled by default although there was a toggle to switch it on if I so chose.

The article also mentions that truecrypt passphrases can be recovered this way. Is this true? This would seem like a very major security oversight for software whose main focus is security.

It seems an easier solution is to just log off your account rather than shut the entire computer down. Unless it can be accessed from the login screen...

It's possible to inject code into RAM via this method as well as read it, bypassing said login screen. With FileVault, once you unlock the disk, it remains so until you shut down. Shutting down prevents an attacker from having access to unencrypted data via this attack.

Hands up if you use Automatic Login on your personal computer, whatever OS you might be using. Also, this hack requires physical access to the computer, and by that time no computer, no operating system, can be considered safe.

Reply on news.ycombinator.com