Dear Wave Systems,
Fuck right off.
When I bought my Dell Latitude D820 laptop, I went through and deleted a certain amount of the shovelware that was preinstalled, but some of it, to be honest, I didn’t know what it did. I tried to work out what EMBASSY Trust Suite did, and it seems to be something to do with the Trusted Platform Module in the system. Encrypting files using the TPM key, or something like that.
Charles Petzold wrote an article yesterday commenting on random number generators, and I added a comment earlier on mentioning in passing the reported flaw in CryptGenRandom. I decided to see if this seemed to be the case in XP SP2. My answer was inconclusive, as the assembler was hard to follow. By chance I was debugging Internet Explorer with WinDBG (easiest way to force the RSA Enhanced Cryptographic Provider, rsaenh.dll, to load so I could disassemble it) and noticed an odd number of access violation exceptions occurring when I accidentally did a search in the instance of IE I was debugging. That’s weird, I thought – where am I on the stack?
In wxvault.dll. The stack trace was:
0012c888 100065ee wxvault+0x7967
0012cac4 42f8c769 wxvault+0x65ee
0012cadc 42f8cdc9 IEFRAME!PathFileExistsW+0x24
0012cb14 42f8ccf7 IEFRAME!HelperForReadIconInfoFromPropStore+0x97
0012cb98 42f78e53 IEFRAME!CInternetShortcut::_GetIconLocationWithURLHelper+0x156
Looks like we’re trying to get the favourite icon for the address bar. But how is IEFRAME calling into wxvault? Microsoft can’t know that this library exists. Is there something on the stack that somehow isn’t being included (can happen if a function was compiled with the Frame Pointer omitted and no symbols are available to get FPO data [which tells the debugger how to fix up]). Let’s disassemble around PathFileExistsW:
42f8c75e ff7508 push dword ptr [ebp+8]
42f8c761 8bf8 mov edi,eax
42f8c763 ff152c13ef42 call dword ptr [IEFRAME!_imp__GetFileAttributesW (42ef132c)]
42f8c769 83f8ff cmp eax,0FFFFFFFFh
That’s weird, we called into GetFileAttributesW. How did we end up in wxvault?
0:000> u kernel32!GetFileAttributesW
kernel32!GetFileAttributesW:
7c80b74c e965ae7f93 jmp wxvault+0x65b6 (100065b6)
Evil! They patched the running instance of kernel32! What else have they patched?
kernel32!CreateFileW:
7c810760 e9d0587f93 jmp wxvault+0x6035 (10006035)
Note how they’ve failed to rebase the DLL, using the default 0x10000000 base address, making it collide with everything ever which also uses that default address.
Needless to say this is going to get uninstalled as soon as I take a full backup of the laptop! In my book, this is a user-mode rootkit. I don’t use the feature, so it’s going.
How should they have implemented this? Well, I’d start by seeing if it’s possible to change the algorithm for the Encrypting File System. It should be, it’s implemented using the Cryptographic API and CSPs (involving callbacks into LSASS in usermode!), so I would have thought that simply providing your own CSP would be sufficient.
If that’s not possible, my next port of call would be a file system filter driver. That would have the downside (like this) that every file system call would go through it, rather than the tiny amount of calls which actually target a file encrypted in this way.
The access violation looks like it might ultimately be caused by a bug in IE – it looks like IE tried to pass the URL to the favicon to GetFileAttributesW, which I would hope would fail (or would it try to invoke WebDAV?)
