Security Vulnerability in Mac OS X – LoginWindow.app
A security vulnerability in loginwindow.app on Mac OS X was reported to bugtraq this week. The vulnerability is that the user password is still resident in memory after the system authenticates the user.
The bugtraq report states that a cold boot attack could be used to extract this information from memory, and that any attack likely requires physical access to the machine in order to get the password. The description also suggests that a malicious user sitting down at the machine would have to do more than simply read the memory in use by the loginwindow process, because only the root user can view that memory. (I confirmed this by attaching to the process using gdb with sudo).
The severity of the issue is open for debate because of the necessity of physical access to the machine or knowing the password of a user who can use sudo (both of which indicate that the malicious user probably doesn’t need to dig through memory to find the logged-in user’s password); however, this vulnerability really brings to light how important it is to have security-focused coding standards in place on the development side. A simple oversight could turn into the user’s password being stored (possibly multiple times) in memory for the duration of the lifetime of the loginwindow process.
Comment by Justin McOmie
March 2, 2008 @ 8:50 pm
I don’t think even an Administrator on the system should be able to view plain text passwords with ease. And while this issue is probably of little practical concern for most people, I think it underscores the fact that Apple (as well as NeXT, it might appear) has been able to play loose and fast with security for quite some time.
A few other interesting things about Apple and passwords/authentication:
On Jaguar, any user can read the hashed passwords for all users on the system by typing “nidump passwd .” at the Terminal. This oversight was never corrected by Apple in Jaguar (though was fixed in Panther and up).
Today on Leopard (as well as Tiger, but I’m not sure how far back it goes) any “Administrator” on the system can resume anyone else’s locked session. I’m not sure if this is a feature or a bug but it certainly seems like less than ideal behavior for the majority of cases I can think of. You can test it by creating an “Administrator” account, locking your machine, and then using the Administrator’s credentials (username and pass) to unlock the session.
Comment by imv
March 3, 2008 @ 8:04 pm
“The severity of the issue is open for debate because of the necessity of physical access to the machine or knowing the password of a user who can use sudo (both of which indicate that the malicious user probably doesn’t need to dig through memory to find the logged-in user’s password)”
I disagree with this statement because most users use a single password for multiple systems. An administrator on System A had better not be able to easily get passwords for less-privileged users, because on System B, the user-roles might be reversed, or the password might be applicable to online-banking, etc.