Message-ID: <BC175C14.1C6E%marukka@mac.com>
Date: Tue, 30 Dec 2003 16:45:08 -0600
From: Matt Burnett <marukka@....com>
To: <bugtraq@...urityfocus.com>, <full-disclosure@...ts.netsys.com>,
   <vulnwatch@...nwatch.org>
Subject: Local Denial Of Service Attack Against Apple MacOS X, MacOS X
 Server, and Darwin.


Advisory Name
Local Denial Of Service Attack Against The SecurityServer Daemon In MacOS X,
MacOS X Server, And Darwin.

Release Date
12-30-03

Effected Platforms
Apple MacOS X, MacOS X Server, and Darwin.

Author
Matt Burnett (marukka@...soleconductor.com)

Vendor Status
No patch has been released as of 12-30-03.

Overview
SecurityServer is a daemon used by the effected platforms to provide
authentication, authorization, password dictionary (Keychain), and other
services. It is possible for any user to cause the SecurityServer daemon to
crash. When this happens it will have a cascading effect crashing other
processes, and leaving the system in an unusable state.

Details
It is possible to cause the SecurityServer daemon to crash by unlocking a
locked keychain and specifying a very long password. When the SecurityServer
daemon crashes, it will have a cascading effect crashing other processes
that rely on it. Since MacOS X, and many GUI and CLI programs rely on the
authentication, authorization, and password dictionary services provided by
SecurityServer, this can cause undefined behavior of those processes.
Typical behavior for programs such as login, sshd, su, and sudo are that
they will say you entered an invalid password. Typical behavior for most
applications that use the authorization services is that they will hang. It
is not possible to manually restart the SecurityServer daemon unless you
already have a existing root shell open before the attack has taken place,
since SecurityServer must be launched as root and it does no have the suid
bit enabled. Even when it is relaunched after an attack has taken place, it
will leave the system in an unusable state. Logins via the GUI (loginwindow)
will not work and authorization services will not work either. The only
realistic way to recover from an attack is to reboot the machine. I have not
fully investigated the extent that this attack could be exploited, or its
effect on a system as a whole since so many programs and applications rely
on the SecurityServer daemon.

Proof Of Concept Code
To  build this code run ³gcc <file name> -framework Security ­o
CrashSecurityServer²

#include <Security/Security.h>
int main(int argc, const char *argv[])
{
    SecKeychainRef defaultKeychain;
    SecKeychainCopyDefault(&defaultKeychain);
    SecKeychainLock(defaultKeychain);
    SecKeychainUnlock(defaultKeychain, 0xFFFFFFFF, "password", true);
    return 0;
}

Vendor Response
Apple Developer Connection told me that Apple does not give release dates
for patches.

Timeline    ??-??-??    Flaw discovered. Most likely in MacOS X Public Beta
                        or 10.0. I do not remember the exact date.
            11-20-03    Vendor is notified of flaw and is supplied with
                        proof of concept code.
            12-29-03    Asked vendor for status update. Apple Product
                        Security referred me to Apple Developer Connection.
                        Apple Developer Connection informed me that Apple
                        does not give release dates for patches.
            12-30-03    Advisory and proof of concept code
                        released.

Recommendation
As of the release of this advisory Apple has not yet released a patch. I am
unable to release a patch because Apple only makes portions of the code
needed to build SecurityServer available to the public. My only
recommendation is for you to allow only people your personally trust onto
your systems if they are effected by this flaw.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Powered by blists - more mailing lists