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?)
17 comments:
Wow, what a meddleware! I'd kill it off without giving it much thought and I would bash them in public even worse than you did Mike.
I've had the unfortunate pleasure of dealing with this particular piece of crapware too. wxVault is so incredibly crappy, it caused my app to crash quite reliably.
Hence, I had to reverse engineer it. The idots writing it clearly didn't know what they were doing. They left the Visual Studio generated dummy function and class in (fWxVault/CWxVault/nWxVault), which do nothing. Clearly they didn't understand what an emoty function does (hint: nothing). Yet, these same idiots used Microsoft Detoured to patch Windows on the fly. Don't play with blowtorches if you can't manage matches.
For those colleague developers who have to deal with the problem, here's what to do: Microsoft Detour only moves the original code, and patches in JMP instructions. Just do a GetProcAddress on GetFileAttributesW, and see if the code starts with 0xE9 (JMP). If so, your app has been hacked. If the JMP points into the wxVault DLL, you know who did it.
WxVault keeps the old code in a 32 byte structure: 23 code bytes, one length byte after that, a pointer to the original code and one to the new code. Pointers to them are stored at offsets 0x1EF00 to 0x1F200 in the DLL. With that information, it's possible to unhook the wxVault code.
Note: as a side effect, this bypasses the "protection" that wxVault is supposed to offer.
Having read all the technical details of writng of code, there is a nagging question that keeps puzzling me.
If one had no intention of using this software from Wave Systems called ETS nor the TPM that is on this particular notebook from Dell, why would one purchase it in the the first place and save yourself a whole bunch of "problems" that you seem to have had?
I also have noticed that through the trials of this set up that took place in several large enterprises and also was tested by Dell and Wave and demonstrated many times beffore at Trade Shows like the one at RSA for example, this seems to work seemlessly and flawlessly for everyone else.
If you did not want this on your computer, then why did you BUY it? You could have chosen from LOTS of other Dell notebooks that had as good and better hardware and software on them as this one did, yet you had to have had purposely chosen this one particular model knowing full well it had something on there you claim that you did not want to use and only attempt to find fault with.
I do not dispute what you are saying about where code and points things to, but when MSFT was in on this from the beginning, as was Dell, I doubt highly anything was hidden from those large staffs of programmers and IT people.
Just my observations fwiw.
synonymous
Why did I buy this model of laptop? Because Dells have been very good to us at work. The D820 has a decent range of ports - which other Dell laptops don't have. It's a decent size for using as a desktop replacement system; it doesn't have the media nonsense that the Inspiron range has.
The TPM module is not something that was specifically called out as a feature, and I didn't ask for it. I suspect Dell weren't fully aware of how Embassy Trust Suite was implemented.
I didn't intend to use the features of this software; this laptop rarely if ever leaves my house, I don't share it, and I therefore have no reason to encrypt data on it. If I had done I was already aware of how to use Encrypting File System.
There is no possible way on this earth that Microsoft would approve of how this software works. Their attitude is that anything documented on MSDN in the Platform SDK or Device Driver Kit is a genuine extension point and can be relied on; anything else is considered breakable and often will be broken. Compare, for example, the list of programs which break on Windows Vista SP1. Note how many are 'security' software. I'd lay a bet that many of them break because they used undocumented kernel interfaces that were changed. The fact that ETS hasn't yet broken is pure dumb luck.
Frankly, synonymous, you smell of astroturfing.
Having finally got to the bottom of a problem caused by this nasty bit of software I thought I would leave some comments which may or may not help the next person to fall foul of it.
wxvault.dll appears to cause and handle access violation exceptions in the normal course of business (late fix-ups?) which means that you cannot install a catch-all exception handler to show a “xxx has failed, please contact yyy “ message if your app goes wrong unexpectedly. More accurately, if you do install an exception handler you have to return EXCEPTION_CONTINUE_SEARCH if it is not an exception you are expecting…
In debugging this we also found that while older versions were easy to spot, showing up both in a debugger and with the app run under dependency walker, on another newer installation we found that wxvault.dll does not inject itself when the application is run under a debugger or dependency walker – with the result that a crashing app ran perfectly as soon as I tried to debug it. Using the ListDLLs tool from sysinternals was the only way I found to spot wxvault.dll once the application was running. In a similar vein, it was possible to disable the wxvault dll using AutoRuns in the older installation (on the AppInit tab), but the same procedure had no effect on the newer installation – wxvault still injected itself with the AppInit disabled. I’m not enough of a Windows programmer to know what mechanism it was using to initiate itself in the second case.
Happy googling
By the way, you don't need to load a DLL into a process in order to disassemble it with CDB / KD / WinDbg. You can just open it with "windbg -z foo.dll". WinDbg loads it as a pseudo-dump-file. A handful of commands work, such as "u", "x", etc.
Mike, I have had this Dell Computer for 1 year when all of a sudden this 'Embasst Trust Suite' popped up. I resd your post but everything is WAY over my non computer skills. So, in simple english, what is it and do I need it.
Thanks, Bones
Hi Mike,
It's one year later, and I find that while cleaning up after a rootkit, GMER thinks that the ETS is a rootkit. So you were right, itis a user space rootkit as far as I know.
I have had numerious issues with the ETS Wave software since I was handed my Dell 620 laptop by my company... now I think I will finally remove the software.
Just about every module in Thunderbird has been patched with a JMP to wxvault.dll, and I think I have had occasional issues in the past with my Verizon wireless CDMA modem software as a result of this as well.
I should have read your blog a year ago.
Yet another bloatware.
If we were using the security chip, it might be another matter, but then I still don't want the software to hook into dll.s like a rootkit.
--R
We had the problem that a file handle inherited by a child process was found invalid by WriteFile() on one particular Dell machine in our office. After uninstalling ETS the problem disappeared (and Windows XP started much faster).
Any suggestions on how to bypass this thing? All of a sudden this Embassy Logon is being displayed on my computer and it won't let me login. I know my Windows password, but the thing justs sits there.
I removed this stupid Embassy Trust Suite program from my laptop using the add/remove programs thingy, and now it won't let me open firefox...it's telling me it can't find that wxvault.dll file or w/e it's called....meh. I have no idea what to do...
The EMBASSY stuff is now being launched from Dell ControlPoint Security Manager. Wave has a page at http://www.wave.com/support/PBA/ that has some details about what it's supposed to be doing.
(What's up with the spam in the last few comments? What are they trying to accomplish?)
(Hmmm... do I trust this site with my Google name and password? Think I'll pass.)
Interesting tidbit: I have Vista SP2, with G-Data's AntiVirus 2010 loaded. Windows's Security Center kept complaining that G-Data was out-of-date. Telling G-Data to update didn't fix the problem. Figured it was a bug with them, and I'd have to live with the little red X in the icon bar. HOWEVER, I just un-installed Dell's ControlPoint Security module, and Windows is now happy as can be; it's no longer complaining about G-Data. I'm also getting a "Hit Control-Alt-Delete to log on" message when Windows comes up; evidently ControlPoint was "helpfully" doing that for me.
I don't suppose you are likely to see this, but the comments on this post are just bursting with spam at the end there...
Thank You for keeping the faith and enduring the tragedy of the commons spam fest.
I have a dell 755 with ETS and your site gave me something to try removing.
My question is if i remove this "helpful" ETS service won't the damage already have been done to various dlls?
When reinstalling from DELL OEM Windows won't it have another whack at splicing itself into everything?
What would you suggest?
Trousers/IMA is the Linux version at least it doesn't install itself automatically. - What was dell thinking?
Thank You again for Believing in the 'net i certainly hope there is a better solution to spam very soon..
i found your article via gockl ... eh ... google. i know, its a bit late since you posted it, and i'm also not that sure, if i might get an answer to my question but i'll try. as far as i've understood, that embassy trust thing is not something rly important or integral that must be installed. the thing is, as i sit here, trying to set up a dell latitude 620 from a friend, i stumbled over that driver/setup on their list when downloading from their site:
upek touchstrip reader, embassy trust suite, trusted platform module 1-2
which is bundled in one exe and i wonder what of it *is* needed or can i discard all without harming the thing itself. tpm alone made me think as for a correlation with tcpa/palladium. on the other hand, all those things bundled into one are on the same list as separate files, which leaves me now a bit confused.
searching broadcom trusted platform bleh also didn't help that much, coz ... yeh, *wot* is it rly for and wot *is* it doing? just encrypting things like f.e. true crypt? or encrypting itself for storing things that one can't get rid of [as far as i remember wot tcpa was meant for]?
regards,
koschei
I have read your post and discussion too.I think you should check this wxvault dll not found post to know more info about that problem...
Post a Comment