>On Tue, 30 Jul 1996 19:40:17 -0400 Russ <Russ .
Cooper @
RC .
Toronto .
on .
ca> wrote:
>I just want to be clear here, I was stating the obvious in my original
>post. AFAIK, the VM is not supposed to be dependent on the OS to
>maintain its security, however, it does depend on the implementation of
>the VM.
Actually, there are several parts. Until I'm done wading through it all
and provide pointers to relevant references, consider that there are at
least the following 4 parts:
- The applet (the application)
- The VM
- The OS
- The comm protocol suite - e.g., TCP/IP
If any of these are not "secure", the applet can not be.
>To me, the inherent insecurity of Java is that it is supposed to be
>viewed as secure.
I disagree. Java is only as secure as its architecture / design /
implementation /environment permit.
>ActiveX should not be viewed as secure by anyone,
>anytime.
Again, I disagree. ActiveX is only as secure as its architecture / design /
implementation /environment permit.
Anyone have a side-by-side comparison of these two approaches? (Another
to-do item for my long list, I suppose.)
>This is a big difference in my mind. Microsoft is not
>attempting to state the security of ActiveX, and its use of digital
>signatures is intended only to the extent that it allows them to prove
>that they were the originators of the applet so they can sell software
>across the net.
Does anyone who does digital signatures implicitly omit the inherent
integrity check? I don't think so. Since I have not looked at the ActiveX
spec, I can't say what Microsoft has done. However, given what I know of
the security people working there, I'd be surprised if they implicitly
omitted the integrity check that seems to be built-in to most digital
signature schemems. Or, am I off in the weeds here, folks?
>If they were attempting to do any further security, the
>WinVerifyTrust API implementation would be checking the signature
>against the CA every time the object was accessed.
Ahhh, another hot topic. Seems to me that this is an implementation
question that everyone faces. Dealing with certificate revocation is a
handfull. Seems to me that checking with the CA each time is an
implementation option in most schemems? Can anyone comment?
>The way its
>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.
As I believe is always the case unless: 1) The CA always checks it's
revocation list or maintains an active list of ALL certiciates - and / or -
2) The client always asks the CA to do so. True?
>From my read of implementor's concerns with making increased security
available, the performance hit of such things as having the client ask the
CA to check upon every access - although I'll bone up on ActiveX and figure
this out.
>This doesn't represent a problem for the sale of software, but it
>obviously represents a problem if ActiveX objects are used the way Java
>applets are used.
Not necessarily, me thinks. Looking at the Java 1.1 Security API (shipping
late Summer or early Fall) it looks like these are all implementation
choices.
So far, here is what I'm looking at:
- http://java.sun.com:80/products/apiOverview.html
- http://java.sun.com:80/products/commerce/
- The details in the Java SDK - found under the Developer's page at
java.sun.com... BTW - Sun deserves the highest kudos for this
documentation effort. When you check it out, you'll find a
complete, downloadable, self-installing / self-decompressing,
documentation library. Cool.
Am I misreading these?
>Clearly Microsoft is leaving it up to other folk to do
>something to secure ActiveX objects for more widespread use than what MS
>intends (IMO).
As is Sun with Java, I believe. The full Java spec is a wonder to behold -
most will not elieve how comperhensive it is. Top-down, soup-to-nuts map
to the future.
>Microsoft also sees ActiveX widely used on an IntrAnet,
>where the security of objects (in many environments) is less of an
>issue. I'm not promoting that idea, but its my interpretation of what MS
>believes.
Again, as is Sun with Java, I believe. The IntrAnet / IntERnet question
necessarily is a matter of policy and the ability of the afore-mentioned
heirarchy of "trust" (if you will) to enforce that policy. It appears that
Java currently can't support this, but will in V1.1 (with their new
security API), however (like ActiveX), I believe that this are ALL
implementation options.
Sun tells me the same thing that Netscape, others, and my experience do:
There is a huge shock factor when one implements or deploys serious
security. A shock factor that most readers of this list are quite familiar
with ;) They are doing everything that they can do to offer implementors
choices so the end users don't see their work simply grind to a stop (e.g.,
the things that support it: applications / systems / nets / firewalls...)
I can't belive that Microsoft is ignoring this.
>I agree that securing the VM should be possible, but so far, its been
>impossible to guarantee. Sun and Netscape may be very security
>conscious, but the simple reality is "can we ever completely trust
>them?".
No, and they say so - explicitly. All they say: if you follow these rules,
you'll have X level of security (modulo the bugs, implementation errors,
and brain fade in application of the technology to the problem at hand,
deployment, operations, and management, of course.) Just like the sane
firewall vendors and any other sane security product vendors.
>I would say, gauging by the activity by companies trying to find
>ways to screen or proxy applets, it would seem the answer is no for
>some. I doubt that we'll be in a position to consider it safe for quite
>some time to come.
I disagree. If you want to be secure, you can be. Its all in the
defintion of what this means to each organization and wheather they will
pay the price to meet their goals.
>The same is true with ActiveX objects, so don't think
>I'm saying that one is better than the other. At least with an ActiveX
>object I'm not struggling to decide if its secure, I just assume it
>isn't.
I disagree. It will be as scure as you make it. If there are ActiveX
defficiencies, those who want to use it will have to ensure that those
defficiencies do not defeat their security goals - just like firewalls and
any other security product.
>ActiveX has longer legs in the PC marketplace because it is more closely
>integrated into the OS.
Ahhh - finally, the basic problem! The OS / comm protocol stack MUST BE
ABLE to support and protect the security mechanisms that depend on them.
This, I believe, is the most profound challenge: how can we trust the OS's
/ comm protocol stack's support and protection mechanisms? Not a trivial
question.
>While this may present a greater challenge for
>developers, it means that a security product developed to deal with
>ActiveX objects can also be used to handle a substantial amount of OS
>security as well.
NO! A thousand times NO! Ahhhh!
The OS's protection mechanisms must allow implementers to protect the comm
protocols stack, applications.... - as they choose - past the basic design
requirements of the OS's protection mechanisms. That is, in some cases,
the basic design requirements of the OS's protection mechanisms *preclude*
everything except a very, very narrow set of comm protocol stack,
application... functions. In other cases, the basic design requirements of
the OS's protection mechanisms *allow* everything. The balance point is
found in building an OS that offers a variety of protection mechanisms.
Unless I'm on a diferent planet here, these are calledSingle Level
(security) Systems and Multi Level (security) Systems, respectively.
>Something developed for Netscape stays in their
>Browser (until they release a complete OS that is), and so the scope of
>the product is somewhat more limited (IMO). Products like Nortel's
>eNTrust can be extended to have the ability to do far more than just
>handle objects arriving via the browser.
Ummm - IMHO, both (and all others) rely on the afore-mentioned property:
the OS must support and protect the security mechanisms that use them -
they can not stand on their own. Sorta like a house of cards in my view.
>The Java language, on the other hand, is a very different animal than
>Java applets.
Yes - language vs program, true?
>When it comes to security, the issues are completely
>different and shouldn't be confused.
IMHO they can't be seperated. If the language does not support security
features, programs written in them - more of less by definition - can not
be secure.
>The Java language, like any
>language, is not constrained by VM's or Sandboxes, or whatever.
I disagree. The language's security features *depend* on everything else
(e.g., the OS's ability to protect them.)
>You can
>develop whatever security implementation you chose in the Java language,
>as you could in C.
Agreed.
>Applets are the fun, neat, easy to implement version
>of Java, but its not the Java language.
Agreed.
>As an example, you will be able to write ActiveX objects with J++ (MS'
>name for their implementation of the Java language), and then script it
>with the JavaScript language if you want.
>
>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.
Agreed. Further, I assert that this can not be done w/o an OS that can
properly protect those security mechanisms.
>For all those who think that filtering Java applets are the way to go,
>think of this. I set my Netscape cache to never expire. I take my
>portable home and access the Internet through my private connection and
>download a malicious applet. I go back into the office to show everyone
>this neat new applet I've found. Bingo, the applet can run despite the
>wonderful filter on the Firewall. I'm not even trying to be malicious,
>I'm just an uneducated user...;-]
Indeed - sounds like the old virus problem, eh? Lack of control over
transitivity between security domains. In the perfect world, when you
attempt to run the applet that you brought in, the current security domain
will disallow it's execution unless it is recognized as being worthy of
trust according to the domain's security policy.
Hence, viri scanning and applet filtering all fall short. The controls
have to be built into the lowest levels of the infrastructure and
ruthlessly enforced. That is, when you attept to execute the rogue applet
anywhere in the "trusted" security domain, the policy enforcement
mechanisms are called into play to approve that action. If the applet can
not be identified as "trustworthy" accoding to the domain's security
policy, it must be prevented from execution. Of course, in the perfect
world, the policy enforcement mechanism also notifies the security officer
that you tried to ignore the policy.
>We need a way to turn off what we consider insecure, and prevent it from
>being turned on again by the user.
Bzzzt! If I accept this philosophy, they I will have to personally look at
everything that wants to execute - no thanks. I want what security
engineering promises: a security domain-wide policy enforcement mechanism
that does this for me. This ain't firewalls or applet filters as they
merely keep certain beasties from getting into the security domain through
a specific channel (most often, only *one* of the Internetwork connection
points ;) )
Before you jump on me, I do recognize reality: given the mess of most
infrastructures, firewalls, viri scanning, applet filters... are needed -
despertately! Moreover, they will continue to be needed. However, don't
get this mixed up with the basic problem. The need for firewalls, viri
scanning, applet filters... is merely an artifact of our inattention to the
basics. A complete (sufficient, correct...) policy enforcement mechanism
must exist at the most basic level of the infrastructure. The continuing
lack of it requires firewalls, viri scanning, applet filters...
Take a look at the total picture that is presented by the work of the IETF
and Java's specs. IMO, these are just specific examples of how current
trends are following the general lay of the traditional security landscape.
A security domain's policy enforcement mechanism must be capable of
supporting what is depending on it. Anything else is an incongruity that
will result in killer security holes that can't be easily fixed.
Firewalls, viri scanning, applet filters... only mediate the significant
residual risk that is left over these days.
>This doesn't exist in any browser
>that I've seen so far, but it will be more possible when the browser and
>the OS are the same thing, when we can use authentication servers to
>provide permission profiles back to the OS.
Agreed, but again: the problem is not the browsers or the browser / OS
combination. Its the underlying policy enforcement mechanism's abilities.
Mean while, back to our regular programming on this channel: dealing with
the current mess of trying to get firewalls to do the things that each
infrastructure's policy enforcement mechanism should do internally.
Synically yours,
RayK
RayK 8) Ray Kaplan
Security Services - P.O Box 23210 - Richfield, MN USA 55423
(612) 861-7198 - FAX (612) 861-3736 - www: http://www.rayk.com/rayk
ray @
rayk .
com - Not an expert, just a battered vet.
|
|
