Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Vuln-Dev
[Top] [All Lists]

Re: Loginwindow.app and Mac OS X

Subject: Re: Loginwindow.app and Mac OS X
Date: Fri, 29 Feb 2008 11:54:02 +0900
On Thu, Feb 28, 2008 at 06:28:51PM -0800, Jacob Appelbaum wrote:
oc photon wrote:
n Thu, Feb 28, 2008 at 1:56 PM, Jacob Appelbaum <jacob@appelbaum.net> wrote:
Moin moin Bugtraq readers,

 Bill Paul and I have discovered that LoginWindow.app doesn't clear
 credentials after a user is authenticated.
This has already been discovered in 2004. While the author only looks
at swap files, it is obvious that this is the same bug.

http://seclists.org/bugtraq/2004/Jun/0417.html

Thanks for the heads up. It's very possible that this is the same bug
but obviously we found it in a different context. It surely seems like
it may be the original that Apple would not discuss with us.

The bug number it was duped against was over 2 million bugs prior. Does
that sound like Apple knew about this for nearly _4_ years (!) and
didn't do anything about it?

That's seriously pathetic if it's actually that case!

I reported it a little while after mailing bugtraq, was
given bug ID #3728773 which was marked as a duplicate of
#3711425 (both after your duplicate of #3250780).
Keep in mind that the increment of millions probably
includes all kinds of automated bug submissions. 

As an aside to grabbing secrets from sleeping machines,
OS X's "secure virtual memory" will encrypt the hibernate
image (good) but then seems to store the key in a nvram
variable.  So that'd be another avenue of attack I guess.

Matt

<Prev in Thread] Current Thread [Next in Thread>