Distributed System’s Middleware: DCOM's ActiveX versus Java's JavaBeans and CORBA's IIOP

1. Distributed System’s Middleware:DCOM's ActiveX versus Java's JavaBeans and CORBA's IIOP

2. COM • Component Object Model or Common Object Model • Promoted by Microsoft as a general-purpose architecture for building component-based software • Main purpose was to define reusable objects for which designer could use to create larger systems from these objects

3. COM continued • Allows developer to create COM objects not specific to any languages or platform as long as they stick to the binary structure Microsoft proposed. • Can interoperate with each other

4. Introduction to DCOM • COM on a wire • DCOM stands for Distributed COM • Basically, DCOM allows use of component objects present on different machines either within or across networks • Put in another way, DCOM is COM on steroids.

5. ActiveX The Chaos Computer Club of Hamburg, Germany showed how to move funds from one back account to another - all using an ActiveX control. This control tricks finance software Quicken into removing funds from a user's account when a user logs on to their bank. Microsoft, the developer of ActiveX, heard about the incident after receiving a phone call from someone in Germany who viewed the Chaos Computer Club's story on German national television. This incident illustrates the potential dangers associated with ActiveX. Unlike Java applets, which are not capable of reading or writing to local files, ActiveX can do nearly anything. Microsoft plans to launch an ActiveX education campaign in response to this attack.

6. Some Quotes • “Microsoft's core competency is monopolization” Steve Litt, 9/6/2000 • Yesterday OLE, COM, DCOM, MFC, IIS, ASP. Today C# and Microsoft.Net. What next? The Open Source world is one of continuous improvement. The Microsoft world is one of continuous U turns. • Getting back to technology selection. There are some who believe Microsoft's line that their software provides "interoperability". Don't fall for that line. Microsoft's technology provides crash-prone non-modular systems whose primary design feature is to enhance Microsoft's monopoly power. You can do better than that. Just say no to Microsoft.

7. Introduction to ActiveX • Set of technologies that enables interactive content for WWW • Can be invoked from web pages through the use of a scripting language or directly with an HTML object tag • Can be signed or unsigned • Signed control provides a high degree of verification that the control was produced by the signer

8. ActiveX continued • Doesn’t guarantee the trustworthiness of the control’s intended functions. • ActiveX are binary code • ActiveX executables can be configured to run in certain machines, under certain conditions • Allowing for scalability • Allowing for increase security

9. DCOM/ActiveX vs CORBA vs Java • Openness • Java, CORBA : yes • DCOM/ActiveX: somewhat • Platform Independence • Java, CORBA: yes • DCOM/ActiveX:no

10. Why DCOM/ActiveX isn’t as platform independent as Java or CORBA • “Microsoft unapologetically will make sure ActiveX works best on Windows” –Bob Muglia, Microsoft (Source: Client Server News and Red Herring Magazine) • DCOM/ActiveX isn’t supported on MS-DOS or 16-bit Windows environment

11. Comparisons continued • Language Independce • Java: no • DCOM/ActiveX: somewhat • CORBA: yes • WWW support • Java: yes • DCOM/ActiveX: 32 bit windows only • CORBA: yes

12. Comparisons continued • Scalable? • CORBA: definitely yes • Java: more so than ActiveX • DCOM/ActiveX: no • Security: • CORBA: yes • DCOM/ActiveX: no • Java’s JavaBeans: yes

13. Comparisons continued • Benefits: • ActiveX: a. reusable components • b. has more capabilities than Java’s JavaBeans • c. are available to meet many needs and functionalities • JavaBeans: a. reusable • b. secure • c. trusted JavaBeans has more functionalities than regular applets. -CORBA: a. mature

14. Comparisons continued • DCOM’s main competitor is CORBA; whereas, ActiveX main competitor is Java’s JavaBeans • CORBA and Java complement each other.

15. Fallacies regarding ActiveX • All ActiveX controls are unsafe • All ActiveX controls either are the same as regular executable files or differs from them completely • ActiveX controls make IE unsafe due to its lack of security • ActiveX controls are safe because they are signed

16. Fallacies continued • All ActiveX controls problems can be avoided if you just avoid using IE

17. ActiveX Security and Risks Can be divided as follows: 1.Imported/Install Controls 2a. Scripted Controls 2b. Execution Controls

18. Imported/Installed Controls • Has no way to measure their capabilities • Should be base on the source of the control • Inadequate for 2 reasons: • Signer of control may not be able to determine the control safety as the end user is • End user must trust the distribution sequence. That is, it wasn’t modify somewhere in that distribution sequence to make it malicious • Signatures persist

19. Imported/Installed Controls • Controls need only be registered once per machine • Will lead to problems if a machine is shared by multiple users. Any one user is capable of downloading a control, at which point it is available to all the users on that machine. • Even worse if the machine is shared on a network • Controls does not always has a solution to a particular vulnerability.

20. Scripted Controls • Responsible for implementing their own security • Can be used in ways that were unintended by its original author. Can lead to unexpected behaviors that could be exploited by hackers • Can invoke other controls without the user knowledge.

21. Scripted Controls • Can escape the confines of the IE’s environment • Controls’ engines might not provide IE’s security regarding ActiveX • Its cross-site scripting is poorly understood • Can lead to vulnerabilities regarding cross-site scripting attacks

22. Execution Controls • Running controls has more capabilities than tools that run strictly in IE’s environment • Due to fact it is native code • Running controls can be based on IE’s securities. However, ActiveX controls do not rely on IE; can be installed and executed without using IE.

23. Execution Controls Cont. • Running controls run under the privileges of current user. No known way of restricting its privileges • Running controls do not have an effective level of abstraction • Running controls are fairly difficult to assess and manage • Running controls’ securities are fairly coarse. It’s all-or-nothing in IE.

24. Securing ActiveX Controls • Using Administrator Approved setting • Using Authenticode • Using CodeBaseSearchPath • Using Internet Explorer Administrator Kit • Using IObjectSafety • Using kill bit • Using security zones including a fifth built-in zone, called ‘My Computer’ zone

25. Broadening ActiveX Appeal • Make it more secure through the use of some kind of sandbox like Java • Make it where it is platform independent like .NET or JVM • Don’t have this windows-only mentality

26. Conclusions • Microsoft can make ActiveX more appealing if they were to provide more security to ActiveX • They need to embrace CORBA not work against it • They need to work with Java, not against it