ActiveX security, or the lack of security, has more than its fair share of critics.
Java experts are quick to point out that ActiveX has no isolating security sandbox to keep controls from causing malicious damage to a computer. They say at least that Java’s default security confines applets to a limited set of computer resources. Virtually everything you can do with a programming language can be done with ActiveX, including remote control Trojans, file damage, and buffer overflows. Not so with Java.
As covered earlier, most of ActiveX’s known exploits have come when a control was marked safe for scripting or initialization when it should not have been. It is almost impossible to determine whether a control can be exploited or not. Software publishers can take guesses, or hire hackers to try an exploit them. But until the control has been released to millions of users and undergone long-term investigation, the vendor alone cannot guarantee safety. If this is so, then no control should be marked safe for scripting, and thus ActiveX loses a lot of its functionality.
Buffer overflows are particularly
bothersome in ActiveX, because in general, it does no parameter
checking. A loosely written control, and there are many, can allow a
web page script to error out the control and execute malicious code
on a user’s system. Several controls on the market today,
including the popular