[prev in list] [next in list] [prev in thread] [next in thread] 

List:       firewalls-gc
Subject:    RE: [NTSEC] ActiveX, MSIE and Quicken
From:       Russ <Russ.Cooper () RC ! on ! ca>
Date:       1997-02-01 23:40:48
[Download RAW message or body]

To try and keep this on a Firewalls vein. The tunneling of anything over
HTTP is, in my opinion, the crappy technology. That goes for Java
applets or certificate authentication for that matter. I don't like the
idea of combining diverse tasks within a single channel if its possible
to avoid it, and it is possible, so the only reason its not being done
is to USURP FIREWALLS.

ActiveX as an Internet web surfing technology (i.e. interaction between
non-cooperating trust environments), despite the ability for vendors to
incorporate their bar codes on their packages, is just another
implementation of that same crappy technology.

BUT...

The issue is whether or not there is to be a future technology that
isn't crappy. I don't see how Firewall administrators can honestly say
that they trust Java applets any more than you can say you trust ActiveX
objects, when their coming from an untrusted source (even if that source
has signed the applet with a trustable digital certificate). Now don't
respond with the Java applets are more secure than ActiveX objects
thing, please. Neither can be completely trusted to the extent necessary
for a Firewall administrator to honestly say its OK to let it in.
ActiveX has no security, and Java applets have lots of security, but
neither provide sufficient control or reporting for a Firewall
administrator to really know what's happening where, and the sandbox
can't be trusted enough to say you don't need to care what a Java applet
it doing, IMO.

So neither technology are THE answer. Both technologies are
demonstrations of future technology which will become AN answer. Whether
either survive, or some hybrid or completely different technology
emerges as THE answer is still to be seen.

I argue that its been possible for applications to be installed on an
OLE machine and do what these malicious ActiveX objects (or hypothetical
objects) can do. It was required for them to be retrieved (in whatever
fashion), installed (in a variety of fashions including Trojans), and
invoked (again, covertly was not out of the question). So in the case of
an ActiveX object from a web page, you are asked if you want to retrieve
the object, whether or not it should be installed, and whether or not it
should be invoked. The issue seems to be how easy that has become, but
Windows 95 and NT 4.0 both implement a model that make that easy and
somewhat hidden (a shortcut accessed across a network share could easily
install itself without any notification whatsoever).

ActiveX is a big word, it covers a whole spate of technologies, of which
only one is its ability to be downloaded/installed/invoked from a web
page. Disparaging ActiveX as a technology because of one aspect of it is
like saying that Java applets are useless because they allow a reverse
connection back to their originating machine. Its one part of the
technology that needs to be replaced/improved.

Since Windows HAS BECOME an ActiveX environment, from top to bottom,
what's needed now is more emphasis on the environments security. Windows
NT 4.0 represents, somewhat, the environment that all OLE-based
platforms have to become. An environment where distributed computing is
possible, but can also be implemented securely. But this discussion
digresses into issues that shouldn't be debated here.

Bottom line is that with so little interest by Firewall administrators
in desktop security, their minds concreted in the idea that everything
is going to be controlled at the company gates by the GateKeeper, its
obvious that the Tunnellers will win and the GateKeepers will lose. With
that goes the legacy systems that put bottlenecks on technology and
innovation in favour of time-tested and proven security models. Fine,
it'll work great for lots of implementations, but while those walls
crumble and the GateKeeper continues to be assailed from his/her own
charges, at some point the realization will hit them that desktop
security and an integrated administration/security platform is the only
model that can move forward with the technology.

They say that a month on the web is the equivalent of a year for
anything else. So if a new Internet product is in public beta for 5
months, that's supposed to be the equivalent of 5 years. Obviously from
a security perspective this analogy doesn't work, since people aren't
testing products 12 times faster than they used to...;-] But if IS
decisions are being done at or near the pace of the Internet, clearly
something has to give somewhere. The only way that can happen is to
expand the scope of the GateKeeper from beyond the Firewall to include
the desktop. If these new technologies are implemented with this in
mind, it would be possible for a Firewall admin to probe, control, and
enforce a security policy at the desktop through a server cooperating
with the Firewall. ActiveX does make this possible, but the tools don't
exist yet (or aren't widely known) so it seems impossible.

So again I say it, block ActiveX objects if you can at your Firewall.
But get your head out of the sand and realize that this very same
technology could be put to valuable use in your environment to enhance
your ability to implement and enforce your security policy, and it all
could be done in total cooperation with your Firewall. All we have to do
is force the vendors to deliver the products that could do this. This
doesn't translate to a call for NT Firewalls (although light 'em if you
have 'em).

But if you think you can say that ActiveX is bad so take it way, you'll
have to tell them to take away all your MS desktops as well. I'm sure
many of you have been saying that for a while now, but the facts are in
front of the majority of you and can be seen just by looking around your
office.

> Cheers,
> Russ
> R.C. Consulting, Inc. - NT/Internet Security Consulting
> "Why does Plug-n-Play so often turn into Unplug-n-Pay?"

[prev in list] [next in list] [prev in thread] [next in thread]