MS Response to Chaos Computer Club Quicken Hack

Rohit Khare (
Wed, 19 Feb 1997 08:53:37 -0500 (EST)

MS's response to HacktiveX Controls continues to be 'c'mon, you didn't REALLY
want to run code that's not from Reputable Software Publishers (i.e. us & our
friends) -- and then, if it turns your PC into a molten slag heap, at least
you can file suit!'

Cute that MS is promoting Felten's Java Security book :-)


>From: Lee Hopkins <>
>To: "''" <>
>Subject: Don't accept candy (or executables) from strangers...
>Date: Tue, 18 Feb 1997 13:28:06 -0800
>Here's the Microsoft position on the Chaos Computer Club incident and
>ActiveX security in general.
>I don't get to keep up on this discussion list as much as I'd like.
>Anyone is always welcome to forward postings my way for comments.
>Lee Hopkins
>Microsoft Denver
>Background: Last Thursday the Hamburg chapter of Chaos Computer Club
>(CCC) demonstrated how an ActiveX control could be downloaded to a
>machine, and then hang about and steal confidential ID information from
>Quicken users and then drain their bank accounts. Our understanding of
>the situation is that the control was unsigned, and that it has not been
>released (demoed only).
>Top Line Response: This is a great example of why anonymously authored
>executables are so dangerous. It's exactly the kind of risk that code
>signing helps to manage, and Microsoft is leading the industry to
>provide more accountability and integrity for executables through
>Authenticode™ technology.
>Speaking Points:
>* This is a great example that shows that all executable content is
>potentially dangerous. This is an industry-wide problem that is not
>going away, and is a threat to all Internet Users. Sandboxing techniques
>don't solve this as the many Java security holes demonstrate.
>* If you want to avoid getting burned, only execute code from publishers
>you trust. Don't take candy from strangers. Anything you let into your
>environment should be from publishers that you recognize and trust.
>* The mechanism for positively identifying authors and managing this
>risk is code signing. Microsoft is the first company to provide code
>signing for Java Applets and other executables in Internet Explorer 3.0
>with Authenticode™ technology. Sun and Netscape have proposed code
>signing architectures in their next release. These features will allow
>businesses and users to make informed decisions about whether or not to
>allow executables to install and run in their environments.
>1. What's the worst thing that can happen when users download code from
>the Internet?
>This really depends on what information is stored on that machine and
>what that user does with the machine. The consequences of these types
>of intrusions can be pretty dire, as various high profile incidents have
>demonstrated. This is why we think it's so important to educate the
>users about the risks, and how to manage them.
>2. Isn't the best solution just to use Java, so the Java sandbox will
>protect my desktop system from access by any Internet applets?
>It would be great if things were that easy. But it's not. And
>fortunately Sun is not irresponsible enough to represent Java as a cure
>all to security problems. In fact Sun maintains a very complete list of
>their security bugs and issues on their website;
> There is also a very good book by Gary
>McGraw and Ed Felten published by John Wiley and Sons called Java
>Security:Hostile Applets, Holes, and Antidotes which every Internet user
>should read.
>3. What are the most important "safety tips" you would offer users on
>the Internet?
>Don't take candy from strangers. Make sure you only run applets and
>content from authors and publishers you know and trust.
>4. What is Microsoft planning to do to notify and/or protect Quicken
>users from this malicious code?
>At this point the ActiveX control hasn't been distributed as far as we
>know, and it was not signed by the Chaos Computer Club. So the first and
>most important thing we can do is to educate users about the problem of
>anonymous code to make sure they don't download and run unsigned applets
>or applications. Fortunately as a society, we have developed criminal
>justice procedures and mechanisms for tracking criminal activity. In
>this case anyone employing this control for criminal purposes would
>leave a clearly defined trail through the International banking system
>that could be tracked by the international criminal justice authorities.
>But the first order of business is to educate users about the threat, so
>that they do not use applets created by unknown authors.