Date: Wed, 5 Mar 1997 03:38:54 -0700 (MST) From: Kevin McCurley Subject: Re: Comments and corrections on Authenticode (Atkinson, RISKS-18.85) I am sometimes reticent to discuss glaring security holes in public, but when a security mechanism is employed as a marketing tool, I believe it becomes fair game for criticism. Microsoft appears to have made a sincere effort to improve security with Authenticode, and Bob Atkinson gave a rather lucid explanation of the goals of Authenticode. Unfortunately, as a security mechanism, ActiveX with Authenticode has a rather big hole in it. First, there are no mechanisms to prevent a web page from invoking the ActiveX components served by another page or already installed on the users disk. For several weeks the page at http://www.digicrime.com/activex was happily invoking an ActiveX component referenced and downloaded by clients from the Microsoft home page. When you loaded the page from DigiCrime with Microsoft Internet Explorer, you were presented with an official looking seal from Microsoft certifying that the code you were about to install was written by them. And apparently it was. The second time you visited the page, the code was just invoked without warning. If you visited the Microsoft page first and then the DigiCrime page, the code from Microsoft was invoked without notice. Second, ActiveX controls have no inherent protection from the problem of stack smashing, which is one of the most common forms of software security problems. The technique is rather technical, but the effect is that some programs can be caused to execute a sequence of instructions supplied by the argument to the program (via a web page). The technique is accomplished when an argument is used to overwrite fixed-length buffers allocated on the stack, depositing instructions on the stack. This technique is rather tedious to carry out, and does not work on all code. On the other hand, writing safe code is a very difficult task, and any code that uses standard C library calls like gets() or sprintf() to handle arguments is likely to be vulnerable. The technique has been well known to hackers for a long time, and has been used to abuse many Unix network programs, including passwd, syslog, rdist, crontab, NCSA's web server, rlogin, talkd, mountd, and sendmail. Note that Java is explicitly designed to prevent stack smashing. Combining these two features of ActiveX, Authenticode becomes largely irrelevant. Code may be signed by the author, who was certified by a competent authority to be a reputable software developer. The user reviews the certification at install time, and accepts it on the basis of the reputation of the developer. The user then forgets about the code for some weeks to come. Later on, he or she visits a page of a hacker, or a page of a web site that has been broken into by a hacker, and invokes the code with arguments supplied by the hacker. The code may appear to do what it's supposed to, or appear to do nothing at all while it's erasing the web browser's history. The user may not even be aware that code is executing. The user goes on to about 50 other pages that night, and shuts off their machine with no evidence of a problem. When they reboot they may have a huge problem, depending on what the code was reprogrammed to do. The Authenticode scenario suggests that the user can now call their lawyer to sue someone, but who do they sue? The hacker that the FBI can't track? The well intentioned but pressured software developer? The certification authority like Verisign that have forty page disclaimers of liability? Microsoft, who developed the ActiveX and Authenticode technology? None of the above I think. And even if someone could be sued, is this an acceptable substitute for having their machine work for their business? My final criticism of Authenticode is unverified, in part because the public documents on the technique are rather vague. There appear to be no mechanisms for revocation of certificates that are already installed on machines. According to the document located at http://www.microsoft.com/workshop/prog/security/authcode/codesign.htm, the default expiration date for Authenticode certificates is the year 2039, which means that no certificate should be expected to expire for a while. If code is only re-verified when the certificate expires, then no buggy code will ever be replaced. If code is verified only at installation time, then this is even worse. I should point out that none of this has happened in real life yet, in part because technologies like ActiveX are in their infancy and are not yet widely deployed. Once it's out there, I maintain that the problems will only be worse, as it is extremely difficult to keep track of the constant stream of security announcements. As I write this, Microsoft is scrambling to patch an unrelated security bug in MSIE 3.0 (see Risks 18.85). Clearly it's not unusual to ship code with serious security bugs, because every vendor is doing it in their haste to ship product. It has been argued that the Java sandbox approach is too restrictive, and that "Users want and demand a rich computing experience". This may be true, but the rewards have to be something better than dancing bears in order to justify the risks. We take risks in life every day, but we do so on the basis of a continual risk/benefit analysis. Users may be willing to take the risks associated with network computing if they are presented with an accurate representation of the risk they are taking, and are given tools to manage and understand their risk. I can't see how Authenticode accomplishes this because it represents an oversimplification of a very complicated subject. In addition, the move to integrate a user's desktop into the Internet will only lead to more confusion from users as they try to understand risks coming at them from all directions. Kevin McCurley