Code signing is an important tool for certifying the authenticity and the integrity of programs. But as we will see, Authenticode does not provide “safety,” as is implied by Internet Explorer’s panel.
Code signing does not provide users with a safe environment where they can run their programs. Instead, code signing is intended to provide users with an audit trail. If a signed program misbehaves, you should be able to interrogate the signed binary and decide who to sue. And as the case of Fred McLain’s Internet Exploder demonstrates, once the author of a malicious applet is identified the associated software publisher’s credentials can be revoked, preventing others from being harmed by the signed applet.
Unfortunately, security through code-signing has many problems:
Once it is running, a signed ActiveX control might erase the audit trail that would allow you to identify the applet and its author. Or the applet might merely edit the audit trail, changing the name of the person who actually signed it to “Microsoft, Inc.” The control might even erase itself, further complicating the task of finding and punishing the author. Current versions of Microsoft’s Internet Explorer don’t even have audit trails, although audit trails may be added to a later release.
Audit trails are only useful if somebody looks at them. Unfortunately, there are many ways that a rogue piece of software can harm the user, each of which is virtually invisible to that person. For example, a rogue control could turn on the computer’s microphone and turn it into a clandestine room bug. Or the applet could gather sensitive data from the user, such as scanning the computer’s hard disk for credit card numbers. All of this information could then be surreptitiously sent out over the Internet.
Consider an ActiveX control written for the express purpose of deleting files on the user’s hard drive. This control might be written for a major computer company and signed with that company’s key. The legitimate purpose of the control might be to delete temporary files that result from installing software. But since the name of the file that is deleted is not hardcoded into the control, but instead resides on the HTML page, an attacker could distribute the signed control as is and use it to delete files that were never intended to be deleted by the program’s authors.
The validation routines used by the Authenticode system are themselves vulnerable to attack, either by signed applets with undocumented features or through other means, such as Trojan horses placed in other programs.
Ultimately, the force and power of code signing is that companies that create misbehaving applets can be challenged through the legal system.
Will ActiveX audit trails hold up in a court of law? If the company that signed the control is located in another country, will it even be possible to get them into court?
Code signing does prove the integrity and authenticity of a piece of software purchased in a computer store or downloaded over the Internet. But code signing does not promote accountability because it is nearly impossible to tell if a piece of software is malicious or not.
Signed ActiveX controls can be hijacked: they can be referenced by web sites that have no relationship with the site on which they reside and used for purposes other than those intended by the individual or organization that signed the control.
There are several ways that an attacker could hijack another organization’s ActiveX control. One way is to inline a control without the permission of the web site on which it resides, similar to the way an image might be inlined. Alternatively, an ActiveX control could simply be downloaded and republished on another site, like a stolen GIF or JPEG image.
Once an attacker has developed a technique for running a signed ActiveX control from the web page of his or her choice, the attacker can then experiment with giving the ActiveX control different parameters from the ones with which it is normally invoked. For example, an attacker might be able to repurpose an ActiveX control that deletes a file in a temporary directory to make it delete a critical file in the \WINDOWS directory. Alternatively, the attacker might search for buffer or stack overflow errors, which might be able to be exploited to let the attacker run arbitrary machine code.
Hijacking presents problems for both users and software publishers. It is a problem for users because there is no real way to evaluate its threat: not only does a user need to “trust” that a particular software publisher will not harm his computer, the user also needs to trust that the software publisher has followed the absolute highest standards in producing its ActiveX controls to be positive that there are no lurking bugs that can be exploited by evildoers. And hijacking poses a problem for software publishers, because a hijacked ActiveX control will still be signed by the original publisher: any audit trails or logs created by the computer will point to the publisher, and not to the individual or organization that is responsible for the attack!
Imagine that a person in a large corporation discovers that a rogue piece of software is running on his computer. The program may be a packet sniffer: it’s scanning all of the TCP/IP traffic, looking for passwords, and posting a message to Usenet once a day that contains the passwords in an encrypted message. How does the computer security team at this corporation discover who planted the rogue program, so that they can determine the damage and prevent it from happening again?
The first thing that the company should do, of course, is to immediately change all user passwords. Then, force all users to call up the security administrator, prove their identity, and be told their new passwords. The second thing the company should do is install software such as ssh or a cryptographically enabled web server so that plaintext passwords are not sent over the internal network.
Determining the venue of attack will be more difficult. If the user has been browsing the Internet using a version of Microsoft’s Internet Explorer that supports ActiveX, tracking down the problem may be difficult. Internet Explorer currently doesn’t keep detailed logs of the Java and ActiveX components that it has downloaded and run. The company’s security team might be able to reconstruct what happened based on the browser’s cache. Then again, the hostile applet has probably erased those.
It’s important to note that technologies like code signing of ActiveX and Java applets don’t help this problem. Say a company only accepts signed applets from one of 30 other companies, three of which are competitors. How do you determine which of the signed applets that have been downloaded to the contaminated machine is the one that planted the malicious code? The attacker has probably replaced the malicious code on the source page with an innocuous version immediately after you downloaded the problem code.
It turns out that the only way for the company to actually reconstruct what has happened is if the company has previously recorded all of the programs that have been downloaded to the compromised machine. This could be done with a WWW proxy server that records all “.class” files and ActiveX components. At least then the company has a chance of reconstructing what has happened.
While to date there is no case of a malicious ActiveX control that’s been signed by an Authenticode certificate being surreptitiously released into the wild, it is unrealistic to think that there will be no such controls released at some point in the future. What is harder to imagine, though, is how the victims of such an attack will seek redress against the author of the program—even if that attack is commissioned with a signed control that has not been hijacked.
Consider a possible scenario for a malicious control. A group with an innocuous-sounding name but extreme political views obtains a commercial software publisher’s certificate. (The group has no problem obtaining the certificate because it is, after all, a legally incorporated entity. Or perhaps it is just a single individual who has filed with his town and obtained a business license, which legally allows him to operate under a nonincorporated name.) The group creates an ActiveX control that displays a marquee animation when run on a web page and, covertly, installs a stealth virus at the same time. The group’s chief hacker then signs the control and places it on several WWW pages that people may browse.
Afterwards, many people around the world download the control. They see the certificate notice, but they don’t know how to tell whether it is safe, so they authorize the download. Or, quite possibly, many of the users have been annoyed by the alerts about signatures, so they have set the security level to “low” and the control is run without warning.
Three months later, on a day of some political significance, thousands or tens of thousands of computers are disabled.
Now, consider the obstacles to overcome in seeking redress:
The users must somehow trace the virus back to the control.
The users must trace the control back to the group that signed it.
The users must find an appropriate venue in which to bring suit. If they are in a different state in the U.S., this may mean federal court where there is a multiyear wait for trial time. If the group has disbanded, there may be no place to bring suit.
The users will need to pay lawyer fees, court costs, filing fees, investigation costs, and other expenses.
In the end, after years of wait, the users may not win the lawsuit. Even if they do, the group may not have any resources to pay for the losses, or it may declare bankruptcy. Thus, victims could lose several hundreds or thousands of dollars in time and lost data, and then spend hundreds of times that amount only to receive nothing.
 Inlined images are a growing problem on the Internet today. Inlining happens when an HTML file on one site references an image on another site through the use of a <IMG SRC=> tag that specifies the remote image’s URL. Inlining is considered antisocial because the site that holds and downloads the image is usually having its content used without its permission—and frequently to further the commercial interests of the first site with which it has no formal relation.
 Developers at Microsoft are trying to develop a system for signing HTML pages with digital signatures. Such a system would allow a developer to create ActiveX controls that can only be run from a specially signed page.
 Anecdotal reports suggest that many ActiveX controls, including controls that are being commercially distributed, will crash if they are run from web pages with parameters that are unexpectedly long. Programs that crash under these conditions usually have bounds checking errors. In recent years, bounds errors have become one of the primary sources of security-related bugs. Specially tailored excessively long input frequently ends up on the program’s stack, where it can be executed.
 Companies such as Microsoft, Sun, and Digital Equipment, as well as individual programmers working on free software have consistently demonstrated that they are not capable of producing software that is free of these sorts of bugs.
 Turning a WWW proxy server into a security server was proposed by Drew Dean, Ed Felten, and Dan Wallach at Princeton University.