>If this sort of hole existed in a plugin, or a browser, you could
upgrade
>to a fixed version, or not use it. With an applet the broken version
can
>always be uploaded by an attacker and since it's signed by the key of
the
>original company... and the company can't revoke the key without having
>to release a new version of ALL applets signed by that key,
As with a "bad" plug-in, an ActiveX object provider can supply you with
an updated copy of that object. There is no need to revoke the key from
the vendor's perspective if they can simply get you to obtain the
updated version of their object. This, IMO, is no different than a
plug-in vendor who has a similar problem with some exploit being found
in their code. They must find a way to get you to obtain an update, and
until then, they have no means to protect you from said exploit.
So from the plug-in vs. ActiveX object perspective, both suffer from an
inability to automatically revoke, but at least an ActiveX object is
capable of being verified prior to its installation, which a plug-in
cannot do.
>and then getting Microsoft to release a new version of Explorer
>that doesn't have the old key in it.
The installation of Explorer merely installs the certificates of the
larger CAs, not the vendors. They don't even install Microsoft's key? So
I'm unclear as to what you intended to say here. You can also delete any
installed certificate, including those of the CAs, should you want to.
If a vendor did decide to replace its key, because it had been
compromised, they could provide you with simple instructions to do so.
Obviously it wouldn't be advisable to do that without being certain that
the "real" vendor is asking you to do so, but the functionality is
present to remove a key once accepted.
>So instead of depending on one company to keep their package secure, if
>you allow ActiveX applets in you're depending on *all* the companies
that
>write applets not having any bugs, and if there is one then it's a lot
>harder to get it out there and fixed.
I don't follow your reasoning here. Are you saying that because of one
vendor's broken object you cannot trust all objects? I doubt this is the
case, but that's how it sounds.
>I'm not happy with the implementation of Java's sandbox... there are
safer
>ways to build one... it's so much safer than ActiveX that there's no
contest
>in my mind which way to go.
There is no comparison between Java applets and ActiveX objects. They
are not the same thing, nor are they intended to be. In IE, Java applets
operate within a sandbox, and ActiveX objects do not. It wouldn't have
been difficult to make ActiveX objects operate within a sandbox, but
they're intended not to be restricted to the confines of a sandbox. This
is clearly a different approach from a security perspective, which is
why you can disable ActiveX objects should you choose to do so. ActiveX,
as a technology, is primarily intended to provide a means for doing
distributed application installation and execution. Seen as such, it
offers a lot of potential for a variety of functionality which the Java
language provides, and as with the Java language, offers the ability to
embed security into the controls. The fact that its not being used in a
secure fashion does not mean it cannot operate securely.
The emphasis you put on ActiveX's invisibility presumes that a user has
already turned off security features within the product. Like with
Firewalls, its possible to reconfigure IE to be less secure wrt ActiveX
objects, just as its possible to set up generic packet relays with most
COTs Firewall products. This does make the product less secure, but it
also makes it more flexible. So I will agree with you, if you are
primarily concerned that your users are going to turn off security
functionality which is turned on by default in IE, then it would
probably make more sense to install Netscape instead. This will not
eliminate the potential for *all* security risks, but it will reduce the
risk a little bit. You could also prevent users from making
modifications to their IE configurations in a casual way, but presumably
this wouldn't be sufficient in your scenario.
If, on the other hand, you feel its possible to have your users
understand and follow some simple instructions, you could let them use
IE. ActiveX objects are not invisible until the user makes them
invisible, and given that you do not hit them on every page or on every
site, their intrusion into the users experience is not significant in my
mind enough to make a user turn off all notification of them. I
personally feel that this aspect of IE has been blown out of proportion.
If I see a new ActiveX control once a week that is a lot. Obviously this
is going to increase over time, but so will the ability to control the
ActiveX environment.
>... and the act of downloading it massively
>reduces the window of opportunity for an attacker, since plugins are
>typically taken from well known central sites rather than blindly
slurped
>up from whatever hacker's nest you might have clicked through to.
>From a security perspective, I'd say that a plug-in, which are typically
larger than an ActiveX object, offers more opportunity for exploitation
than an ActiveX object by virtue of the fact that its larger and has
more code in which to contain bugs.
Cheers,
Russ
R.C. Consulting, Inc. - NT/Internet Security
Follow-Ups:
|
|
