RE: Securing ActiveX.
In response to my questioning why one would want to run an ActiveX control in a sandbox Ray writes:
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.
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.) 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.
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.
This is scaremongering. No, I don't virus scan every new CD I get from Microsoft/Netscape/etc, do you? 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.
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 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?
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.
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? regards, -Blake
Why do people talk about sandboxes? Sandboxes are places where people play. I want to run hostile code in a jail cell, with carefully designed interfaces where my jailers can control the messages it sends in and out. If this is a game, why is Microsoft spending hundreds of millions of dollars to put ActiveX everywhere? People are going to start building safety critical systems with these toys, and should be encouraged to engineer them for real world use. Crypto relevance? Java is a pretty damned flexible tool for writing pluggable cross platform modules, including crypto software. It behooves us to make it solid. See http://www.brokat.de/welcomee.htm (English version) for plugable crypto. See Ross Anderson's Murphy's Law paper for why cross platform is so important. http://www.cl.cam.ac.uk/users/rja14/ Adam 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.) -- "It is seldom that liberty of any kind is lost all at once." -Hume
At 7:19 AM -0800 12/17/96, 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.)
While I might agree about Peter, I wouldn't agree if the signature was Microsoft's (or any other large software vendor). There is just too much room for bugs and or Trojan horses to enter via that route.
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.
Not necessarily true. See Goldberg, Wagner, Thomas, and Brewer, "A Secure Environment for Untrusted Helper Applications, Confining the Wily Hacker" from the 6th USENIX Security Symposium proceedings. (The paper won the "best paper" award too.)
This is scaremongering. No, I don't virus scan every new CD I get from Microsoft/Netscape/etc, do you?
No, but I would prefer to know what their applications are accessing and why. That's why current systems are not good from a security prospective. I would be a great advance in security if *everything* ran in a sandbox. A sandbox specially built for it where it had access to the things it customarily needed and all other access was mediated by the user. This kind of environment has its costs, not so much in performance as in changing the way people work with computers, but it would be a lot more secure. ------------------------------------------------------------------------- Bill Frantz | I still read when I should | Periwinkle -- Consulting (408)356-8506 | be doing something else. | 16345 Englewood Ave. frantz@netcom.com | It's a vice. - R. Heinlein | Los Gatos, CA 95032, USA
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 =========================
participants (4)
-
Adam Shostack -
Bill Frantz -
Blake Coverett -
Ray Arachelian