3 ms·

Not really. You can view the source code for both Chrome, Chrome OS and Chrome Frame in their repo: http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame

Not really. You can view the source code for both Chrome, Chrome OS and Chrome Frame in their repo: http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/ http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame... As a side note, after having looked at the code for a few minutes, it appears they're doing some clever things with the Chrome Frame helper program: (tidy) DLL injection into Internet Explorer, together with dynamic BHO loading using the windowing API and the IWebBrowser2 interface (see http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/bho_loader.cc?revision=87033&view=markup http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame... ). The "right" way to do this is to register your BHO dll through regsvr32 (I believe this creates a registry entry as well.) If you have Administrative rights, the installer does this for you, and Internet Explorer will do everything on its own from there on. It surprises me that their workaround actually works. One would think that aspects such as DLL injection and API interfacing would be blocked for non-administrative users. The code could actually prove inspirational for malware writers. I still wonder how they load the helper program at startup. Probably using a service, but setting a new service would require Administrative privileges, I believe...

kevingadd 15y ago
Restricting DLL injection and 'API interfacing' (if that's even a thing) to administrative users would provide no security benefit. People would just have to run as admin. DLL injection is used all over in windows to provide useful features like alternate input methods, icon overlays in explorer, etc. You aren't allowed to inject DLLs into processes owned by other users or processes of higher integrity level, so it's not really a significant security threat under the current windows model. IIRC Chrome and IE both run their processes at low integrity so those processes won't even be able to inject DLLs into other processes unless those other processes are also low integrity.
- Macuyiko 15y ago
  Ah, thanks for the clarification. "API interfacing" was formulated a bit quickly (then again, don't you interface with an interface?) -- perhaps I should have said "using API's".
BrianLy 15y ago
I don't think they would install a service to start the helper program. Service and desktop interaction has been changed since Vista. IIRC this was to prevent the shatter attack that allowed Window messages to be passed between services and applications. I haven't looked but I think it could add the helper to the startup items for a user, or create a scheduled task. You don't have to use regsvr32. Registration-free COM (http://msdn.microsoft.com/en-us/library/ms973913.aspx http://msdn.microsoft.com/en-us/library/ms973913.aspx) has been around for a while. I wonder why this was not used, or if there is a limitation with certain types of COM objects.

kevingadd 15y ago

Restricting DLL injection and 'API interfacing' (if that's even a thing) to administrative users would provide no security benefit. People would just have to run as admin. DLL injection is used all over in windows to provide useful features like alternate input methods, icon overlays in explorer, etc. You aren't allowed to inject DLLs into processes owned by other users or processes of higher integrity level, so it's not really a significant security threat under the current windows model. IIRC Chrome and IE both run their processes at low integrity so those processes won't even be able to inject DLLs into other processes unless those other processes are also low integrity.

Macuyiko 15y ago
Ah, thanks for the clarification. "API interfacing" was formulated a bit quickly (then again, don't you interface with an interface?) -- perhaps I should have said "using API's".

BrianLy 15y ago

I don't think they would install a service to start the helper program. Service and desktop interaction has been changed since Vista. IIRC this was to prevent the shatter attack that allowed Window messages to be passed between services and applications. I haven't looked but I think it could add the helper to the startup items for a user, or create a scheduled task. You don't have to use regsvr32. Registration-free COM (http://msdn.microsoft.com/en-us/library/ms973913.aspx http://msdn.microsoft.com/en-us/library/ms973913.aspx) has been around for a while. I wonder why this was not used, or if there is a limitation with certain types of COM objects.