>> ActiveX, on the other hand, doesn't claim any responsibility whatsoever
>> for what an object can or cannot do. They do not try to give you a
>> sandbox, you have to make that yourself.
>
> "That is simply not true in any practical sense. Microsoft is pushing
>ActiveX and signing as a solution to the security problem. The masses are
>getting the message "Microsoft says ActiveX is secure". Microsoft is not
>saying precisely that, I grant you, but what they're saying is close enough
>that that's the message that's being delivered."
>
>I have said it many times before publically, and I'll restate it here, IMO
>ActiveX is not secure, IMO it is not intended to be secure, IMO Microsoft are
>misleading people with their statements, IMO third-parties are going to make
>ActiveX-bearing environments secure against ActiveX's insecurity.
>
>Clear enough for everyone?
>
>The code-signing has its values for software distribution, but as Russian
>Mark (mdr @
vodka .
.
.
) pointed out, reliability does not make a security
>solution.
>
>My point is only that to anyone who looks at the two technologies with some
>technical knowledge (which is what we all are here) will see quite clearly
>that ActiveX does not provide security in the form necessary to open your
>system up to it. It doesn't have any components in it that are supposed to
>provide that network-aware security, it simply has this code-signing part
>that does reliability. Java applets, and the VM, OTOH, do come with security
>implied and delivered.
>
>> The inherent integrity check is part of what proving ownership is all
>> about.
>
> "Sure, go ahead and sign the applets. That allows you *some* control over
>what's installed (but you're not going to refuse Microsoft's signature, are
>you?), but you still have to assume that any applet that uses data provided
>by an external source is potentially another security hole."
>
>You're repeating what I'm saying, obviously in a far better way than I.
>
>> You must be talking about a completely in-house environment here,
>> otherwise how can I ever *ensure* that a third-party object does not
>> contain deficiencies that compromise my security goals, with technology
>> available today?
>
> "You can't. But with normal applications you can remove them and they stay
>removed. If there's a bug in Microsoft Geewhiz 3.4 you never know when you'll
>hit a page that'll download it to you again."
>
>Well, sorry, but this isn't true either. I can't remove what my employee
>installs on his portable at home. You can write a policy for it, but that's
>not going to protect you. Heck, most of the time its impossible to guarantee
>that a program doesn't get installed in the office, unless you've removed the
>floppy drives (mind telling me how you do that with most portables?). So
>applets are no different than programs that are delivered on disks, CDs, or
>any other media.
>
>> As virus in DOS have proven over and over again, if I intercept
>> acceptable calls and redirect them somewhere else, I can change the
>> basic functionality of the environment. So if I intercept all calls to a
>> disk drive and respond properly with malicious information, the OS does
>> not know the difference.
>
>"Of course in NT you're not supposed to be able to do that. And if NTFS
>security was up to snuff you couldn't. Or rather... NTFS security seems to be
>pretty good, but as shipped by Microsoft it's largely disabled."
>
>Well, I was trying to show how it would be possible to seperate the security
>of the OS from the security of an application. If the VM doesn't permit
>applets to do things to the OS, by intercepting calls, it can attempt to be
>secure.
>
>Cheers,
>Russ
>...eek, give me some broken software, I'm going into beta withdrawal...
>
>
>
Follow-Ups:
|
|
