ATL DLL registration for current user only- IE BHO

Question

·         Hi,

I have been trying to get an IE BHO (ATL DLL - no MFC) to register for the current user on XP, Vista, Windows 7 32/64 bit system reliably and have not got it to happen. For the sake of testing I have been concentrating my efforts on a Windows 7.0 64 bit system and trying to register with IE 8.0 (32 bit & 64 bit) and have failed miserably. My priority requirement is for IE 8.0 (32 bit) on all operating systems.

I have read several forums on the internet and have tried everything and have run into one show stopper or another. From registry errors all the way to registration entries not being made. I have tried the following registration function and moved the IE BHO registration to the current user. Also I periodially get 0x8002801C error during registration - even though as far as I can see all the entries have been made properly as far as I can tell.

I am beginning to think that it is not possible to register a BHO for the current user. Is it possible?

STDAPI DllRegisterServer(void)
{

 // registers object, typelib and all interfaces in typelib for the current user
 HKEY key;
 if(ERROR_SUCCESS != ::RegOpenKeyW(HKEY_CURRENT_USER, L"Software\\Classes", &key))
  return E_FAIL;

 if(ERROR_SUCCESS != ::RegOverridePredefKey(HKEY_CLASSES_ROOT, key))
 {
  ::RegCloseKey(key);
  return E_FAIL;
 }

 HRESULT hr = _AtlModule.RegisterServer(true);
 ::RegCloseKey(key);
 return hr ;
}

Another note that if I manually create all the registry entries it seems as though IE 8.0 will not recognize the BHO. So is there something I am missing? It seems like IE is not recognizing the current user entry (HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects). Although on Windows 7.0 64bit system the 32bit entry is under a "wow" sub registry entry which should not make any difference.

Any thoughts or experiment suggestions would be greatly appreciated.

Thanks,
Tom

 

Answer 1

No, IE does not load BHO from HKCU. otherwise it would be a text book privilege elevation attack when the user runs IE in elevated mode.

---

---

The following is signature, not part of post
Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
Visual C++ MVP

Answer 2

Hi Sheng,

Thanks for your response.

That does not make too much sense to me. We want to set up our network so that nonadmin users can install a harmless BHO if they want the service the BHO provides.

If I have the IE browser out of the loosely-coupled mode and I have user control totally off...why cannot I not load the BHO in the current user.

The reason we want to do this (like many many BHO's) is to avoid doing Active Directory push's of software ( huge corporate network). We want to do a non-admin install. Is there a way to get IE to recognize the BHO?

I did not want to say this...but how come we can do this with other browsers without any issue?

Thanks,

Tom

 

 

Answer 3

Yeah, it's not clear to me either how that would be a security threat, but I haven't finished my coffee yet either.  

I suspect—for whatever reason—IE just doesn't load from the HKCU keys.  You can run Process Monitor and see if it even tries to open the keys.  

If it doesn't, then you're just out of luck and you have to do an admin install.  I'm not completely familiar with how Active Directory works, but couldn't you just have a script that writes the HKLM key and have your user-mode install skip that part?  I mean, it sounds hacky, but it might work.  I dunno, I'm not a sysadmin.

What does your BHO do?  Perhaps there is another way to accomplish the same thing without an admin install.

Lastly...

I did not want to say this...but how come we can do this with other browsers without any issue?

For the same reason you can't make orange juice with apples.

Answer 4

Jeff you got me to laugh on your last comment.

The end customer does not want to get his Network Admin people to right any scripts. I don't think he wants to deal with all the politics they bring to the table.

The BHO adds a link to the bottom of a couple search engine pages. Very simple BHO.

I would just like somebody to point out somewhere where it states "IE does not support non-admin installations". Then I could point that out to the customer.

I really do not understand why that would be a security risk. Most corporate enviroments already have pretty stealth anti-virus protection.

 

 

 

 

Answer 5

If IE were to load BHO from HKCU, then a rogue app running unelevated could register a BHO. And when the user start IE elevated, the BHO would be loaded into an elevated process. Assuming the user trust IE and click "Continue" when Windows ask for UAC consent,  the result in this case could be disastrous.

This is just a speculation though. There must be some other design decisions before Vista. The IE SDK does not list HKCU as an acceptable BHO registration point to begin with. 

 

---

---

The following is signature, not part of post
Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
Visual C++ MVP

Answer 6

IE could load BHO from HKCU in non-elevated mode.

And in elevated mode it could continue to NOT load from HKCU (as it does currently).

This scheme could solve both problems.