RE: Securing ActiveX.

Jim McCoy wrote:
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...
No, it's not really the accountability that's the issue. It's the ability to choose before the fact that I 'trust' the software's author.
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 :)
Yup, point well taken. <story user=clueless>I popped into an empty users cube last week to borrow the phone. On the monitor was a post-it note from one of his co-workers that read, 'Please write your password here:' and of course the helpful fellow had done just that.</story> With real users I suspect only centrally administered security decisions that they can't override will be effective. Hmm... wonder what I can retrofit into IE to accomplish that.
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.
Shh... we have enough kool dewds floating around here looking for ideas.
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.
I agree 100%. The intent of my comments was that such security *is* possible, but it's not available in widely deployed mass-market OS's. I'd love to hear feedback to the contrary, but it seems to me that it's extremely difficult to layer that type of security onto an existing system. -Blake (who's thinking about putting crazy glue into one user's floppy drive)

At 5:49 PM -0800 12/16/96, Blake Coverett wrote:
I agree 100%. The intent of my comments was that such security *is* possible, but it's not available in widely deployed mass-market OS's. I'd love to hear feedback to the contrary, but it seems to me that it's extremely difficult to layer that type of security onto an existing system.
It depends on the level of compatibility you need. If you need bug-for-bug compatibility, then you get the security bugs too. The only advantage you have is being able to run two "systems" on one set of hardware. If you allow some non-compatibilities, then things get better. We had a Unix running on KeyKOS which would run much of the Unix functionality. For example, we ran a number of the X demos. On our IBM/370 version, we ran IBM's CMS system with binary compatibility. We used it for our development environment, including editing, source management, compiling etc. (There was one IBM product we did not run. It needed to read real-addresses to grunge through system control blocks we hadn't emulated. Since it had no interface documentation, we would have had to look at its accesses, figure out what it wanted, and simulate it. Too much work for what was a pretty bad product.) If I was writing a Netscape implementation for KeyKOS, I would run Java Applets in a separate protection domain because it would be relatively easy. ------------------------------------------------------------------------- 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

Blake Coverett <blake@bcdev.com> writes
No, it's not really the accountability that's the issue. It's the ability to choose before the fact that I 'trust' the software's author.
No, you have it wrong. It's the ability to choose before the fact that you 'trust' the _key_ that signed that applet. The key is everything and it does not necessarily have any connection whatsoever to the software's author. You just hope that it does... andrew
participants (3)
-
Andrew Loewenstern
-
Bill Frantz
-
Blake Coverett