Message-ID: <47C72000.6090907@appelbaum.net>
Date: Thu, 28 Feb 2008 12:56:32 -0800
From: Jacob Appelbaum <jacob@...elbaum.net>
To: bugtraq@...urityfocus.com
Subject: Loginwindow.app and Mac OS X

Moin moin Bugtraq readers,

Bill Paul and I have discovered that LoginWindow.app doesn't clear
credentials after a user is authenticated. We discovered this while
testing our EFI-based memory recovery utilities discussed recently[0].

We've found that depending on the state of capture, the passwords for
currently active accounts are stored in memory in plain text form, at
least once if not more times.

We've observed many copies of the password when the screensaver was
unlocked (but not the keychain per se). We consistently find one copy of
the password when the screen is locked. This memory is active for a
least the duration of a session and possibly longer. I believe that with
fast user switching, things could get interesting but we haven't
explored this avenue. As Declan McCullagh points out[1] - this code is
seriously old and it may have been a pre-Apple issue. If anyone has a
NeXT cube sitting around, I'd love to know if this problem goes back
nearly 20 years. Any takers?

Apple originally didn't consider this to be critical because "you have
to be root to read loginwindow.app memory" and they are correct. A
running user cannot even attach to their own loginwindow.app instance.
Give it a try, gdb will throw you to the curb. However, any DMA attack
would be able to extract this password and put it to use. An attacker
doesn't even require a cold boot attack for this but of course that's a
a valid way to get this information as well. Of course this attack
method of attack does require physical access or root (something that
isn't very hard anyway on Mac OS X).

I think this is a realistic issue to address. It could and probably is
being leveraged by forensic analysts as well as other kinds of data thieves.

When I first disclosed to apple, they were seemingly disinterested
because they were unaware of the cold boot attacks that we were carrying
out. Now that such attacks are well known to be easy in software,
they've said they will patch the Loginwindow.app issue in the future.
Still I find this curious as the attacks done by Maximillian Dornseif
have been known and in the wild for years[2]. One software update has
gone out the door without a fix, I hope the next set of patches will
contain an update for this issue.

It's worth noting that this "issue" is so plainly wrong that it was
solved in passwd(1) over two decades ago.

A few details on how to find your own password (from the Apple bug tracker):

Problem ID: 5726694
Title: Information disclosure with LoginWindow.app
State:	  Duplicate /3250780
 Originated Date:	05-Feb-2008 05:57 PM

05-Feb-2008 05:57 PM Jacob Appelbaum:
Loginwindow doesn't sanitize the user supplied password after the login
is authenticated. This appears to last for the entirety of the session.

The application loginwindow running as:
"/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow
console"

An example of this in memory as a series of strings looks like the
following:

        /Users/aluserdsAttrTypeStandard:Password
        ********dsAttrTypeStandard:Picture
        /Library/User Pictures/Fun/Gingerbread Man.tif
        dsAttrTypeStandard:PrimaryGroupID
        dsAttrTypeStandard:RealName
        First Last
        dsAttrTypeStandard:RecordName
        aluser
        dsAttrTypeStandard:RecordType
        dsRecTypeStandard:Users
        dsAttrTypeStandard:UniqueID
        dsAttrTypeStandard:UserShell
        /bin/bash
        home
        /Users/aluser
        homeDirType
        longname
        First Last
        password
        blah
        shell
        /bin/bash
        shouldunmount
        username
        aluser

The username for the user in question is 'aluser' and the password is
'blah' for the session in question. This should probably be erased after
the authentication is finished.

In many cases, the password occurs near the string "shouldunmount," so
searching for this string is a reasonably reliable heuristic for
locating an unknown password in the memory dump. (The meaning of this
string is not entirely clear, though perhaps it should say
"shouldnotleavepasswordslyingaroundincleartext" instead.)

Apple replied to me saying:

"Thank you for forwarding this issue to us. We take any report of a
potential security issue very seriously."

And subsequently said:

"Hello Jacob,

Here is a status update on the issue you filed: <rdar://problem/5726694>
Information disclosure with LoginWindow.app

We have been able to reproduce the issue you reported.  We are currently
tracking the fix for inclusion in an upcoming software update.

Thanks,
Aaron"

If you look at the bug numbers you'll note that this is marked as a
dupe. Our bug is #5726694 and the original report of it is #3250780.
When I first reported this bug, I thought that it would be worth waiting
as a courtesy to Apple and their customers. However, when I noticed that
they closed our bug with a dupe of a bug that is 2,475,914 bugs
prior(!), I felt they had enough notice. Yes, those bugs numbers are in
  sequential order. Apple security wouldn't tell me if this was reported
internally or externally. I guess if they credit the people involved,
we'll see who's known all along.

As a final word, Apple security has been quite nice to us even if they
may be totally powerless to push fixes out the door. They knew that we
would disclose this and we were not threatened with lawsuits. We were
treated with a professional courtesy above and beyond expectation. I
credit this professionalism to Aaron Sigel of the Apple security team.
He's a nice guy and wickedly sharp.

Regards,
Jacob Appelbaum

[0] http://citp.princeton.edu/memory/
[1] http://www.news.com/8301-10784_3-9881870-7.html
[2] http://md.hudora.de/presentations/

Powered by blists - more mailing lists