RE: Securing ActiveX.
Ray Arachelian (sunder@brainlink.com) said something about Securing ActiveX. on or about 12/16/96 11:08 AM
On Sat, 14 Dec 1996 ichudov@algebra.com wrote:
Ray Arachelian wrote:
Until Microsoft secures ActiveX in it's own sandbox and doesn't allow it to access things it shouldn't, it's not cool.
I do not understand how one can secure ActiveX.
Simple. Check out Windows NT, under NT you can write/run programs as services which log in as an account. When you do this, that service program is limited to the security restrictions of that account.
Not exactly. Win32 API's include the ability for a program to impersonate any known user. Besides ActiveX (OLE really) has nothing to do with services. In order to make ActiveX secure there would need to be a virtual machine with access to a limitted API only. Sound familiar?
If you're using the NTFS file system and give that account access only to one directory, it can't access anything but that directory. (If you're using FAT, this isn't true and the program can read/write/delete anything it wants.) Works quite well.
It can be done under 95 but Microsoft will have to write a Sandbox Virtual Machine (a Virtual x86 session whose API's are filtered to prevent access to certain things like the file system, and disables direct I/O.) Not that easy under '95, but it already exists for NT.
There is no such thing on WinNT.
The problem is how to deal with DLL's. You don't know all features/functions of all DLL's. It may be possible to write a DLL that runs outside the sandbox and can act as a proxy to the file system, so it's iffy unless you limit the DLL's and services that ActiveX apps talk to, and make them all live inside the sandbox.
Why is that a problem? ActiveX components are shipped as discrete objects with a known DLL like interface. DLL's are unloaded when the load counter is zero so they don't hang around in memory after the ActiveX job is done. You also cannot write a "proxy to the file system" in a DLL. That's a special device driver called a filter. Of course there is this Mark Russinovich fellow that is showing how this is not exactly true. It is possible to identify all entry points in a DLL. --j -------------------------------------------------------------------- | John Fricker (jfricker@vertexgroup.com) | -random notes- | My PGP public key is available by sending | me email with subject "send pgp key". | www.Program.com is a good programmer web site. --------------------------------------------------------------------
On Mon, 16 Dec 1996, John Fricker wrote:
Not exactly. Win32 API's include the ability for a program to impersonate any known user. Besides ActiveX (OLE really) has nothing to do with services.
In order to make ActiveX secure there would need to be a virtual machine with access to a limitted API only. Sound familiar?
Which is what I've been saying; except for the impersonation feechur, you can do all of the above with a secure account.
If you're using the NTFS file system and give that account access only to one directory, it can't access anything but that directory. (If you're using FAT, this isn't true and the program can read/write/delete anything it wants.) Works quite well.
It can be done under 95 but Microsoft will have to write a Sandbox Virtual Machine (a Virtual x86 session whose API's are filtered to prevent access to certain things like the file system, and disables direct I/O.) Not that easy under '95, but it already exists for NT.
There is no such thing on WinNT.
That's funny, I could have sworn that services could log in as users. Gee I must have been dreaming all along about the directory replicator which requires you to create a replicator user, and the scheduler service which though it can run as the LocalSystem account is better executed as another user with limited rights. No, I must have been imagining them. And the services control pannel which allows you to set such settings, I've imagined that too. Gee I also must have imagined hearing that it's a bad idea to allow such services such as the scheduler to log in as administrator or LocalSystem account because then folks could run anything they like by using the AT command with the /INTERACTIVE switch. Sure there is no sandbox, however you can easily install the RunAsService program from the ResKit and point it at MIE so it too runs as a limited access account which won't have access to the rest of your hard drives, but granted, if someone does use the Impersonate calls in the control, this isn't going to help much.
Why is that a problem? ActiveX components are shipped as discrete objects with a known DLL like interface. DLL's are unloaded when the load counter is zero so they don't hang around in memory after the ActiveX job is done. You also cannot write a "proxy to the file system" in a DLL. That's a special device driver called a filter. Of course there is this Mark Russinovich fellow that is showing how this is not exactly true. It is possible to identify all entry points in a DLL.
Welp, there you go. =====================================Kaos=Keraunos=Kybernetos============== .+.^.+.| Ray Arachelian | "If you're gonna die, die with your|./|\. ..\|/..|sunder@sundernet.com|boots on; If you're gonna try, just |/\|/\ <--*-->| ------------------ |stick around; Gonna cry? Just move along|\/|\/ ../|\..| "A toast to Odin, |you're gonna die, you're gonna die!" |.\|/. .+.v.+.|God of screwdrivers"| --Iron Maiden "Die With Your Boots on"|..... ======================== http://www.sundernet.com =========================
participants (2)
-
John Fricker
-
Ray Arachelian