From: Ray Arachelian <sunder@brainlink.com>
Date: Tue, 17 Dec 1996 12:44:32 -0800 (PST)
To: Blake Coverett <blake@bcdev.com>
Subject: RE: Securing ActiveX.
In-Reply-To: <01BBEC03.C251AC10@bcdev.com>
Message-ID: <Pine.SUN.3.91.961217152435.5536C-100000@beast.brainlink.com>
MIME-Version: 1.0
Content-Type: text/plain


On Tue, 17 Dec 1996, Blake Coverett wrote:

> I would be happier running an ActiveX control with Peter Trei's signature on it
> than I would an unsigned control in a sandbox.  (This kind of a trust decision
> is probably the normal case in the intranet world.  ActiveX as it sits is quite
> sufficient for rolling out internal intranet applications.)

And I'd be happier running the signed ActiveX control, written by Peter 
Trie, or anyone else within a Sandbox regardless of signature as it 
increases security.
 
> On the second point, I never suggested that a sandbox would require virtual CPU
> emulation.  What I do find likely is that the overhead from the extended types
> of checking the kernel would need to do would probably outweight the performance
> advantage of native code over a JIT compiler.  The DES cracker is probably not
> a good example of the problem because it would make virtually no API calls.

You did however say this a few days ago:

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

The above says that you wouldn't want to run ActiveX in a sandbox while 
you would want to run Java in a sandbox.  The difference between 
technologies is that one runs native the other emulative.  I wouldn't 
want to run ANY foreign code outside a sandbox.  Java or ActiveX.
 
The whole point of this was creating a distributed network of DES 
crackers.  There is zero API security checking on a control that does 
nothing but math and integer operations.  The loss of performance occurs 
when the control or applet wants to read or write to the file system or 
tries to talk over the network, which a DES cracker won't do very much 
of, hrrrm?  In other words, an ActiveX sandbox will not slow down the DES 
cracker, and it will increase security.  What's your problem with it 
being used on ActiveX when you say it's cool to use on Java applets?

> This is scaremongering.  No, I don't virus scan every new CD I get from
> Microsoft/Netscape/etc, do you?

I back up my hard drives to CDR's.  While it is true that viruses can get 
into my system, I'd notice them quickly with the scanners, and if they 
did manage to wipe my drives, I'd have the data safe on CD where they 
can't write.  I don't store programs on the CD's, just data.

> More importantly to the discussion at
> hand, what is to prevent said virus from infecting the compiler used to
> build the sandbox?  Part of the decision to trust a software vendor must
> include trusting that they use appropriate clean build procedures.

Precisely why you need to sandbox an OS.  A good operating system / virus
scanner doesn't allow programs to modify other programs, except for a
user approved compiler.  If you've ever used a Mac compiler and 
Symantec's SAM, you'll notice that if you enable certain features, you 
have to allow exceptions for your compilers - you as the user.

If a virus infects your compiler it is because you've allowed it 
permissions to do so previously.  (With my Mac, I have the virus checkers 
warn me, even when I compile. Yes, it is annoying, but it's much safer.)
 
> If you choose to run an unsigned control all bets are off.  On a related note,
> I recently saw a Java implementation of a board game that recommended
> the user download the zipped up .classes and run it locally.  How many
> average users realize this would disable the Java sandbox entirely?

How many users know how to download the jdk and run the java vm locally?  
Yeah, all bets are off when you download an unsigned control, but having 
them downloaded into a sandbox means that even if they are written by 
VulisSoft, they won't damage anything of importantce.
 
> > 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.
> 
> You mis-read the paragraph above.  Trying to build the sandbox for native
> code as you've described is akin to the problem above.  Is it not?

It is not.  The sandbox runs in supervisory (Ring 0 for you intel freaks) 
mode, the code it allows to execute runs in user mode (ring 3 is an 
example) so no matter what the control does, it cannot get into anything 
the sandbox doesn't allow it to since it cannot switch to supervisory mode.
(Assuming you've implemented your sandbox securely and it lacks security 
holes.)

At the same time, only I/O calls are hindered by the extra checking, so 
it's a moot point in the case of the DES cracker.

Now what you are saying is that if you don't trust the control, why 
should you trust the manufacturer of the sandbox?  The answer is that 
they are a highly more visible target for lawsuits than a possibly 
unknown author who wrote some control which you ran ten months ago that 
decided to wake up today and wipe your drive.

There's a big difference between protect the user wholy and presenting a 
dialog box where they can press Ok to download a destructive bit of code.
In one case the user is culpable for agreeing to download destructive 
code, the other prevents the problem from happening.

Also, the secure sandbox source code can be made visible (if such an 
entity as one that wrote it deems to do so in the name of trust.)  See 
pgp.  need I say more?  Would you trust PGP more or less than say Norton 
Diskreet?

Whether or not you are qualified to analyze PGP source code isn't the 
issue, you at least have the ability to do so once you learn how.

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