LONG READ NtBugTraq/Russ, but decent discussion/review
>ActiveX controls FWIW, an ActiveX control is merely an executable that happens to have registered entry points.
I'm going to extend that, JUST a little bit:
It's a form of library that doesn't have the ability to launch itself, like a DLL (dynamic link library) is, BUT, is registered by GUID (actually a CLSID (class identifier, which makes sense: You design classes to create ActiveX controls))...
Marshalled (launched) this way, you don't run into "dll hell" because it is identified by GUID (globally unique identifier) &/or CLSID (Class Identifier). OLEServer DLL's are much the same also, vs. "old school/classic" DLL's, which are launched by NAME only!
Usually DLL's (std. oldschool type) are started by LoadLibrary Win32 API calls, or by referencing them in various languages (such as VB declare statements, &/or Delphi using extern references under its VAR (pascal) clause).
Non-"LoadLibrary" autoloaded DLL references in various languages (std. DLLs) examples: vs. LoadLibrary
Delphi E.G.-> function DxFileClean (OldSpec
Char):Integer; stdcall; external 'Stamin32.DLL';
VB E.G.-> Private Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
* The NICE part about using LoadLibrary though, is you can DYNAMICALLY unload libs/dlls you call... not having them loaded in the same process, for its entire duration...
Whereas loading them @ program instancing would force you to use the reg hack "AlwaysUnloadDLL" in the registry, forcing the OS memory mgr. to do it for you once the program 'dies'!
(... of course, this slows loadtime for other progs referencing that DLL (if they already don't have OPEN ref counters to said lib already in place, forcing it to stay open/loaded anyhow)).
Additionally, IE7 also allows you to control ANY ActiveX installed & used by IE, from w/ in its TOOLS menu, Manage Addons Submenu... some "FYI", @ least in Windows Server 2003's version of it., some "FYI" there on that account.
I can, therefore, hand off anything I want to IE's ActiveX processing, from CALC.exe to a multi-process installer routine.
Typically, when you extend IE's TOOLs menu for example? You do it via a GUID/CLSID, as noted here & where I ran into a "false positive" (which I mentioned earlier while using SpyBot, it ID'd an app I wrote for myself as a malware of some sort, by the CLSID I used (totally random on my part) & I have to write SpyBot folks about this - I changed the registry .reg merge file I use for installing it to another CLSID for now) extending said menu in IE6/IE7, thus, in the registry:
--------------------------------------
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Extensions]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Extensions\{10954C80-4F0F-11d3-B17C-00C0DFE39736}]
"APK IE Plugin 1 -> C:\\WINDOWS\\APKPING32.exe"="APK IE Plugin 1 -> C:\\WINDOWS\\APKPING32.exe"
"MenuText"="APK IE PlugIn 1 -> C:\\WINDOWS\\APKPING32.exe"
"MenuStatusBar"="Run Script"
"ClSid"="{1FBA04EE-3024-11d2-8F1F-0000F87ABD16}"
"Default Visible"="Yes"
"Exec"="C:\\WINDOWS\\APKPING32.exe"
"HotIcon"="C:\\WINDOWSWSOCKET.ICO"
"Icon"="C:\\WINDOWSWSOCKET.ICO"
--------------------------------------
NOW, IF you launch a document via 'association' (part of the Microsoft 'document-centric' paradigm)? Then, you might have a point...
Again though:
IE7 also allows you to control ANY ActiveX installed & used by IE, from w/ in its TOOLS menu, Manage Addons Submenu... Me? I burn ANY ActiveX control usage on the PUBLIC internet (not for INTRANET work though)... why??
Take a read here:
Acer May Be Bugging Computers
http://yro.slashdot.org/yro/07/01/08/0515200.shtml
A control, marked safe for scripting no less, has RUN commands in it... bad business by ACER computers imo, since 1998 no less!
(Some "FYI", @ least in Windows Server 2003's version of it., some "FYI" there on that account).
NOTE: I am NOT aware of your example in Calc.exe having associations w/ any known file or datatype (some FYI for you), but, I get your point here.
That allows it to be hosted in another application. No version of IE has ever verified that an object being called *as an ActiveX control* is *actually an ActiveX control*.
The OS does, per my explanation above!
CLSID (class identifiers) essentially do, for OLEServer DLL's & ActiveX controls... differentiating them from 'oldschool' DLL's @ least + "id'ing" them as such, because they are marshalled!
However, for .exe types, you have a point (note the IE tools menu addon technique I used, it will launch them that way via CLSID too - you have a point, but this is why doubtless WHY Ms provided the control for addons (even .exe type) in its TOOLS menu I mentioned above, now in IE7).
I had to help a guy remove an IE tools menu addon recently (his IE would not launch due to SOME addon not working anymore), & that CLSID path I note above for IE addons was the way we went about it in fact.
So if I hand off in this way from within IE to a process not limited by the Protected Mode features, it can then install itself whatever way it wants...
Do you mean by say, launching a WORD doc from off the web? By File Association?? I wouldn't recommend it... not w/ WORD docs! They have 'macroing' possible...
including spawning processes during that installation that launches malware.
Right & what I was leading into above... That is what I was stating to in the preceeding paragraph, when I assumed you meant loading a document into its associated datatype application:
IMO, IT'S NOT A GOOD IDEA TO TYPICALLY PRACTICE THOUGH (@ least not w/ sites you might not know well or trust)!
Just not good 'safe' surfing habit... this is part of WHY I make Outlook/Outlook Express LIMIT what I can open as an attachment. I think Wile E earlier/above on this page alludes to this as well... just "surfing smart" can help you, a TON.
While PM can control what malware can do within IE, it doesn't control what it can do on the machine or outside IE, beyond limiting its effects to the single user.
It seems to say that in the bolded description I posted about it though from the URL you noted... again:
http://blogs.msdn.com/ie/archive/2006/02/09/528963.aspx
User Interface Privilege Isolation (UIPI) blocks lower-integrity from accessing higher-integrity processes. For example, a lower-integrity process cannot send window messages or hook or attach to higher priority processes This helps protect against "shatter attacks." A shatter attack is when one process tries to elevate privileges by injecting code into another process using windows messages.
Also, ANY application YOU run? Runs in YOUR USER ID CONTEXT...
So, by stopping/stalling changes in apps run under YOUR User Context (as it seems to say above per that URL you provided) seems to be enough to stop this!
Also, imo & regardless of using Windows NT/2000/XP/Server 2003 messaging methods/IPC (inter-process control) methods (mailslots, RPC, Shared Memory (RAM &/or diskbound files), Winsock, NetBIOS, DDE, clipboard access, named pipes, etc. et al) OR, VISTA's new "Windows Messaging Foundation" even, especially... it sounds faily solid!
So PM stops things like Gator and some other BHO (Browser Helper Object) malware/spyware, but not MyTOB or its ilk.
BHO's are like the registry .reg file export I pasted in above, & I agree, this really IS IE controlleable... manually, via its menus noted above, OR via "VISTA PM"... which I have yet to try, but it does sound good... @ least, vs. how IE of ANY KIND runs on other OS'...
It also doesn't stop the IE configuration from being altered from outside of IE.
http://blogs.msdn.com/ie/archive/2006/02/09/528963.aspx
"Mandatory Integrity Control (MIC), a model in which data can be configured to prevent lower-integrity applications from accessing it. The primary integrity levels are Low, Medium, High, and System. Processes are assigned an integrity level in their access token. Securable objects such as files and registry keys have a new mandatory access control entry (ACE) in the System Access Control List (ACL)."
That SEEMS to state otherwise... especially regarding registry areas.
The LOCAL commandline switch/file creation (IEXPLORE.exe.local) for IE & some batchfile work can also isolate this as well...
1.) Unzipping/extracting the distro file's files to an IE7 folder
2.) Deleting the UPDATE subfolder that formed under it
3.) Deleting the shlwapi.dll in that IE7 folder you made & extracted the IE7 distro files to (optional - it runs WITH IT IN PLACE!)
4.) + lastly creating a BLANK FILE called IEXPLORE.exe.local with notepad.exe & putting it into the IE7 folder you made & extracted all the files from the Ie7 distro into.
E.G. (which automates it for you to run side by side installs of IE6 & IE7)->
=========================
@ECHO OFF
TITLE IE7 Launcher
ECHO IE7 STANDALONE LAUNCHER
ECHO.
ECHO Do not close this window or it will not clean up after itself properly.
ECHO You can pass a URL into this batch file, like this:
ECHO ie7.bat
www.microsoft.com
ECHO.
ECHO When you close IE7, this will remove the registry key and shut itself down.
ECHO.
ECHO Setting up IE7 for standalone mode...
REN SHLWAPI.DLL SHLWAPI.DLL.BAK
TYPE NUL > IEXPLORE.exe.local
ECHO Running IE7...
iexplore.exe "%1"
ECHO Removing IE7 registry key.
> %TEMP%.\IE7Fix.reg ECHO REGEDIT4
>>%TEMP%.\IE7Fix.reg ECHO.
>>%TEMP%.\IE7Fix.reg ECHO [-HKEY_CLASSES_ROOT\CLSID\{C90250F3-4D7D-4991-9B69-A5C5BC1C2AE6}]
>>%TEMP%.\IE7Fix.reg ECHO.
:: Merge the REG file to delete the IE7 standalone entry
REGEDIT /S %TEMP%.\IE7Fix.reg
:: Delete the temporary REG file
DEL %TEMP%.\IE7Fix.reg
ECHO Removing IE7 standalone files...
REN SHLWAPI.DLL.BAK SHLWAPI.DLL
DEL IEXPLORE.exe.local
ECHO Complete, closing...
=========================
& here is the "IE7Fix.reg" file content (to eliminate changes/additions to the registry) made by IE7 in isolated local mode:
--------------------------------
Windows Registry Editor Version 5.00
[-HKEY_CLASSES_ROOT\CLSID\{C90250F3-4D7D-4991-9B69-A5C5BC1C2AE6}]
--------------------------------
Burning anything it added in the registry, by removing the entire path/value key.
Heck, here is what they thought about it @ SLASHDOT:
http://slashdot.org/comments.pl?sid=175857&cid=14615222
"Modded up" 3 points, as "interesting"... it is, & it works, & NOT just for IE7 afaik, but also other older models of IE!
It allows "side-by-side" loads of diff. versions of IE (I used it to try IE7, while keeping IE6 as my loaded/default windows webbrowser in fact), & protects them both & @ the registry level no less.
Again, I'm not bashing, just trying to point out the difference between PM and a true sandbox.
I tend to disagree w/ SOME of what you wrote, & some I agree with... per the descriptions noted from the URL you gave us to look at.
Still, it's one HECK of a lot better than even Opera (fastest, most std.'s compliant, & most secure browser there is w/ least known bugs afaik) & FireFox in this capacity @ this point, especially on VISTA.
Again, FWIW, I am working on my complete Vista Security White Paper and hope to have it ready soon for our customers. For those of you interested, I'd be happy to copy you on the drafts as they're produced for your feedback. Just email me privately (at whatever email address makes you comfortable, @rc.on.ca or @cybertrust.com.) I expect it to show that upgrading to Vista for security is a waste of resources, and that nothing of alleged security value in Vista can't already be done in XP as effectively and for less cost.
Cheers,
Russ
That would be COOL to see & have, so I hope this point about VISTA having a BETTER SECURITY SETUP, via its "Protected Mode" on VISTA, helps make that paper of yours better... along w/ our discussions of ActiveX & such too!
ALL IN ALL, great discussion/review, as my title of this post states!
I love this stuff, & this is great review, especially w/ someone of your stature-position in THIS field for me, & doubtless others here reading (lol, IF they have the stamina for our rather "HUGE & VERBOSE" posts in this exchange!)...
APK
P.S.=>
This is interesting also, an undocumented switch for IE (eval), & sounds good here also in regard to protecting IE from itself & other installed versions of IE:
http://blogs.msdn.com/ie/archive/2005/12/16/504864.aspx
iexplore.exe (the Internet Explorer front-end) has an undocumented switch, -eval, which will put it into "evaluation mode", where it will preload the following DLLs before yielding to the actual Internet Explorer main loop (in shdocvw.dll):
comctl32.dll
browseui.dll
shdocvw.dll
wininet.dll
urlmon.dll
mlang.dll
mshtml.dll
jscript.dll
If you put these in the iexplore.exe directory, they will be loaded instead of those in the system directory, and the older version of Internet Explorer implemented by that set of DLLs will load (which makes Total Sense - Win32 Portable Executables (PE's) always look in their OWN directory/folder FIRST, for libs they call to load, these are privatized... otherwise, they hit publicly accessible system %PATH% ones (there is far more rules to it, but this covers the generalities).
Or so it used to work in Windows 98. I believe in Windows 2000 and later you'd have to use an iexplore.exe.local hack (LoadLibrary() has been somewhat hardened since then), and in Windows XP and later you could use application manifests
All the versions "installed" this way will share their settings, history and cache (the latter two being especially problematic, since their on-disk format may have changed), but I believe you can use the Application Compatibility Administrator to apply the virtual registry shim and redirect the relevant keys
Your mileage may vary. On the internet you can find detailed guides on how to do it, or even pre-made applications that will do everything for you. This is obviously unsupported, not to mention unused (hence untested) since Internet Explorer 4.0, and may have quirks or not work outright
Finally, all applications using Internet Explorer components will use the system-wide version - unless the relevant DLLs aren't redirected in a way similar to how iexplore.exe does
apk