> To me, the inherent insecurity of Java is that it is supposed to be
> viewed as secure. ActiveX should not be viewed as secure by anyone,
> anytime.
But it will be. People will trust ActiveX applets because they're
authenticated... and there will be holes in them.
Let me give you an analogy that should flip your switches: you know the
biggest security problems in UNIX are caused by applications (running as
daemons or setuid) running as secure components of the system. There are
so many of them written by so many people that they're always finding
new holes in them.
But at least with these, you always have control over what's installed
and running on your system... on a case by case basis. With ActiveX, there
will be a strong tendency to just automatically trust all "big name"
applets. As people set up web pages using ActiveX, people will feel they
have to just turn it on for whole swaths of companies (adobe, sun, macromind,
and so on). So someone who finds a hole in a popular applet or even an
unpopular one from a popular vendor will be able to install the applet *and*
the exploit code on their web page and *zap* you're toast as soon as you
look at it.
Going back to my analogy, imagine being able to install an old buggy version
of sendmail on your victim's machine without them noticing?
> implemented, this check is done once and recorded, subsequent access
> check first to see if its been previously authorized, and if so, it will
> use the object. So if a CA invalidates an object (say, because the
> author was found to be a malicious hacker), anyone who had previously
> accessed the object would continue to use the malicious object without
> question.
*ick*
You're still assuming that all these applets are going to be trustable
because they're from trusted sources. Even on NT there have been holes
in Microsoft's and Netscape's webservers. Does this mean they're nests
of malicious hackers? No, no more than Eric Allman's one.
What *this* means is that a company can't even repudiate a product if
they *want* to, if it's got a hole in it. What this means is that as soon
as the *first* hole is found, it's going to be a security nightmare
forever.
> The same is true with ActiveX objects, so don't think
> I'm saying that one is better than the other.
On the other hand, I *am* saying that. Why? because if someone finds a hole
in Java then Sun and Netscape can distribute a patch and for most people
the hole is gone. People routinely track the latest release of these
programs, because it's free and easy. There's a window of opportunity,
but it's small. There's a path to a better solution.
With ActiveX there's no way to close the window. Even after you fix a hole
it's still going to hit people long after the problem's supposedly solved.
> This all boils down to a desperate need to build better security at the
> desktop, together with better tools for Firewall administrators to
> define permissions for those desktops through gateways to less trusted
> networks (assuming we adhere to the idea that there are "trusted" and
> "untrusted" networks). With better tools at the desktop we can implement
> user policies to define permissions regardless of where they are, and
> what their doing.
And Java is working to build better security at the desktop. ActiveX is
simply misleading people with this half-baked key-signing mechanism.
References:
|
|
