1996-12-17 - RE: Securing ActiveX.

Header Data

From: John Fricker <jfricker@vertexgroup.com>
To: ichudov@algebra.com
Message Hash: 1fe74963662d1d350b2439d53455541a6014524a5b17ddf27458d95c324237ca
Message ID: <19961217052343287.AAA173@dev.vertexgroup.com>
Reply To: N/A
UTC Datetime: 1996-12-17 05:24:35 UTC
Raw Date: Mon, 16 Dec 1996 21:24:35 -0800 (PST)

Raw message

From: John Fricker <jfricker@vertexgroup.com>
Date: Mon, 16 Dec 1996 21:24:35 -0800 (PST)
To: ichudov@algebra.com
Subject: RE: Securing ActiveX.
Message-ID: <19961217052343287.AAA173@dev.vertexgroup.com>
MIME-Version: 1.0
Content-Type: text/plain


>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.
--------------------------------------------------------------------





Thread