RE: Securing ActiveX.

This thread branch seems to be based on bad assumption.  Why would
one want to run ActiveX controls in a sandbox?  If you need a sandbox,
use a Java applet, if you need native code level access to the system
use ActiveX.

Running code in a sandbox, a la Java applets, is one approach to allowing 
safe execution of downloaded code.  If one has a perfect implementation of 
the sandbox, which doesn't appear to be the case for Java thus far, this can 
be a useful solution.  There is however a severe limit to the types of 
applications you can run from inside a sandbox unless you subscribe 
completely to the 'Network Computer'-type model.

Digitally signed code, a la ActiveX, is another approach to the same problem.  
If the digital signatures and infrastructure around them are sound, which they 
appear to be for ActiveX, this is also a useful solution.  The built-in gotcha 
with this model is the all or nothing nature, either I trust the software publisher 
to run arbitrary native code on my machine or I don't run it at all.

Specify technical issues follow:

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

But of course it's not enough to filter out filesystem calls.  The entire
windowing system would have to be separated as well.  For example
a rogue control might watching all edit controls for ones
that have the ES_PASSWORD style and grabbing the contents.  

An equivalent Unix problem would be to allow an open-access guest
account with the ability to transfer in and execute arbitrary binaries.
While doing this securely may be possible in theory I don't think the 
state of the art is up to it today.  (I sure wouldn't allow it on my system.)

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

DLL's are by definition mapped into the processes address space, they
would have to be inside the sandbox too.  It's not a call gate type of thing.


regards,
-Blake

Blake Coverett <blake@bcdev.com> wrote:
[...]
>Digitally signed code, a la ActiveX, is another approach to the same
>problem.
>If the digital signatures and infrastructure around them are sound, which
>they
>appear to be for ActiveX, this is also a useful solution.  The built-in
>gotcha
>with this model is the all or nothing nature, either I trust the software
>publisher  to run arbitrary native code on my machine or I don't run it at
>all.

The other problem is that the proposed Authenticode system and other "signed
applet" systems only provide accountability after the fact.  This is little
help when your hard drive is toast and the only proof you had was a logfile
which was the first thing erased...  The illusion that only "trusted software
puslishers" will be given blanket authorization is a pipe dream: users are
sheep who will hit that "OK" dialog box as many times as necessary to get the
tasty treat they are anticipating (and there is actual experimental evidence
to back this up :)  I expect that the first post-Authenticode ActiveX virus
will be one to modify the signature checking routines or add additional keys
to the registry which makes the second round of the attack appear to be a
valid OS update from Microsoft. What exactly does a signature get you other
than someone to point a finger at?  In case you don't read those legal weasel
words in software licenses there is no claim made that the product will work
as intended and the company does warn you that if the product fries your
disk then it is not their fault...

>Specify technical issues follow:
>
>> 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.
>
>But of course it's not enough to filter out filesystem calls.  The entire
>windowing system would have to be separated as well.  For example
>a rogue control might watching all edit controls for ones
>that have the ES_PASSWORD style and grabbing the contents.
>
>An equivalent Unix problem would be to allow an open-access guest
>account with the ability to transfer in and execute arbitrary binaries.
>While doing this securely may be possible in theory I don't think the
>state of the art is up to it today.  (I sure wouldn't allow it on my system.)

The state of the art was up to it quite a while ago.  Check out KeyKOS and
other OSes which use capability semantics for access control.  Rather than
the all or nothing approach to security which is currently built into Java
and continued with the code signing initiatives (albeit allowing you to
delegate responsibility regarding trust) what is needed is to extend the
signatures to granting the capability to perform a certain task and nothing
more.  If the signature could express things like "this ActiveX control
needs access to a writable file in C:\WINDOWS\TEMP which will not exceed
1 Megabyte in size" then the system would be flexible enough to succeed
and would allow users to express much more complex trust relationships than
the simple boolean expressions which current code signing mechanisms allow.

jim

On Mon, 16 Dec 1996, Blake Coverett wrote:

> This thread branch seems to be based on bad assumption.  Why would
> one want to run ActiveX controls in a sandbox?  If you need a sandbox,
> use a Java applet, if you need native code level access to the system
> use ActiveX.

To prevent ActiveX controls from formatting your hard drive while still 
being able to run native code to do fast DES cracking, why else?  
Sandbox!=Virtual CPU emulator.  Sandboxes work at the supervisor/user CPU 
level deciding which calls are cool and which will result in a core dump.

...

> Digitally signed code, a la ActiveX, is another approach to the same problem.  
> If the digital signatures and infrastructure around them are sound, which they 
> appear to be for ActiveX, this is also a useful solution.  The built-in gotcha 
> with this model is the all or nothing nature, either I trust the software publisher 

Viruses can sneak into software.  Given enough time you will see them 
sneak into compilers which will then happily create virus infected or 
trojan loaded controls which will be happily signed.  I'll leave the test 
of that scenario up to your imagination.  There were cases of viruses 
making their way to production distributed disks back a few years ago 
because people weren't watching carefully enough.

Or you may find that shareware control authors won't bother to sign their
controls, etc...  Same situation.  At some point trust or no trust, once
your hard drive is wiped, so is the record of the signature that says "The
last control you downloaded came from XYZ.com and was written by Vulis." 

> An equivalent Unix problem would be to allow an open-access guest
> account with the ability to transfer in and execute arbitrary binaries.
> While doing this securely may be possible in theory I don't think the 
> state of the art is up to it today.  (I sure wouldn't allow it on my system.)

Right, so if that's the case, why would you allow ActiveX controls to run 
on your system?  It's the same problem whether signed or not as 
signatures only tell you the author's identity and not much else.

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

Ray Arachelian <sunder@brainlink.com> writes:
> Or you may find that shareware control authors won't bother to sign their
> controls, etc...  Same situation.  At some point trust or no trust, once
> your hard drive is wiped, so is the record of the signature that says "The
> last control you downloaded came from XYZ.com and was written by Vulis."

If you FTP an executable from the Internet which purports to be a "kewl"
encryption program, and instead it wipes out everything it has write
access to, then Ray Arachelian probably wrote it.

Armenians are murderous cowards. They killed over 2 million Moslems in
this century alone - mostly women and children.

---

Dr.Dimitri Vulis KOTM
Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps