> As with a "bad" plug-in, an ActiveX object provider can supply you with
> an updated copy of that object.
But you didn't deliberately download the object. You probably didn't even pay
attention to what the popup said, other than it was authenticated, and you can
still find yourself downloading the version with the hole in it when you hit
another pirate site... in fact that's even likely.
> 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.
But old plugins die away. They can't easily be renewed by malicious people.
There's going to be a black market in cracked ActiveX controls.
> 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.
I would say that a plug-in is, from the point of view of the user, just
as easily verified. The only chance of a plugin getting faked is if the
black hats managed to break into the vendor's site... and that's going to be
a short term problem, quickly fixed.
> If a vendor did decide to replace its key, because it had been
> compromised, they could provide you with simple instructions to do so.
How do they know who to give these simple instructions to?
> I don't follow your reasoning here. Are you saying that because of one
> vendor's broken object you cannot trust all objects?
I'm saying that with (say) 100 vendors shipping security-critical modules,
instead of 2 or 3, they're that much more likely to screw up their security.
> There is no comparison between Java applets and ActiveX objects. They
> are not the same thing, nor are they intended to be.
In terms of web development and presentation, they're *very* similar, and the
way they're going to be used on the web is very similar.
> 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,
Since they're 80386 code, yes, it would have been difficult. For Windows
and Windows-95, I would say it would be impossible... and for NT, it would
not be much better. UNIX does have *some*facility for a jail, and this has
been demonstrated on SunOS, but even there it's only been done for one variant
of UNIX.
Running untrusted applications written in native code without the ability to
create restricted security environments at the OS level is VERY hard.
> The fact that its not being used in a
> secure fashion does not mean it cannot operate securely.
How can it be made secure?
> The emphasis you put on ActiveX's invisibility presumes that a user has
> already turned off security features within the product.
Or the user clicks "OK" when the security-blanket warning comes up. Experience
has shown that users just don't know how to say "no".
Russ, you just aren't *nearly* paranoid enough. Or you don't think like a
cracker. Ask yourself... how would I abuse this capability.
References:
|
|
