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