Steve Betts said...
"As usual sun via are making an attempt at security but leaving holes, and
microsoft are not. There is no support yet for signing code."
Let's be clear on one things here. SunSoft said for a long time that the
use of applets across the Internet was not recommended, and that support
for running applets in any browser was provided to test those applets on a
secure, internal network. Please correct me if this is an incorrect
statement, but to the best of my knowledge, SunSoft *still* say that the
use of Java applets across the Internet poses a security risk to your
internal environment.
With that said, its true that there is still no Internet site capable of
authenticating the digital signatures on ActiveX objects. This is not the
same thing as saying "There is no support yet for signing code". Like
SunSoft with Java, Microsoft provides you with the tools to sign objects,
test those signatures, and test the authentication process within your own
machine. I do understand what was intended by the statement, but I just
wanted to add that clarification.
For those who haven't already been told this, ActiveX simply means Network
OLE (or Object Linking and Embedding). It also incorporates the Common
Object Model (COM) and the Distributed Common Object Model (DCOM). Its a
marketing word which is loosely tied to the idea that Microsoft is
Activating the Internet...whatever.
The ActiveX model simply extends OLE to incorporate distributed objects.
The security implications are tremendous, and some will say it is far worse
than anything Java poses. As was pointed out, SunSoft are at least
attempting security, while Microsoft are not doing anything beyond
providing a means to authenticate objects against a known trusted signature
escrow (currently, this infrastructure is to be provided by VeriSign Inc.
and GTE).
http://www.microsoft.com/intdev/signcode/ provides all the currently
available public information, and there is a mailing list for code signing,
although its hardly active yet.
The debate rages today in many sites as to which of these two approaches
are better. With the Java applet, we have to rely on the sandbox not to
leak. So far, this has been pretty difficult, similar to building a good
firewall solution. Since the same sandbox is being used everywhere,
breaking it is something of a badge of honor for some. Others, like the
folks down at Purdue, are truly trying to ensure that the sandbox is sound.
With ActiveX, there is no sandbox, and therefore, I would suggest it poses
less of an attraction to those who would attempt to break in. This by no
means reduces the potential risks, but it does make it less of a target to
the exploratory types.
Internet Explorer 3.0 has the ability to prevent the downloading of any
ActiveX object which is not authenticated against a "Safe Source"...or code
signing authority. If the signature received from an object is not
validated by the "Safe Source", then the object is rejected and anything it
might have wanted to do is not done, pretty simple really. The signatures
can be a variety of formats, X.509 or PKCS#7 for example, but Microsoft is
not attempting to dictate policy in this arena. They simply want to get
acceptance by the widest group possible. Microsoft have published their
proposed specification for performing the authentication process, also
known as WinVerifyTrust, which can be found under the above mentioned URL.
Since the process required to get a digital signature will be governed in
much the same way that getting an SSL signature is today, it means that
there will be a certain level of assurance involved. Before you clip this
line out and start sending me reams of mail about it, let me break it down
a bit more.
1. There will be different levels of signature, representing the different
levels of assurance obtained by the signing authority. This is to
accommodate the shareware vendors and smaller organizations who either do
not have, or cannot produce, the level of documentation required for higher
assurance. This makes sense if you think about it, since you would have
less recourse against these entities anyway.
2. There will be a mechanism in IE which will allow you to determine your
acceptance of the various levels of signatures.
3. There will be some way to ensure that the security components of IE
cannot be modified if a site administrator chooses. This may only be
available as part of some administration tool like Systems Management
Server, although there may be a Site Policy tool made at some point. Since
the technology here is not proprietary to Microsoft, such an administration
tool could be made by anyone for any browser. Furthermore, since SunSoft
have also indicated a desire to use digital signatures, some lower level
authentication server will probably come into existence. More in point 4.
4. Since the browser can be configured to use one, or multiple "Safe
Sources", a localized authentication server could be used to provide
administrative control to an IS group like InfoSec, or the Firewall
Administrator. It may be nothing more than a relay server, or could offer
considerably more functionality...but I won't go into those details here...
So, a browser could be configured to only accept objects which have the
highest level of assurance from only the most reputable signature
authorities, the signature could be verified correctly, and you could still
end up with something that trashes your machine or does something illegal
or undesirable. This is true.
But...you would at least be able to obtain the certificate information from
the signing authority to determine who's signature created the havoc, and
then take appropriate steps. Probably, although this hasn't been determined
yet, notifying both CERT and the signing authority would be the logical
first step. Once the act is verified (i.e. it does it to someone else's
machine also), the signature would be revoked and more tangible actions
could be taken according to the agreement signed between the signing
authority and the object owner.
The real point is, you have about as much assurance as you have with shrink
wrap software, and possibly a little more depending on how granular the
assurance levels end up being.
What you don't have is some myth of a belief that you can trust the stuff
implicitly. Rather than trying to pretend you can build a complete and
totally secure sandbox that still has a network connection to the Internet,
you instead are forced to continue to look at the viability of the vendor,
the value it adds, and the need to use it. We are all faced with the issue
that everything under the sun is being stuffed down port 80, we're stuck
with that one for now. With MIME scanning technology, like Trend Micro's
VirusWall, we can make a stab at scanning for viruses. This doesn't prevent
applications from doing things we don't want it to do, however.
I personally don't believe that either Java, or ActiveX, were developed
with the intention of targeting the Internet. Both technologies offer far
more benefits when used on an Intranet. From an Internet perspective,
ActiveX offers nothing more than Java does when it comes to authentication
or verification (assuming that Java applets get signed, which I believe
they will...).
If any object/applet, regardless of who made it, operates solely over port
80, I throw it in the trash and deny all streaming objects at the firewall.
If a conscious effort is not made by developers to provide a means for
Firewall Administrators to filter their stuff, toss it. This goes way
beyond object technology, though, as we simply don't have enough ports to
assign everyone their own for their own product (well, we may have enough
but we don't want to recreate the numbering problems we're having with IP
addresses with ports, do we?).
Depending on how the signature servers get written, there may be some
relief in localized servers which have application suites programmed in
according to the signatures involved, but that's subject to session
hijacking and stuff, so it still needs work...
Now the discussion of ActiveX vs. Java on an Intranet is another story, but
since it has little to do with firewalling I'll leave it alone...here...;-]
Cheers,
Russ
p.s. I'm looking for a new job...;-]
Follow-Ups:
|
|
