Search the Catalog
Malicious Mobile Code: Virus Protection for Windows

Malicious Mobile Code

Virus Protection for Windows

By Roger A. Grimes
August 2001
1-56592-682-X, Order Number: 682X
542 pages, $39.95

Chapter 11
Malicious ActiveX Controls

ActiveX is considered by many to be Microsoft's answer to Sun's Java language, but it is much more. Chapter 11 discusses ActiveX, digital signing, and Microsoft's Authenticode security program.


Unlike Java, there isn't an ActiveX programming language. Instead, ActiveX is a group of Microsoft software development tools that allow Windows programs to work across networks. Initially code-named "Sweeper," the ActiveX architecture was formally announced at a San Francisco developer's conference in early 1996, as Microsoft's way to address the booming Internet programming market. At that conference, a slew of new tools were announced in support of ActiveX, including VBScript, the OLE Scripting Service, new APIs, Microsoft-developed Internet protocols, and ActiveX controls. Microsoft released these new tools as part of its ActiveX Software Development Kit (SDK). ActiveX is an extension of Microsoft's 32-bit Windows API and Component Object Model (COM) models, and is now covered under the umbrella of the Distributed COM (DCOM) architecture. DCOM encompasses all programming tools that allow a Windows client to use a server program over a network. This distributed programming architecture is eventually culminating in Microsoft's .NET initiative (covered in Chapter 15).

Although it began as a reactionary response to competitive pressures, ActiveX is really just a natural evolution of Microsoft APIs which allow data to be shared between applications. Microsoft's Object Linking and Embedding (OLE) technology allows users to place data objects from one application into another, something DOS couldn't do. The first versions of OLE allowed users to copy data objects from one program to another. For example, a graphic chart could be copied from a spreadsheet into a word processor. The next phase of OLE allowed a linked object to "live" in another application. Now, a user could edit a chart in a word processor, and with an OLE link to a spreadsheet have the changes made in one appear automatically reflected in the other. ActiveX extends the functionality and allows, not just the data, but the entire application to be shared across the Internet.

Today, you can save a spreadsheet or document directly to the Web, or allow multiple users flung far across the Internet to make changes to a document you created. Objects, pictures, even sound files, can be linked from their distributed locations onto one page. ActiveX includes all the tools and methods to allow programmers to distribute their applications across the Web into users' desktops.

TIP:   ActiveX programs can be installed, used, and executed by hundreds of applications, including Microsoft's Outlook, Outlook Express, and Office product lines. Throughout this chapter, I will be discussing ActiveX as it runs within a browser only.

ActiveX Controls

An ActiveX control is an executable program that can be automatically delivered over the Internet where it usually runs within a browser. Contrasted against Java applets, which are created in their own special language, ActiveX controls can be written in many different languages, including C++, Visual Basic, Visual C++, Delphi, Powersoft, Java, C-Sharp (C#), and Visual J++. And because ActiveX controls are based on the OLE specification, controls written in one language can be re-used within controls written in another language. ActiveX controls are compiled into fast 32-bit machine language for Windows platforms. This means they can run only on systems that work with the Win32 API and lose the portability advantaged gained by Java.

Since ActiveX controls are compiled programs originating from a variety of programming languages, they aren't limited to a basic set of routines. Besides being able to jazz up web pages and build sophisticated user forms, ActiveX controls can be any program they want to be. Complete spreadsheet and database programs are no problem. Local disk systems can be manipulated, connections can be established to other computers and networks, files transferred, and all of this is invisible to the user. It is this feature-rich openness that worries security experts. Every type of malicious code exploit that can be attempted with viruses, worms, and Trojans, can be accomplished with ActiveX.

When you accept a control for the first time, the control is downloaded to your computer and the appropriate registry entries are created. Controls are registered in the HKCR\CLSID subkey, and can also be found in HKLM\Software\Classes. ActiveX controls usually have the file extension, .OCX, which stands for OLE Control, but a control could have any extension. The typical Windows system has dozens of controls installed. Most are located in C:\%windir%\SYSTEM and C:\%windir%\Program Files\Common Files\Microsoft Shared, if you have MS Office installed. Controls downloaded and installed by Internet Explorer are usually located at C:\%windir%\Download Program Files.

Files in C:\%windir%\Download Program Files are specifically concealed by the newer versions of Windows and will not show up with a File Find or DIR command. But you can use Windows Explorer or the DOS Change Directory and find the hidden subdirectory.

TIP:   Internet Explorer 3.x stores ActiveX controls in C:\%windir%\OCCACHE.

ActiveX Scripting

Scripting languages, like VBScript, JScript, JavaScript, Python, PowerScript, Tck/Tk, and Perl, can be used within a web page to direct the functionality of an ActiveX control. ActiveX controls can be written to run differently based upon the parameters passed to it by the scripting language that calls it. For example, a web site can start the ActiveX downloading process as soon as the web page loads, or tell the control to manipulate different files based on end-user input.

Safe for scripting and initializing

ActiveX controls can be defined as Safe for Scripting and Safe for Initialization by the software publisher. By designating the control as safe, the vendor is saying that the control cannot be used maliciously and is safe to be manipulated by other scripting languages. Safe for Initialization means that no matter what values are passed to the control during its startup, it cannot do damage to a user's system. Safe for Scripting means that the control cannot be used maliciously no matter how its manipulated. Although each control has two safety settings, most of the popular press focuses on the Safe for Scripting moniker, even though they're referring to both. Controls that can create, read, or write files, or write to the registry are not considered explicitly safe, unless their actions are predetermined and specific.

Without this predefined safety check, a seemingly innocuous program could easily be used to do harm that the original publisher (programmer) did not intend. For example, a control could be made to function as a popup word processor that a user could write with and save notes. If marked Safe For Scripting, a malicious web page might be able to load the control, create and save new files, and use it to overwrite the user's startup files. There is much discussion within the security industry over this controversial setting. Particularly, how does a vendor guarantee his control to be bug free and not susceptible to maliciousness from other programs? There is no standard way for a vendor to test the safety of their code. As we will see later, it's difficult for a vendor to consider all the possibilities of their program's interactions.

Safe for Scripting or Initialization does not mean the control is safe for use. There might be a control that scrambles and deletes all your files when you execute it. As long as the result was not implemented by a script or initiated during startup by an unintended third party, it could still qualify for the Safe for Scripting setting. Obviously, this control would not be safe to have on your computer.

Differences Between ActiveX and Java

ActiveX is often thought of as a Microsoft Java clone. It isn't. Without the common goal of being optimized for Internet component downloading, the two platforms don't share much in common. Here are some key differences:

Activating ActiveX

Web developers include an <OBJECT> tag within their HMTL page (see Example 11-1) to automatically download a control to the browser, much as with a Java applet. The ID field defines the name used by any related scripting language that presents the control. The CLASSID is a globally unique identifier used to identify the control (something you'll need to become comfortable with to locate a specific control on your machine) and the CODEBASE contains file identification information (minimum version and location). HEIGHT and WIDTH tell the browser how many pixels tall and wide to make the displayed control. Other custom startup parameters, such as the background color, can be passed to the control as it starts.

Example 11-1: Example HTML page with ActiveX Control

<TITLE> Draw a Square </TITLE>
Here is a sample square from ActiveX:
HEIGHT="101" WIDTH="101"
<PARAM NAME="Version" VALUE=45445">
<PARAM NAME="ExtentX" VALUE="3001">
<PARAM NAME="ExtentY" VALUE="2445">

When you surf across a web page with a signed ActiveX control, the browser reviews CLASSID s stored in the registry to see if the control is already installed. If not, the web page's CODEBASE attribute tells the browser where the appropriate control can be found. If the browser still cannot find the control from the location specified by the CODEBASE attribute, it can try contacting one of several servers where signed controls are registered. The servers can be registered at HKLM\Software\Microsoft\Windows\CurrentVersion\Internet Settings\CodeBaseSearchPath. Normally, or will be stored as default locations. The server then checks a list of all controls and their CLASSIDs that have been registered with it and tells the browser where the control can be downloaded. This, of course, is invisible to the end user and happens in seconds.

Cabinet archival files

A single ActiveX control can be made up of dozens of files. Besides the OCX executable code, a control might depend on audio, video, and other support files to run. Basic HTML forces each file to be downloaded into a separate connection, wasting time and increasing the chance of error. When Microsoft needed a way to deliver all the necessary control files in one package, they extended an already existing file structure. Cabinet archival files (they have a .CAB extension) started being used by Microsoft in full force with the release of Windows 95. All the files within a cabinet file are first merged together to form one larger file, and then compressed. This results in better compression and faster downloading.

Cabinet files also contain the necessary information needed to install the control, such as .INF files and registry entries. Developers also have the option of including the necessary dependent files within the cabinet container, or having them downloaded as needed. For example, a user might download an ActiveX control that requires Visual Basic 5.0 support files to run. The cabinet file will determine if the appropriate files are already installed, and if not, download them from the developer's web site, or from Microsoft's web site.

TIP:   Cabinet files are used to package all types of Microsoft program files, not just controls.

Cabinet files can even contain separate executable code used in the initialization and installation process. This last point has been used to form malicious email exploits (covered in Chapter 12). Internet Explorer 3.0 was the first browser to accept cabinet files. Windows uses the ActiveX Setup Install control, C:\%windir%\SYSTEM\INSENG.DLL, to handle unpacking signed cabinet files and executing them. The control is use by Internet Explorer, Outlook, and other ActiveX-compatible programs.

ActiveX Security

Java's default security model runs untrusted code in a security sandbox. ActiveX's default model (see Figure 11-3 later in this chapter) doesn't run untrusted code, period! The defining question is how ActiveX determines what is untrusted code. In many cases, it doesn't, you do. When you download an ActiveX control, Internet Explorer checks for the existence of a digital signature to verify its authorship. Depending on the browser's security setting, you may then be asked (see Figure 11-1) to accept or deny the control's downloading and execution.

Figure 11-1. Internet Explorer ActiveX warning


As you are prompted to accept a new, signed control for the first time, the browser will also allow you to accept every control signed by the same author, if you check the Always trust content from box. If you do, future controls from the same author or vendor, now considered trusted publishers, will not result in additional notifications. They will download and execute without warning. This is a lot of trust to give a vendor, so give it with due consideration. Microsoft writes trusted publishers to the following registry keys:

A few sneaky controls have ignored the user's authority by directly modifying the registry to make themselves trusted publishers. After the user initially accepted the control, the control, unbeknownst to the user, makes its creator a trusted publisher. Then any control signed by the same vendor can download without further user notification. This type of predefined trust is also found on a lot of new computers. In an effort to provide better technical support, several leading vendors include controls and publishers on brand new PCs that are configured as trusted. Again, this is taking the decision of who to trust out of the hands of the user.

Figure 11-2. Unsigned control message


If a control is not signed, you are given the option of accepting or denying it (see Figure 11-2). Microsoft considers all unsigned controls as unsafe. While this can be true, many of the controls you will download are legitimate and safe, yet are unsigned. If you accept, the unsigned control runs and you will not be prompted again for the same control. If you deny the control, the code is not executed (although it has already been downloaded to a temporary file location).

With ActiveX, an author writes his program in any one of the dozens of accepted ActiveX languages, compiles it into 32-bit machine language and stores in an .OCX file. Microsoft then hopes developers will digitally sign their code before placing it on the Web, although this doesn't happen in many cases. Users download the ActiveX control and may be prompted by the browser to accept or deny the program. If accepted, the browser runs the control and it has full access to anything on your system that you have--sometimes more.

Figure 11-3. ActiveX development and security model


Microsoft's ActiveX security stands (or falls) on whether or not you, or your browser, accepts the code as trusted. It doesn't tell you what system resources the control will access or what it might do (as Java's new security model attempts to do). ActiveX's entire security scheme is based upon signed code, security zone policies, and end-user judgment. (See the ActiveX development and security model in Figure 11-3.)

Digital Signing and Certificates

Central to ActiveX's security (and to a lesser extent, Java) is the concept of digital signing. Digital signing is recognized by hundreds of software applications, including Microsoft's Internet Explorer, Outlook, Outlook Express, Office, and Netscape. Digital signatures allow a user to verify, prior to running executable code, that it came from the developer it says it came from; and that nobody else has modified the code. It doesn't guarantee who distributed it or where it ultimately came from. And it doesn't mean the code is bug free or not malicious. Digital signing only authenticates those who created or intended to distribute the code. The code can still be malicious or used maliciously. As has been the case in so many past incidents, malicious mobile code has been able to insert itself into other, supposedly trustworthy, code. If the original author doesn't recognize the infection, his code will still be digitally signed and electronically distributed as if it were safe.

There are several digital-signing platforms, including Microsoft's Authenticode, Netscape's Object Signing, Javasoft's Jar Signing, and Apple's Code Signing. Although based on a similar concept, they are not compatible. Developers are forced to make a decision they don't want to make. Either they direct their code-signing efforts toward one particular platform and thereby exclude using secure code on competing architectures, or they work harder fulfilling the code-signing requirements on multiple platforms. Programmers writing ActiveX controls will choose Microsoft's Authenticode initiative.

Digital authentication summary

Digital signing allows authors and users to verify (authenticate) that a particular piece of code hasn't been tampered with. Software developers wishing to digitally authenticate their code, have to put their finished code product through a series of additional steps, as shown in Figure 11-4. First, they write their program and apply a series of processes to digitally sign their code. The code is examined by a mathematical hash algorithm to produce a unique digital fingerprint. The author encrypts the digital fingerprint with his private key to create a digital signature. This signature will not be the same for any other vendor or any other piece of code. The digital signature is attached to the code, along with a public decrypting key, and a certificate verifying the decrypting key, and is placed on the Web. When a user downloads the signed code, it is placed into a temporary file (usually C:\%windir%\Temporary Internet Files). The control's certificate is inspected to see if it was granted by an authority the browser trusts. If so, the software vendor's certificate is used to verify the authenticity of the decrypting key. The browser then decrypts the digital signature with the decrypting key back into its hashed fingerprint. The code is rerun through the same hashing algorithm as the author performed and the two results are compared. If identical, the code is executed and run. If the two hash totals don't agree, then the code is considered unsigned. The end-user portion of this process is performed seamlessly by the browser.

Figure 11-4. Digital authenication summary


As you can see, a lot of examination goes into verifying signed code. If any of these processes fails, the code is discarded or the user is warned that the code is unsigned. Encryption is a crucial part of ensuring that the crucial parts of authentication cannot be faked.


Encryption, as explained in earlier chapters, is the process of taking a plain text message and scrambling it in such a way that it is not understandable during transport, and then converting it back to its original form for the intended recipient(s). A key is the character representation that can be mathematically applied to scramble or unscramble the message. A good key and encryption routine uses special mathematical properties to create the following characteristics in the encoded message:

A simple encryption example

A very simple encryption method might be subtracting one letter from any alphanumeric character in the message. Thus A becomes Z, B becomes A, C becomes B, and so forth. A message in its plain-text form might read, "The safe combination is 32-23-42." While encrypted it would read, "Sgd rzed bnlahmzshnm hr 31-22-41." Both parties of the intended communication would know to add one letter (the decryption key) to each character to unscramble. This is, of course, a very simple example that would not be used in real life. This type of encryption, where the same key is known to both parties, is called symmetric cryptography, or private key encryption.

TIP:   During the discussion on encryption I will frequently refer to encrypted messages. A message in cryptography means any type of content (executable code, text, graphic, sound, etc.) and not just printed text.

One of the critical problems in private key technology is how to transport the private key in a secure method to all the parties involved. There is the fear that during the transport of the private key it will somehow become compromised and make the encryption session unknowingly insecure. Also, private key encryption cannot prove who made a particular message (authentication). Since all of the involved parties use the same private key, any of them can forge a message from any other. Enter public key security.

Public key security

Central to any digital certificate scheme is the use of public key cryptography (see Figure 11-5), which uses two related keys for secure communications. In our case, keys are used to encrypt a message or create a digital signature. With this form of encryption, the originating party generates two keys: a private key and a public key. Only the originating party has and knows the master, private key. Everyone else can have the related public key that is common to all parties involved. Only the user(s) with the private key can create an encrypted message (in our case, a digital signature) that can be unencrypted with the related public key. Anyone with the public key can unscramble it. The public key will only unscramble messages signed with the related private key. The private key can create or read encrypted messages. Public keys can be used to make messages that only the private key owner can read. The official name for this type of system is asymmetric key pair.

Figure 11-5. Authentication with public key cryptography


This scheme allows the message source to be authenticated because the sender is the only one who can create the message. Second, since anyone who wants to read the message need only get a public key, it doesn't compromise the security of the private key. So far the legal status of digital signatures has not been thoroughly tested in the court system, although they are readily accepted by many authoritative regulatory bodies (GAO, UCC, NIST) as nonrepudiated evidence. Nonrepudiation is legalese for "You can't say it didn't come from you." Still, someone might be able to prove that their private key was compromised and subsequent messages were faked.

TIP:   Public key cryptography was introduced in 1976 by Whitfield Diffie and Martin Hellman.

Security experts are always concerned about malicious mobile code of the "Family & Friends" type. These can infect a person's computer and automatically send emails that appear as if they were sent by the sender. There are hundreds of attacks that do this. A "Family & Friends" malicious program could easily send email signed by a user's private key. For that reason, private keys should always be password protected, and stored in a secure location.


Signing content involves performing a quick mathematical check against a predefined area of the code. This is called hashing, fingerprinting, or message digesting. The hash calculation is done using a standard well-known formula (such as MD5 or SHS), which is difficult to reverse engineer and fake. That is, if someone finds out the hash total, it is difficult to reconstruct the message it was applied against; and it is difficult to manipulate the message in any way without a different hash result appearing. You can review the Message-Digesting-5 (MD5) algorithm in Internet RFC 1321 (

The result of the mathematical analysis is called a hash total, or digital fingerprint, and is encrypted using the author's private key and stored with the code. Later, when the file is sent, the same mathematical check is applied again and verified against the original hash total. As long as the message has not been tampered with, the hash results will always be the same. If the source and destination hash totals don't agree, the digital signature and related certificate are not authenticated. This check lets you know that the code has not been modified after the code was signed.

It's important to understand that although encryption is used to sign the hash fingerprint, the code itself is not encrypted. Encrypting the complete code would take lots of additional time without adding significant benefits. And for this reason, signed code can be exported outside the US without breaking exportation laws. If the code itself needs to be encrypted, it would have to be put through another set of cryptographic processes. Fortunately, both Java and ActiveX contain standard APIs for code encryption.

Certificates and certificate authorities

A document that guarantees that the public key was created by the person or company claiming to be its creator is called a certificate. A certificate does not identify who distributed the key or where it came from, only who generated the key. A certificate is unique per user (or company) or it can be unique per product. A message can be signed with multiple certificates. When you download code, your browser looks for the presence of a digital signature and its public certificate. With its default security settings, Internet Explorer will refuse to automatically execute unsigned ActiveX. Both Netscape and Internet Explorer force unsigned applets to run in the security sandbox.

Certificates relied upon by the public are issued by independent third parties known as Certificate Authorities (CA), who play the most important part in the public key infrastructure. CA's ultimately attest that they have verified the identity of the certificate holder. Depending on the attestation process and how involved it is, the resulting certificate can be designated as Class 1, 2, or 3. Class 1 certificates are given with minimal credential checking, maybe only verifying the requestor's email address. Class 3 certificates, on the other hand, require substantial verification. The requestor has a lengthy application process, must provide irrefutable evidence of identity, and may even need to make a personal appearance. Consequentially, Class 3 certificates provide more reliance than a Class 1 certificate. Most CA's require a Class 3 verification process before they will grant a digital certificate to a software developer.

Digital certificates issued to software publishers are signed with the CA's own private key (to authenticate the CA) and contain at least the following: owner's public key, owner's name, expiration date of the certificate, name of the CA, serial number of the certificate, and the digital signature of the CA. Dozens of companies offer digital certificates. VeriSign ( is currently considered the industry leader in digital certificates, but other companies (such as Equifax Secure ( and GlobalSign ( are growing. Certificate authorities can allow other third-party companies to assign certificates on its behalf. The highest governing certificate authority along the chain of trust is known as the trusted root authority.

Digital certificate incompatibilities

In order for your browser to automatically trust signed code, the certificate must have been created by certificate authority your browser already trusts. Digital certificates and IDs, although based on x.509 standards, are not usually compatible between different code-signing products. It means that signed code meant for Internet Explorer and Netscape browsers will often have to have two versions, each signed by a separate certificate. And of course, the developer has to buy a different certificate to support each platform. A few companies, like Thawte (, recently purchased by VeriSign, offer certificates compatible for multiple code-signing platforms.

Certificate granting process

Certificates are granted the following way: a programmer generates a key pair, public and private, as the initial part of the certification process and sends the public key (as proof of the private key) to CA along with a proof of identification. The CA verifies the identifying information and creates, using its own private key, a certificate (also called the digital ID) that the programmer can attach to his program. Typically, this process takes three to five days. The certificate is relied upon by end users as evidence that the public key used to decrypt an encrypted message was created by the private key owner. Without a mechanism to attest to the validity of the public key, malicious parties could distribute code with their own keys and claim to be a particular vendor.

Inherently, you must trust the CA who issues the digital certificate to do the job of validation, or else you shouldn't trust the certificate. In many cases, a programmer's public key is posted at the CA so that anyone getting an encrypted message can obtain the public key and extract the plain text contents. With browsers and downloaded code, the owner's public key is usually transmitted with the certificate to decode the digital signature. When the public key is not transmitted with the signed code, the browser will attempt to locate the author's public key at the CA's web site.

Trusting the trust giver

Signed code is a chain of trust. The certificate says you can trust that the code publisher's public key is authentic. In trusting the certificate you are saying that you trust (or in reality, your browser trusts) the certificate authority to verify the publisher's identity. You are trusting the developer not to program his software to do anything you don't want it to do. You are trusting that the developer took reasonable steps to protect his private key. You are trusting that the developer's software was not infected with malicious code when he signed. You must trust that cryptology experts created hashing and public key algorithms that can't be faked. It is all a matter of trust, and like any chain, it is only as strong as its weakest link. Thus, when you hear the phrase trusted code, it often means digitally signed code attested by a certificate.

Internet Explorer will list at least four types of certificates:

Personal certificates are for use by individual users to authenticate the actions or coding of one user or developer. Personal certificates can also be used to authenticate a user to a secured web site or for use with secure email. Server certificates allow web servers to operate in secure mode, encrypting information between the browser and server. This chapter is concerned with the next two types. Software publisher certificates (listed under Other People in Internet Explorer) are the certificates of developers the user or browser has designated as trusted (see Figure 11-6). Signed code arriving from one of these developers will automatically execute in most cases.

Figure 11-6. Example list of software publisher certificates trusted by Internet Explorer


Certificate authorities certificates are the CAs the user or browser will automatically trust to attest the validity of the other three types of certificates. When you download signed code and its digital certificate, Internet Explorer immediately examines the certificate and verifies that the certificate authority is one whom it trusts. If Internet Explorer does not have the CA's public key, it will prompt the user on whether they want to accept a new CA. If so, the browser contacts the CA and installs the CA's public key. In practice, dozens of CA's are preinstalled as a trusted root CA by Microsoft browsers. The public CA certificates contain an expiration date. Earlier browser versions had trust certificates that expired on January 1, 2000, but most new browsers contain trust certificates with expiration dates (e.g., 2010) that should outlive the browser.

Figure 11-7. Example certificate


If you want to see the list of CA's Internet Explorer trusts, choose ToolsInternet OptionsContentCertificates and choose either the Intermediate Certification Authority or Trusted Root Certification Authorities (see Figure 11-7 for an example of a CA certificate).


Digital certificates, as recognized by today's browsers, follow the CCITT X.509 version 3 standard. Most certificates have an expiration date and can be revoked prior to its expiration date by the issuing certificate authority. Revocation can be started because the developer thinks the certificate was compromised or initiated by the CA because the holder violated terms of the license agreement. CAs publish lists of revoked certificates that users can compare against any suspected public certificate they are inspecting. This process is becoming more automated, but isn't always reliable. Fortunately, there have been very few revocations.

Always trusting a certificate

If you trust a particular vendor to always deliver trusted code, you can accept the vendor's public key with your browser and any code signed with the vendor's private key will be accepted for the duration of the certificate. The first time you accept a signed control from a particular vendor, Internet Explorer and Netscape will offer the opportunity to always accept any signed content from that vendor. Some versions of Internet Explorer allow you to accept any object signed by a particular CA. Be careful, as this is a lot of trust to give any vendor or CA.


Microsoft's initiative for digitally signing code is known as Authenticode? and is available with Internet Explorer 3.x and above. Authenticode is based on a 128-bit cryptographic system involving X.509 (certificate specification), PKCS #7 (encrypted key specification), SHA and MD5 hash algorithms, and PKCS #10 (certificate request formats). So although Authenticode is proprietary, it is based on popular industry-accepted technology. Authenticode can be used to sign any 32-bit .EXE (PE files), .DLL, .CAT, .CTL, .OCX, .CAB, and .CLASS file. Figure 11-8 displays a message in Internet Explorer alerting the user about an Authenticode validated control.

TIP:   Authenticode does not sign Internet scripting language files

Figure 11-8. Code signed by a valid Authenticode certificate


In order to digitally sign a control, all the necessary files must be merged into one .CAB file and then signed as a whole. Individual signing of files within a single cabinet file is not supported. This makes authentication easier to manage. If one file within the cab is changed, the whole cab must be resigned. In this way, the author always reestablishes his ownership of the whole package, and not just a part of it.

Authenticode digital certificates (Class 3 Commercial Software Publisher Digital ID) routinely cost $100-$400 per year and are assigned to corporations who can prove their identity. Companies obtaining a commercial certificate promise never to intentionally distribute malicious code. Authenticode's end-user license (EULA) contains Microsoft's standard boilerplate language absolving Microsoft of liability for any damage caused by the use of Authenticode.

Individual certificates (usually Class 2 Digital IDs) for small software developers can be had for less money per year and the user's promise to take reasonable steps to protect the private key. Unfortunately, many CAs (including, VeriSign) have either discontinued Class 2 IDs for Authenticode or never offered them because the cost to verify the developer's identity outweighed the revenue. Personally, I feel this significantly weakens Microsoft's code signing security model. ActiveX depends on Authenticode for security. By pricing most digital certificates at several hundred dollars per year, most small developers and home programmers will not sign their controls. This has led, and will lead, to substantially more unsigned code than signed code on the Web. Users will become accustomed to downloaded controls being unsigned, ignore the cautionary warnings, and thus weaken the overall model.

Java, Authenticode, and Internet Explorer

Authenticode is only supported by Internet Explorer, or in Netscape by using an Authenticode plug-in. Most objects signed by JavaSoft or Netscape technologies will run in Internet Explorer, but won't be interpreted as signed. Authenticated Java applets can be downloaded in Internet Explorer as long as they are part of a signed .CAB file. During the signing process, the .CAB specifies any special resources its wants outside the normal Java sandbox. While being downloaded, Internet Explorer examines the signature, verifies it, and then compares any requests for resources outside of the sandbox to what is allowed in the Internet security zone. If the requests are predefined as allowable, the applet will launch without any notification to the user. If the applet requests access permissions outside the predefined set, the user will be prompted to allow or deny them.


Digital IDs rely on encryption, and any encryption scheme can be cracked in time. For this reason, digital IDs have an expiration period to remain trustworthy. Authenticode digital IDs are only good for one year. This creates a problem because most software code is used for a longer period of time. Software developers can choose to resign their code every year, or as they should, timestamp their code. When a software author signs new code, the hash result is sent to VeriSign ( and timestamped. The hash signature is forever documented as having been valid during the digital signing process. If users download expired, timestamped code, they will see that the digital signature is valid even though the certificate has expired. Expired, timestamped code should be trusted. Expired, untimestamped code should not be given the same amount of trust.

TIP:   VeriSign is the only CA offering Authenticode timestamping.

Signed Code in Action

The treatment of executable code by Internet Explorer depends on the type: ActiveX or Java. Microsoft gives any ActiveX control, signed or allowed by the user, complete access to the computer system. Users determine whether or not a signed or unsigned ActiveX object can be automatically executed without end-user intervention by defining allowed behaviors per security zone. By default, unsigned ActiveX objects cannot automatically run in any Internet Explorer security zone. In high, medium, and medium-low zones, unsigned ActiveX objects are not allowed to run and are ignored. In the lowest setting, usually reserved for the trusted sites zone, unsigned ActiveX controls will still prompt the user to approve before running (not always so in earlier versions of Internet Explorer).

With Java, unsigned code will typically either not be allowed to run or be forced to run in a limited security sandbox. Internet Explorer allows users to predefine the level of default trust and access to local system resources to be given to authenticated Java code. Internet Explorer allows Java security policy to be configured in a user-friendly menu (ToolsInternet OptionsSecurityCustom LevelJava PermissionsCustomJava Custom SettingsEdit Permissions).

When incoming signed Java code is recognized by the browser, Internet Explorer immediately inspects the signed .CAB file for requested permissions. If the requested permissions don't exceed those predefined for the particular zone, the applet is allowed to run without user intervention. If the applet requests access beyond the predefined options, the user will be prompted to allow or deny the additional access. Since Internet Explorer does this during the initial download of the code, the user knows immediately what the code is capable of requesting and the approval process only done once.

Internet Explorer and Authenticoded Java

When Internet Explorer downloads a signed applet requesting permissions beyond those allowed in the security zone and the browser has been instructed to prompt the user for additional access requests, the user will be given the opportunity to approve or deny the additional permissions (see Figure 11-9 and Figure 11-10).

Figure 11-9. Java applet requesting full permissions to the local system


Figure 11-9 shows a Java applet requesting full permissions to the local file system in Internet Explorer. In the example, the developer's certificate has expired. Although Internet Explorer considers the expired certificate as untrusted, most people consider expired certificates as somewhat trustable. At some previous point, the developer of this application held a valid certificate, and since then the code has not been modified. If the code had been modified since then, Internet Explorer would consider the digital certificate as invalid, and say so.

Figure 11-10. Signed applet asking for additional permissions


In both Figure 11-9 and Figure 11-10, the applets are asking for additional specific permissions beyond those allowed in the current security zone. Had Java permissions been set to Disable instead of Prompt, the applets' additional requests would have been denied without user involvement. Many applets are not given enough error-checking routines and the denied access will result in incomplete web pages, blank gray boxes, and other unpredictable, minor consequences.

Additionally, applets wishing to access the local file system in Windows must use Microsoft-proprietary Java classes. Meaning that although an applet written to run in the sandbox can easily be cross-platform, applets wishing to exceed default limitations must be specifically written for the Microsoft platform (causing problems on other platforms). This type of forced exclusionary coding behavior has long been debated between JavaSoft and Microsoft.

ActiveX Security Criticisms

ActiveX security, or the lack of security, has more than its fair share of critics.

ActiveX Has No Sandbox

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.

Safe for Scripting Vulnerability

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

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 Adobe's Acrobat Reader? 4.0, are susceptible. The Acrobat Reader control (PDF.OCX) allows users to view .PDF files within a browser, and is available for Internet Explorer versions 3.0 and above. It is such a great, free tool that it is the rare browser that doesn't have it installed, and thus, most browsers are susceptible to buffer overflows. A demonstration exploit that uses Acrobat's control to run the Windows calculator can be viewed at It could have called FORMAT.EXE just as easily.

Users Can't Be Trusted

Critics correctly point out that users can't be trusted. They execute unknown, untrusted code all the time. There is hardly a computer user I know who doesn't execute the latest joke file sent to them from a friend. Even a warning message isn't enough to make most users pay attention. This is the whole reason macro viruses are the number one type of malicious code. As ActiveX becomes more popular, there will be more and more web pages and emails with embedded controls. Most of those will probably not be digitally signed. After the user gets dozens of download warnings without any problems, the user will just start hitting the OK button without really considering the potential consequences.

Most users don't want the responsibility of determining trust. They want to compute and surf the Web. They don't want to learn about malicious mobile code and the intricacies of browser security. Microsoft addresses some of this argument by accepting signed controls, and denying unsigned controls, by default. But even that isn't completely safe. It is not impossible to think that a strongly motivated individual or group could obtain a digital signature and distribute a malicious control. There have been dozens of cases where real companies used unethical code against unsuspecting users to fraudulently steal money, damage computers, or collect personal information.

Authenticity Doesn't Prevent Tampering

A malicious hacker could take a commercial company's legitimate, trusted control, and use it to modify the computer of someone surfing their web page. For example, many computer vendors install remote access support controls, marked safe for scripting, to help technical support provide help to customers. A hacker could utilize this control to remotely control their victim's PC. Microsoft is working on a system where controls can be designed so they can't be borrowed from other web sites, but so far this solution is not in place.

Authenticode Is Only as Strong as Its Private Keys

Public key encryption schemes fail if the private key is compromised. Authenticode makes an individual or company promise to take the appropriate steps to safeguard their private keys. Many critics feel that lax security exists in most companies, and they doubt that private keys are as well guarded as they should be. Remote administration Trojans or email viruses are easily capable of stealing private keys, and one such attack was successfully demonstrated.

Guarding Private Keys

Microsoft's own private keys are stored in a hardware-based crypto box, called the BBN SafeKeyper, and stored in a guarded steel and concrete bunker. The crypto box is designed to destroy itself rather than reveal the keys, if compromised. A variation of the BBN SafeKeyper is used to house nuclear missile launch codes on American submarines.

Weak Revocation

Once a control is accepted and downloaded, it is very hard to revoke. If a trusted control was found to have a significant security hole, there would be no automated way to replace the control or take away its trust. Even if the trusted control's digital certificate is revoked, like in the case of the Exploder control, once the control has been trusted, its right to run cannot be easily taken away. Several other revocation weaknesses exist. By default revocation is not turned on in Internet Explorer. Even when turned on, Internet Explorer only checks a certificate's revocation status during the initial download. Lastly, software authentication certificates issued by VeriSign, used by many leading ActiveX developers, are not checked for revocation ever.

This last point became more significant on March 22, 2001, when Microsoft revealed that VeriSign accidentally gave two Microsoft Corporation digital certificates to unknown persons posing as Microsoft employees on January 29 and 30, 2001. If used inappropriately, these false certificates would allow MMC to appear as Microsoft trusted code. Because VeriSign code-signing certificates cannot be automatically revoked, Microsoft had to release a security update eliminating the vulnerability and warn its customers. This situation underscored a weakness long espoused by critics.

TIP:   Any digital-signing initiative is exposed to the same risk if a certificate is issued in error.

No Granularity

Another big problem ActiveX has is no granularity. Unlike Java, where you can customize what a specific resources an applet can utilize, ActiveX is an all or nothing proposition. Once you accept the control, it has the same access to your system as you do. If it decides it wants to delete every file on your hard drive there isn't much you can do after you've accepted it. You can't decide to allow a control just access to a certain file, or limit it to a specific computer resource. If you or your browser has access, the control has access.

ActiveX Controls Are Registered to the Machine

When controls are downloaded they are registered to the local machine by default (HKCR or HKLM), meaning that on a shared machine, controls and security holes may exist that the current user knows nothing about.

No Easy Way to See All Controls

Although you can easily view some of the downloaded controls within the browser, there is no easy way to see all ActiveX controls installed on a particular machine. If you don't mind a little hard work, you can search the registry or use Microsoft's OLE Viewer tool. I cover both of these methods later on.

Security in Browser

Lastly, although ActiveX can and does run outside the browser environment, almost all ActiveX security is configured through Internet Explorer.

Malicious ActiveX Examples

Since an ActiveX control can do almost anything it wants, it's almost useless to classify types of exploits. If you allow a control to execute on your system, it has full access to your system. Known ActiveX vulnerabilities are spread nearly even between unsigned controls that should not be trusted and exploits of previously trusted controls.


Fred McLain, currently a Java product development manager at Appworx Inc., is the infamous creator of malicious demonstration ActiveX controls, Exploder and Runner. His web page at contains a Frequently Asked Questions document on his Exploder control, as well as links to download both examples.

Released in 1996, the Exploder control shuts down Windows 95 machines and powers them off (if you have the Advance Power Management feature in your BIOS). It is no different than if you chose Shutdown from your Start button on the taskbar. After making his malicious control, Fred contacted VeriSign, Microsoft's authenticated certificate authority, and purchased an Authenticode digital signature. At the time of release, Internet Explorer 3.x would run any signed control without prompting the user. So, if you were lucky enough to browse across Fred's web site or anyone else's who borrowed the control, you would have about 10 seconds before your system shut down, and losing any unsaved data.

Fred and his creation immediately made headlines around the world, and he was contacted by both Microsoft and VeriSign. VeriSign revoked his digital signature because Fred broke the Authenticode licensing agreement by intentionally designing his control to be malicious. Fred contacted a lawyer to represent his case, but eventually withdrew his signed control to ward off potential lawsuits. But by then, Fred had proven his point. A hacker with malicious intent could easily obtain a digital signature, sign the control, and release it into the wild. Although Microsoft correctly stated that ActiveX's security worked as designed, Exploder ended up strengthening both ActiveX's security model and VeriSign's digital certification process. Today, with default security enabled, Internet Explorer 4.x and 5.x will not download the malicious control. Even at the lowest security setting, Internet Explorer 5.x warns you that the control contains unsafe content.


Runner is another of Fred McLain's malicious ActiveX creations. It is an unsigned control that simply runs a copy of COMMAND.COM, and opens up a DOS window. Fred programmed this control to demonstrate again how an ActiveX control can do anything it wants. He could have just as easily made it format the user's hard drive or send files to his web site. Runner was never distributed with an Authenticode signature and will not be run by Internet Explorer with default security enabled.

InfoSpace Compromise

In September 1996, an Internet company, called Infospace, ( posted an ActiveX control (labeled Quick Search) on the Lycos search engine site, which bypassed one of Authenticode's security checking mechanisms. The Lycos control was written to allow the seamless downloading of advertising to a user's browser while they were using the search engine, but it also did an unwarranted modification to bypass future warning messages.

Specifically, if the user allowed the signed control to download and run the first time, it would transparently modify the computer's Windows registry database so that it made Infospace a trusted publisher. Once this was done, Infospace could download any control to a user's system without further user notification. After the security exploit was published, Infospace's CEO stated that the misguided feature was simply a programming bug, and the control was fixed. Regardless of Infospace's original intentions, this control took the decision of who to permanently trust out of the hands of the user. Critics of ActiveX's security model consider this exploit to be an example of the greatest weakness in allowing trusted code to do anything it wants. They feel running all code in a protective sandbox is a better default option. That way, when code unintentionally messes up, there is a safety net in place.

Quicken Exploit

Germany's famous hacking group, Computer Chaos Club, demonstrated on live television in February 1997, an unsigned ActiveX control that would look for the presence of the popular personal finance program, Quicken?. If found, the control would check to see if the electronic banking feature was used. It then manipulated Quicken data files so the feature would automatically transfer money into CCC's bank account the next time a user initiated a banking transaction. Although the demonstration program worked, it required that someone go around Microsoft's default security settings to accept the unsigned control. Intuit, the company that writes Quicken, recommended that users concerned about this type of exploit disable ActiveX. Later on, additional features were implemented in Quicken to make CCC's type of hack more difficult.

Microsoft's Not Safe for Scripting Controls

Internet Explorer allows the activation (scripting) of ActiveX controls marked Safe for Scripting. Over the years, Microsoft and other vendors have released ActiveX controls that should not have been marked Safe for Scripting. Part of the problem is Microsoft doesn't have a standardized process for determining whether or not a control is safe to script. Hackers have used that to their advantage and discovered many controls that could be used maliciously. Security watchdog, Richard Smith, has an interrogating web page ( that will check your browser for the presence of many of these holes and tell you how to fix it.

Norton Utilities exploit

In April 1997, it was found that systems using Norton Utilities 2.0 for Windows 95 and Internet Explorer were vulnerable to a new type of attack. Symantec's Norton Utilities installed an ActiveX control called TUNEOCX.OCX and marked it as "Safe for Scripting". As part of Norton's System Genie? toolset, TUNEOCX had the ability to start a second program to call any system command that might be necessary to troubleshoot the system, including FORMAT, FDISK, and FTP. A malicious web site could include a script language command that used TUNEOCX.OCX to run any external command. The hacker site, for example, could copy files off a user's hard drive and then format the drive, maybe adding a delaying component to avoid suspicion. Symantec released a fix soon after the bug's discovery, but it pointed out the potential security holes that could be found because of unintentional code interaction.

Help desk controls

Several leading personal computer vendors ship their PCs with potentially dangerous scriptable controls. Richard Smith discussed his findings about HP Pavilion and Compaq Presario computers with several newsgroups in July 1999. He discovered that Pavilion systems were shipped with two unsafe ActiveX controls as part of HP's system diagnostic package, SystemWizard. One of the controls, called Launch, would run any Windows or DOS command passed to it by a scripting language. Thus, if a user went over the wrong web site, files could be deleted, hard drives formatted, and files copied. Another control, RegObj, could modify the registry. Both of these tools were designed to allow HP Help Desk support to help customers troubleshoot and fix problems. Unfortunately, both controls were marked as Safe for Scripting, when obviously, they should not have been. Smith found a similar hole in Compaq Presario computers. In this instance, Compaq included controls and applets, and made itself a trusted publisher. The diagnostic applets, which could launch external programs, would run outside the security sandbox.

DHTML edit vulnerability

In April 1999, Microsoft released a patch (see Microsoft Knowledge Base Article Q226326) to close a hole created by a new control released in Internet Explorer 5 (and downloadable in version 4.x). Microsoft's DHTML Edit control was marked Safe for Scripting, and allowed users to edit HTML text to see how it would look in a browser. The file, DHTMLED.OCX is stored in the subdirectory C:\Program Files\Common Files\Microsoft Shared\Triedit. Unfortunately, malicious scripts could download virtually any file on a user's system as long as it knew its name and location. In addition, the control could be used to trick users into typing sensitive data that could then be copied. Microsoft's patch worked by modifying the control to only load data that was in the web site's own domain. No customers were reportedly affected before the hole was closed.


Microsoft found another of its own vulnerabilities in a scriptable control called Taskpads. Taskpads was shipped in the Windows 98 Resource Kit and BackOffice Resource Kit 4.0. It allowed users to view and run Windows management tools through an HTML page. Like all the other Safe for Scripting mistakes I've reviewed, this allowed a malicious web site to write an HTML page that could invoke the control and cause damage. Since the Taskpad's functionality was not commonly used, Microsoft decided to remove its functionality all together with a patch (see Microsoft Knowledge Base Article Q218619).

Scriptlet.typlib and Eyedog exploits

Two infamous Microsoft browser holes, Scriptlet.typlib and Eyedog, exploit built-in Microsoft controls. Although not related, both were discovered and patched at the same time. The Scriptlet.typlib control is supposed to be used by developers to generate type libraries for Windows script components. Type libraries can be used by software development tools, like Microsoft Visual InterDev, to provide additional functionality. Unfortunately, because the control was marked Safe for Scripting, it could be used to change or delete files on a user's system. This exploit has successfully been used by malicious worms, including BubbleBoy and Kak. Microsoft patched the ActiveX control to remove the Safe for Scripting setting. The Eyedog control (EYEDOG.OCX) is used by troubleshooting utilities to gather information on the user's computer, such as username, hardware settings, and registry settings. This queried information could be passed back to a malicious web site and then used against the user. Microsoft's patch disabled the ability for Eyedog to be called from within a browser.

Office 2000 UA control

In another Safe for Scripting blunder, Microsoft unfortunately allowed the UA control (OUACTRL.OCX) shipped with Office 2000 (and related 2000 Applications, such as PhotoDraw, FrontPage, and Project) to be used maliciously. Included to allow "Show Me" help tutorials, the control has the ability to interact with the system, type in keystrokes, choose software options, etc. As a trusted, signed control, it could be scripted to accomplish almost anything the malicious hacker wants. Microsoft posted a patch to eliminate this vulnerability in May 2000.

Active Setup control

The Active Setup control allows Microsoft-signed .CAB files to be automatically downloaded and installed on a user's computer without intervention. The slight flaw that it contains is the ability to use script files to direct the destination download directory. A malicious hacker could construct a web page that downloaded a legitimately signed Microsoft control, but force it to download over other system files. This could leave the user's computer unusable. Of course, Windows ME and 2000, and their file protection mechanisms, would prevent such an attack from being successful.

Windows 2000 Sysmon Buffer Overflow

Unpatched versions of Windows 2000 contain a control, SYSMON.OCX, which contains an unchecked exploitable buffer. Announced in November 2000, this hole, like any other buffer overflow, could allow a malicious web page complete access to a Windows 2000. Sysmon, or system monitor, is used to measure and record system performance. It can be accessed in Windows 2000 by StartSettings Administrative ToolsPerformance Logs and Alerts. Microsoft released a patch in December 2000 to close the hole. In their announcement (Microsoft Security Bulletin MS00-085), Microsoft postulated that buffer overflow conditions compromise two-thirds to three-fourths of all security vulnerabilities.

Detecting Malicious ActiveX Controls

Your best hope for detecting malicious ActiveX controls is to use an antivirus scanner or software that scans incoming Internet traffic.

Disable Internet access
Disable Internet access to prevent possible further damage.

Use malicious code scanners and firewalls
Most antivirus programs and the more sophisticated firewalls can scan for malicious controls when they are being launched or downloaded. Figure 11-11 shows an antivirus scanning program catching a malicious control.

Figure 11-11. Network Associate's McAfee VShield in action


Unfortunately, antivirus scanners must know about the malicious code to catch it. New ways of compromising systems are being developed every day. So, while a good antivirus scanner that detects all malicious mobile code is a great defense, it isn't foolproof.

Removing and Preventing Malicious Active Controls

This section discusses several things you can do to remove and minimize the risk from malicious ActiveX controls. These items listed were covered in Chapter 10, and aren't covered in detail here:

The following sections cover further items in more detail.

Run Only Trusted Code

Running only the code you trust is a significant step in reducing your exposure to malicious mobile code. In the theoretical world of ActiveX, this means only running digitally signed code. With the Internet zone's default security set, this is automatic. At a low setting, you will be prompted if you want to run unsigned code. With any other setting, unsigned code is discarded without any user notification.

Unfortunately, trusted and signed code fails the digital certification process all the time. Sometimes it can be something as little as web site name change (which is stored in the certificate), or an expired certificate. Most controls aren't signed at all (see Figure 11-12). They come from legitimate vendors and are safe to use, but for whatever reason, the software programmers didn't go through with the extra effort and money necessary to digitally sign the code. Thus, it is up to the user whether to accept the unauthenticated code, or not. This is ActiveX's biggest weakness. Unless you have the time and are capable enough to examine the source code yourself, you are taking a leap of faith when you accept unsigned code. You should only take the leap for vendors whom you trust. You should rarely trust noncommercial vendors. In environments where security is a must, you shouldn't run unsigned code.

Figure 11-12. VeriSign does not have a digital ID on file for this control


Network administrators can use the registry or Internet Explorer's Administration Kit (IEAK, briefly covered in Chapter 9), to set a list of approved controls. No other controls can be installed, or executed. Approved controls are stored by their CLASSIDs at HKCR\Software\Policies\Microsoft\windows\CurrentVersion\Internet Settings\Allowed Controls.

Kill Bit Setting

Administrators and users can set a kill bit flag in the registry to make Internet Explorer not load specific controls. In order to do so the control's CLASSID must be known. Then the following registry key must be located or created: HKLM\Software\Microsoft\Internet Explorer\ActiveX Compatability\{CLASSID}. Locate the Compatibility Flag key. By default, it can be several values. Setting it to 400 will instruct Internet Explorer not to load the control. This is a good way for administrators to prevent known controls from running if they've had a problem with them previously.

The kill bit only works within Internet Explorer, and thus some controls can bypass the settings. For example, I set the kill bit on Adobe's Acrobat ActiveX control. When I clicked on a .PDF document in Internet Explorer, the control was not launched. However, I downloaded the same .PDF document to my hard drive, and clicked on it in Internet Explorer. Explorer automatically loaded Windows Explorer to handle the local file, which then loaded Acrobat and displayed the .PDF document. This just reenforces one of ActiveX's criticisms about security being handled by the browser.

Examine Certificates

Most of the time, I readily accept signed code without hesitation. But if you suspect a digital ID has been tampered with or you don't fully trust the vendor, carefully inspect the certificate during download. When you download a new, signed control, Internet Explorer will display the control's certificate and prompt you to accept it (unless you've already told it to automatically download all controls from a previously trusted publisher). The Acceptance dialog box contains links to the publisher's certificate. Click on the name of the software publisher to view the author's certificate and then choose Details (see Figure 11-13) to reveal more information. The certificate contains the author's name, the control's name, the CA's name, the certificate's expiration date, and over a dozen other details that attest to the author's identity.

Figure 11-13. Certificate details


You can save the certificate for later inspection by choosing the Copy to File button in Figure 11-13. This starts Microsoft's Certificate Manager Export wizard. You will be prompted with a couple options, including where to save the file. The file will be encrypted and have a .CER extension. When you click on the saved file with Explorer, it will be opened by Microsoft's CRYPTEXT.DLL application. The certificate will appear in its original form for inspection. It is important to note that if you do not choose the save a copy of the certificate to disk during the initial certificate viewing, it will be difficult to resurrect later.

WARNING:   Microsoft explicitly prevents certificate files from being sent in Outlook with the latest patches installed. This is because they fear a malicious hacker could send a .CER file to a user, who could then unsuspectingly install it (the user would have to be faked into accepting it). Once installed, any program from the malicious hacker would be automatically downloaded and executed.

Configure ActiveX Browser Security

There are five security settings related to ActiveX controls under ToolsInternet OptionsSecurityCustomActiveX controls and plug-ins:

If your company needs absolute security, disable all ActiveX options. This will require a custom security setting in the appropriate zone. With Internet Explorer 5.x, the default Internet security zone is set to Medium. Medium security disables downloading unsigned controls and disables scripting of controls not marked as safe. Medium security is a good level for most end-user PCs to have, except that I like to have the option of choosing whether to accept or deny unsigned controls. The Internet is full of legitimate unsigned controls, and although I don't necessarily run them, I do like knowing when a particular web page tries to initiate an unsigned control on my system. If I am not warned, then I can't consider the validity of the request. And in some cases, where I have complete trust in the vendor's site, I will accept and run an unsigned control. Table 11-1 is a security matrix showing the relationships between Internet Explorer's different security settings and my custom recommendations. Normal end users without an understanding of ActiveX security and risks should have their security settings set to Medium or High.

Table 11-1: Internet Explorer 5.x settings related to ActiveX

ActiveX security item description

Security settings



Medium Low


My Custom

Download signed ActiveX controls






Download unsigned ActiveX controls






Initialize and script ActiveX controls not marked as safe






Run ActiveX controls and plug-ins






Script ActiveX controls marked safe for scripting






TIP:   After coming to grips with the fact that few ActiveX controls can ever be completely safe, Microsoft defaulted Internet Explorer 6.0's Restricted zone with Script ActiveX controls marked safe for scripting disabled.

Most options are self-explanatory, but some users get confused about the difference between the options controlling downloading and those that control the running of ActiveX controls. If you disable running ActiveX controls and plug-ins, your browser will not run any controls or plug-ins, even if they are already downloaded and trusted. The download security items are only concerned with whether or not to download, and they are not involved in the decision of whether to launch ActiveX controls. If enabled, all ActiveX controls are downloaded to a temporary directory, even before being reviewed for a digital signature. However, if you are want to disable ActiveX controls, make sure to disable the downloading of them as well. If a malicious control was to be placed in the temporary directory, there is a small risk that a hacker could execute the downloaded control via some other method. Figure 11-14 shows the warning Internet Explorer will display when a plug-in or control is attempting to download and security is set to High.

Figure 11-14. Internet Explorer warning when a plug-in or control is attempting to download


Remove Unnecessary Controls

Over a period of time, any browser will become a repository for unused controls. Most are from one time-visited web sites to which the user will never return. Use ToolsInternet OptionsSettingsView Objects to view the controls and applets downloaded and trusted by your browser. You can right-click any object to get more details. The CODEBASE field will often tell you where the control came from. You can remove any objects you are sure you are not using or you don't trust. Although there have been security risks involving installed Microsoft controls, deleting them could produce functionality problems within Windows, Internet Explorer, and certain web pages. You are better off leaving them, unless you need absolute security. In Figure 11-15 example, the NFL.COM control was left installed well after I visited the web site to follow a playoff game. I don't plan to return to the site, so it should be removed.

Figure 11-15. Installed controls


To remove an ActiveX control, right-click the object and choose Remove. Alternately, you can use StartControl PanelAdd/Remove Programs. Microsoft prefers if you attempt this method first. It will attempt to remove registry entries and files. You can also delete any .OCX file using Internet Explorer or Find File. As shown in Figure 11-16, you can choose FileProperties to see more details on any control to help with your removal decision.

Figure 11-16. Properties of a control


Reappearing controls

Some deleted controls can reappear without warning, if you selected the Always Trust Content From This Vendor option during installation. Since the vendor's certificate is still trusted, if you visit a site containing one of the deleted controls from a trusted vendor, it will automatically download again. In these cases, you would also have to remove the trust given the publisher by choosing ToolsInternet Options ContentPublishers, and selecting the appropriate trust relationship, and then choosing Remove.

Error messages while removing controls

Often, if you try to delete an ActiveX control, you will get an error message preventing removal because the control is in use by Internet Explorer or Active Desktop. If this occurs, close Internet Explorer, disable Active Desktop (if enabled), reboot Windows, and try again.

Viewing and removing all controls

The controls you will see listed in Internet Explorer are just the controls downloaded by the browser and installed in the default downloaded program folder. The list doesn't include ActiveX controls installed by other software and mechanisms. If you want to view and audit all controls, you can search the registry under HKEY_CLASSES_ROOT\CLSID, search for all files with an .OCX extension, or download Microsoft's free OLE Viewer? (OLEVIEW.EXE). For example, Internet Explorer listed 14 ActiveX objects on my test machine. Searching for files with the .OCX extensions, I found 61 controls, most of which were in the C:\Windows\System and under C:\Program Files folders.

Using OLE Viewer, I found hundreds of controls, most of which pointed to the previously found .OCX files, although remember that controls can end in any extension. OLE Viewer contains a lot of information and is not for the faint of heart. However, it will reveal the files each controls refers to, their CLASSID's, and what controls are marked Safe for Scripting and initialization. Figure 11-17 shows the OLE Viewer and some of the information you can learn using it.

Figure 11-17. Microsoft's OLE Viewer


I will not cover all the information you can learn from using OLE Viewer, but it is over two dozens of fields of information on each control, and you can find the GUID of each control type classification, which can be helpful when tracking down controls marked as safe, etc. If you want the quickest way to see all the ActiveX controls installed on a PC, use OLE Viewer and look for the Controls category. If you are looking to see what controls are marked safe for scripting, choose the Controls that are safely scriptable category, although not all scriptable controls are registered here.

View Trust Relationships

You can view the trust relationships you have accepted during your browsing experience by choosing ToolsInternet OptionsContent in Internet Explorer 5.x. The Certificates button will list the certificates your browser trusts. The Publisher button lists (see Figure 11-18) what software vendors your browser trusts. If a name appears here, it means your browser will download and execute code signed by these vendors without prompting you at its default security setting. As shown earlier, even nonmalicious controls have been known to force themselves as trusted publishers. Review your trusted publisher list and remove those you don't need.

Figure 11-18. Trusted publisher certificates


Change Safe for Scripting Functionality

ActiveX controls can be marked Safe for Scripting and Safe for Initialization by their authors. If your Internet security is set to Low, you will be warned of controls that are not marked safe. There are many controls that are marked as Safe for Scripting that probably should not be. To find out if a particular control that you've already download was marked safe by the publisher, try these steps:

  1. Locate and record the CLASSID of the control. You can find this by choosing ToolsInternet OptionsSettingsView Objectsright click on desired objectProperties. Record the CLASSID number.
  2. Run REGEDIT to search your registry database.
  3. Go to HKCR\CLSID\classidnumber\Implemented Categories.
  4. The following keys will exist if the control is marked Safe for Scripting: 7DD95801-9882-11CF-9FA9-00AA006C42C4 (Safe for Scripting) and 7DD95802-9882-11CF-9FA9-00AA006C42C4 (Safe for Initialization).
  5. Delete the two keys, and the selected control will no longer be marked safe. It's not pretty, but it works.

If you've got controls that can modify or read your local file system, you probably don't want those marked as Safe for Scripting. Of course, as always, be sure to back up your registry prior to performing any direct registry manipulation. In Figure 11-19, I searched the registry for Vivo Player's CLASSID to find the two keys that determine if the control has been marked Safe for Scripting and Safe for Initializing.

Figure 11-19. Registry search to find if a control has been marked Safe for Scripting and Safe for Initializing


Enable Certificate Revocation Checking

You can tell Internet Explorer 5.0 and above to check a developer's signing certificate against the certificate authority's certificate revocation list prior to accepting the certificate. This lengthens the certificate acceptance process, but increases the degree of reliance on the certificate. You instruct Internet Explorer to check revocation lists by enabling two ToolsInternet OptionsAdvancedSecurity options: Check for publisher's certificate revocation and Check for server certificate revocation. The latter option concerns certificates that cover entire web sites and not signed code. A third option, Warn about invalid site certificates, directs Internet Explorer to check the URL links included in a site certificate, and warns you if a link is invalid.

TIP:   Although certificate revocation checking is not completely reliable, it cannot hurt to have it on.

Risk Assessment--Medium

To date, only a few malicious controls have been reported in the wild, and none are widely spread. However, seemingly innocent controls have been used for attacks, and nearly 50 ActiveX weaknesses have been discovered. ActiveX's biggest problem is the way it incorrectly marks controls Safe for Scripting. Already used in several email worm attacks, these types of holes continue to appear. If Microsoft cannot correctly determine the safety and appropriateness of their own system controls, how can vendors be expected to? Following that problem is the growing use of unsigned code. The digital signing process is technical and expensive. Most ActiveX controls on the Web are unsigned. Many of those that are signed, are expired. I rarely come across a control that is signed and current. If ActiveX's security lives or dies on whether end-users correctly choose to trust or not trust unsigned controls to run, it appears doomed unless digital signing of code becomes widespread. If ActiveX controls become standardized across the world's web sites, as expected, we will surely see a rise in malicious code for ActiveX.


ActiveX is a popular code-distribution platform with a fair amount of potential security holes. ActiveX's security is based around the concept of signed digital code. If you follow Microsoft's strict dogma of only accepting signed code, the risk of hostile ActiveX code is minimal. However, the lack of signed code means the decision to trust a particular piece of code is often left up to the user, who is not able to make an educated evaluation. It is hoped that Microsoft grants granular security to the ActiveX model and wraps controls in a protective cocoon, like the Java sandbox. Chapter 11 completes a four-chapter discussion of malicious code in the Internet browser environment. Chapter 12, on email attacks, is related because most of what we just discussed can happen in an HTML-enabled email client.

1. D=Disable, E=Enable, P=Prompt.

Back to: Malicious Mobile Code: Virus Protection for Windows Home | O'Reilly Bookstores | How to Order | O'Reilly Contacts
International | About O'Reilly | Affiliated Companies | Privacy Policy

© 2001, O'Reilly & Associates, Inc.