by Bill Schongar and Paul Lagasse
It's hard to protect yourself against every possible thing that could happen. To give ourselves a feeling of security, we surround ourselves with walls. Of course we have to get in and out, so we put doors in those walls. Because the doors become the weak link, we put locks on them. Now our wall is not as strong as the original wall, but it's more convenient, and we feel okay about it. But, we also feel a little claustrophobic, so we need some windows to get light inside. That puts more holes in the walls, albeit with a little glass standing between us and the outside world, but it's definitely no deterrent to someone who wants to get in. And we still feel secure? It's a sacrifice of security for convenience.
Dealing with computers, and most definitely dealing with the Internet, is a little like a house. You can be pretty certain that when you first get your computer set up it doesn't have anything nasty lurking in it. As you start opening up more connections to the outside world and bringing back things you've found, you're taking a chance. Is that chance worth it for the convenience you gain? Is there too much danger? Well, take a look.
VBScript and ActiveX are two recent entries into the exuberant chaos of the Internet, and as new visitors there's a lot that you might or might not know about their potential for causing trouble. We're now going to examine all the possible hazards you could be facing, and show you that although the potential for danger is there, a great deal of effort has been put into making VBScript and ActiveX as safe and secure as possible. You'll look at the following:
One thing to keep in mind while going through this chapter is that there's inherent danger in everything you do. There's always a chance something can be misused, that something can go wrong. But risks are normally weighed against benefits, and the same needs to hold true when dealing with VBScript and ActiveX. Much has been done to make both elements of Microsoft's Internet plans as safe as possible, but it's better for you to know all the possibilities so you can be prepared.
Who do you trust? Whether you're considering buying a used car, investing in some financial venture, or buying software, the decision ends up being a combination of a number of factors. What's the reputation of the person or group you're dealing with? What do you know about the product, service, or information you're getting? What's your gut instinct? There's a lot to consider.
The wide and often weird world of the Internet makes trust a more difficult commodity to come by. There's now a lot of distance between you and whomever you're dealing with. You might or might not have the benefit of knowing the reputations of the folks on the other end of the arrangement, or even if you're dealing with whom you think you are. Anonymous remailers, purloined passwords, and the inherently insecure nature of an unsecured public network are all just parts of the chances you're taking.
Don't think that you're alone, though. If you're on one end of the conversation, think about what's going on if there's another person like you on the other side. They feel they're trustworthy, but what do they know about you? How can they be sure that you're who you say you are? If you're writing any kind of software code for them, how can they be absolutely sure there's nothing nasty hidden in it? What about things such as unforeseen circumstances, like bugs in the code that weren't tested or encountered?
Sounds ominous, but don't get your knickers in a twist just yet. At the time of this writing, there were no publicly known security holes, but the same was true of JavaScript and Java for a while, too. It stands to reason that somewhere, sometime, someone will discover a trick or a bug that manifests itself as a nasty possibility for security breach. They might or might not make it public, depending on if they're well-known security researchers at a university or someone with something slightly less ethical driving their hunt for such a "feature."
The software is continuously changing, as well. Not necessarily VBScript, but what's used to run it. The basic premise of VBScript is that with a few DLLs or some source code, some other application could run VBScript code. Depending on how someone else implements VBScript functionality, the security features of VBScript could end up being compromised, either due to errors, incompatibility, or just the need of the other application for more functionality. NCompass Labs was the first company to dare tread those waters by developing ScriptActive, a plug-in that allows VBScript to function in Netscape Navigator. While it's unlikely that any adverse interactions could happen in ScriptActive's use of VBScript, it's just an example that VBScript language and functions will find their way into a variety of operating systems and general environments. That leaves a lot of room for an open door.
If you've followed the plans of Microsoft and the other big industry players, you've also seen that one of the big pushes is to integrate the Internet and everyone's machines. Microsoft plans an integrated desktop, where you're browsing the Net and your hard drive at the same time. You can bet that will mean more built-in functions that could possibly be accessed by scripting languages. And that means more possibilities for dangerous situations. The hope is that new security technologies and the basic built-in safeguards of VBScript will make Net surfing safe for a long time yet to come. So far, it doesn't look too scary.
Safety and security in VBScript would seem to be a dead-end topic. After all, didn't Microsoft say in all their original VBScript documentation that "all potentially unsafe operations have been removed from the language"? The following list shows some commonly used Visual Basic function categories that you won't find in VBScript.
File I/O (all of it)
DDE
Object Instantiation
Direct Database Access (DAO)
DLL execution
While certainly not an exhaustive summary, you can see that a lot was removed in the name of security. You can't create an object, you can't do real file input and output-what could possibly be potentially harmful or unsafe? Well, because you ask, take a look.
Safety in VBScript is a relative term. The good news is, you really can't purposefully do anything that will have a significant harmful effect on any user's system. That's because of the language limitations we just looked at in the previous list. If File I/O had been left in, or even some of the other inter-application communications processes, there would be a lot that you might need to worry about. However, it's still easily possible to annoy people. For example, we'll show you an obnoxious implementation of a Message Box. It would certainly be a way to discourage people with VBScript-enabled browsers from visiting your page, but other than that its actual practical use is pretty much nil. So don't try this at home, unless you really want to inconvenience yourself.
Listing 21.1. VBScript Inconvenience Script-What not to do in VBScript.
1: <script language="vbscript">
2: <!--
3: ' Don't run this in your browser!
4: ' The purpose of this script is just to show how even
5: ' basic "safe" functions in VBScript can cause
6: ' problems...
7: while (1=1)
8: {
9: value = MsgBox("Yuck.", 1 + 16 + 4096)
10: }
11: -- >
12: </script>
If you had run the script in Listing 21.1, you would get a screen that looks similar to that shown in Figure 21.1, where a message box pops up on the screen with the message and style that had been selected with the MsgBox function. The problem here is that this function is in an endless loop; every time you click OK in the message box, another message box comes up. No problem; just switch pages and kill the task. Nice try, but one of the reasons this is so inconvenient is that you can't do that.
The parameters on the end of the MsgBox function do more than just control the appearance, they include a parameter (the 4096 part of the MsgBox statement, to be specific) that makes the Message Box System-Modal. For those of you who haven't done much in the realm of Windows programming, this means that everything else on the system stops until this message box is cleared. Under Windows 95, you're not completely stuck-you can go into your other applications and save files, open files, and go about your business as normal, but that annoying message box will still remain on top of your other tasks. Because it's in an infinite loop, it doesn't stop with just one message box, which means your system is somewhat stuck until you very explicitly tell it to stop.
This is just an annoyance example, one that doesn't do anything to your system that's permanent or really disruptive (other than tying up your computer and possibly causing you to reboot, of course), but demonstrates unsafe code. It does something that isn't harmful, but doesn't function as intended, and was probably never tested if it's part of a larger script. Remember, "safety" is a relative term- being "safe" to run a piece of code might mean complete security to one person, and bug-free code to another.
As a general rule, though, VBScript by itself can't do any significant damage. Microsoft was very careful to remove potentially unsafe elements, and without those elements in place the VBScript code is trapped within the confines of the browser. It's certainly possible that new additions to the browser could change that, or that a bug or security hole could open up, but that possibility is about as small as it can reasonably be expected to be.
Microsoft is pushing ActiveX components like a bulldozer moves dirt and small rocks: relentless and unstoppable. This created an immediate response from vendors of OLE-capable controls that had previously been developed for C++ and Visual Basic use. The number of ActiveX controls on the market and in development just exploded over a short period of time. You already know the reason-the capability to integrate ActiveX components with VBScript adds a lot of possibilities to the list of what can be done with an otherwise limited scripting environment. They open almost every door that was closed by limiting VBScript operations in the first place. Don't have File I/O? Make use of an ActiveX component. Can't tell the system to do things? You got itÉActiveX to the rescue.
With this proliferation of controls on Web pages, more and more sites will be adding functional controls to their internal and external sites. From a functionality standpoint, having this cornucopia of controls is great, but from a security standpoint, the same proliferation is frightening. You're talking about legions of controls that are automatically downloaded onto your system, installed, configured, and there for anyone to use in their VBScript code. All any VBScript author needs to do is look for the unique CLASSID number that corresponds to the object, and hey, presto! They now have instant access to that control within their VBScript code, or through another ActiveX control. With so many controls popping up at once, it's hard to believe that no one will find bugs or even as-designed features, which let someone get away with something that you might not want them to.
Imagine for a moment that you want to prevent someone from doing something. Isolating them will normally make some progress on that front because they can only affect their immediate surroundings. That is, unless you provide them with a method of communicating to someone or something outside their isolation. Give someone a phone and a capable outside accomplice that they can call, and all you've done is prevented the isolated person from doing the dirty work themselves. The same holds true for the seemingly incarcerated VBScript and its ActiveX cohorts. If someone can find a way to get a control of theirs on your system, or knows of a legitimate control that can be coerced into doing something that suits their purposes, you could be in trouble.
Looking at the basic array of ActiveX controls, you might scoff at first. What can someone do, toss an extra button on your browser screen? Shove unwanted streaming video at you? Spawn unwanted URLs in new windows? Hmm, doesn't sound too terribly frightening, does it? Before you doze off into peaceful dreams of the safe world VBScript lives in, you might want to try looking under the bed.
In the race to inspire confidence in online consumers, the software industry constantly looks for the best way to assure people that what they're getting hold of is authentic and safe. People like going into a store and knowing they're not buying some cheap copy of something when they're paying the price for the original, and they like feeling that they can trust the vendor of the software. But how do you assure people over the Internet?
You start by giving them something reasonably tangible. The Internet is an anonymous place, where people can pretend they're anyone they want, because you can't see them. If you need to convince consumers that your software is safe, you first need to convince them that you're who you say you are. The tangible proof that someone can get when an ActiveX control comes into play arrives in the form of an authentication certificate. While it's just one item to the user, there's a lot more behind this certificate than just one step.
The first step that precedes the certificate is Internet Component Download. Unlike the traditional plug-ins, but like Java applications, ActiveX components can be automatically downloaded, installed, configured, and run on an end-user's machine, all automatically. The HTML <OBJECT> tag that outlines what the ActiveX control is, as well as what parameters the object has, includes support for specifying a location through a CODEBASE parameter. If the unique class ID (CLSID)of the object isn't found on the user's system, the browser goes out to the site specified in the CODEBASE parameter and downloads the required file or files.
When the component is downloaded, a few basic checks are made on the integrity of the file to ensure that it isn't immediately doing something it shouldn't, but it can't possibly test the component exhaustively. What Microsoft and other vendors would like to accomplish is giving end users the same sense of security and assurance that they have when buying a shrink-wrapped piece of software in a store. You know who it's from, you know what it's supposed to be, and you know who to yell at if it doesn't perform as expected. To make us all feel safe, components are secured using what's called Authenticode technology.
Knowing that you're getting what you asked for is where Authenticode kicks in. Part of the mechanism for downloading the ActiveX component seamlessly involves a basic security check on the thing that's being obtained. One of the best ways to promote security in these transactions is to have a piece of code digitally "signed" by the manufacturer, so you know it's reasonably authentic, and not just someone claiming to be IBM or Microsoft, or some modification of their code. Besides that, it can check the integrity of the download, making sure that the transfer didn't get corrupted along the way.
The hows and whys behind the general use of Authenticode are pretty simple. You create a piece of code, and then you tag it with a digital signature that contains information about the file, including a cryptographic checksum. A what? A Cryptographic checksum is basically a summary of the file itself, such as how big it is and some interior inherent data, which is then encoded and stored. When the file integrity is checked, the same information is gathered and encrypted again. If the two encrypted portions match, it's a pretty sure bet that the code hasn't been tampered with or corrupted during download.
But what if someone else tries to sign a name that's not theirs to a piece of code? Well, that's where a signing authority steps in.
To prevent digital forgery, a signing authority is used in conjunction with the Authenticode process to ensure that the person or company signing the code is legitimate. The first signing authority entrusted with this task of keeping signatures intact is VeriSign, Inc. For a fee, they'll check your company out and provide a way for you to uniquely identify your products electronically, preventing tampering. What this buys you, as an established vendor, is the capability to provide a reasonable level of assurance to customers and visitors that you are who you say you are, the code is what you say it is, and someone else will vouch for you.
So, if you, as a software author, develop a component or a series of components, you'd prove to a Signing Authority that you are who you say you are. They might ask for a Dun and Bradstreet number, some tax information, or other documents, just to be certain. When they're convinced, they give you a unique digital stamp that you can use to encrypt your software. When you stamp your software this way, someone on the other end will see a certificate that contains the public information contained in that stamp-who your company is, what the software is, and who vouches for you. While all possibilities of forgery can't be avoided, the combination is pretty effective, and enough to inspire a reasonable level of confidence in erstwhile consumers. After all, that's the goal-you're downloading only "friendly" components that have been checked and that someone takes responsibility for.
Don't be fooled into thinking that ActiveX controls are harmless, even the ones that do what you think they do and come from people you can trust. Someone you trust could give you a knife set as a present, but if someone breaks into your house they could still use it against you. The danger isn't necessarily in the original source of the object in question, but any subsequent use of that object could potentially be by someone you don't trust.
As an example, imagine an ActiveX-based FTP control. Great for automated download pages, especially in intranets. You could branch your VBScript application to different files based on questionnaires, or any number of other choices, and process it in the background so users could continue to do other things on the page. While the control itself is extremely useful, imagine the possibilities for abuse. Someone could download any file they want to your system, possibly even bypassing prompts to check and see what you want to do with the file. Far worse, FTP is a two-way street-they could bundle and upload a variety of system files from your machine, or other random files that could be of use to them. If they were really devious, they could just replace a typical system file with a copy of their own, to capture passwords and other data.
Pretend, for a moment, that you're a computer whiz with a desire to experiment, and have temporarily misplaced any ethical qualms about doing weird things to other people's systems. Oh go on, we won't tell anybody about your dark side. From this new (hopefully) vantage point, ActiveX could be a big temptation to play with. You've got millions of people downloading software that they've never even heard of, often times without even realizing it. Sure, it's harder than making a virus or following a how-to guide for packet-based denial-of-service attacks, but, oh, the possibilities. And you were looking for a real challenge for your free time, anywayÉso you decide to hack some ActiveX controls.
There are a lot of highly skilled individuals out there who aren't pretending. They know code inside and out, backwards and forwards, and they could easily see mucking about with ActiveX and its associated security as a great thing to add to their resume. There are also distinct groups of them. Some are in it just for the challenge, not for the damage-to them it's not a question of malice or ethics, but something new and cool to figure out and understand. They might make a few controls that do things they shouldn't, but they'll probably give them to friends, or show them off. Another group might follow that path slightly further, being interested in just what they can do, and where that knowledge gets them. They'd probably build something to collect tidbits about you from your hard drive, send it back to them, and bounce you an anonymous e-mail saying they've done it.
Other groups end up with far more malicious intents-they might want to trash your hard drive, get financial data, or break into your corporate network to get things that will ruin your whole day. Some of it might be subtle, planted for later, and other things could be blatant, but for them the challenge isn't just to know how to do it, it's to do it, use it, and get away with it.
The popularity of ActiveX makes it too tempting a target to be ignored. No matter who does it first, or how they do it, someone will create controls that are designed to breach the security of your system. These "rogue" controls could take any form, but the most obvious ones have already been mentioned-system corruption, private information gathering, and stepping stones for further security breaches.
Can you defend against these kinds of people? Sure, don't download anything, ever. This is paranoid, fatalistic, but unfortunately, true. Insidious hostile controls, like those that serve a real purpose but have hostile code embedded deep within, will be the worst. While it inspires a sense of paranoia to think you have to question everyone, it's just part of the cost you pay for the convenience of the Internet.
The worst possible case of rogue controls would be that of intentional tampering of a company's controls by a member of that company. This would be someone who could change the code, or switch it for something else entirely, and authenticate the new code. Because the trust in authenticode technology is geared more towards trusting a company, rather than an individual, dissent within the ranks hits the consumers through what they thought was a safe back door. As mentioned in the "Authentic Controls" section of this chapter, users might have already established that future; authenticated source code from a particular company or agency should not inform them of future component downloads. So, if someone tampers with what is already registered as a "friendly" product.
Another possibility would be the cracking of the authenticode scheme on either the signing end or the user end. Imagine what someone could do if they got hold of Microsoft's signing key-suddenly you're prompted to download the latest version of an Internet Explorer control, and the certificate looks perfectly valid, if you see it at all. This breach of the underlying security would cause a real break of faith in the trust that Authenticode and other digital signing technologies want to inspire in end users.
Preventing your system from these kinds of attacks is pretty tough to do all by yourself. Sure, you can disable the use of ActiveX controls, but that's the "stick your head in the sand" approach to safety, and won't move you into the next generation of functionality very quickly. Your real best defense is to put only those controls on your system that you need, and keep up with the latest versions of browsers and controls. This gives you the best chance to have the properly functioning versions of controls and the latest security measures available in your browser.
Be sure to take advantage of the security measures wherever possible. Don't disable them because they're annoying or inconvenient-they're built in for a reason. A common trap is to disable the certificate checking for other software packages from the same company or signing authority. Give yourself a fighting chance-let yourself know what people are shoving on your system.
Remember, though, that at the heart of the legitimate controls are people with safety and functionality as their primary goals. They're not out to mess your system up or give people a way to cause you problems. They want to give you functions that you want and need. It's in their best interest to give you a sense of confidence in what they produce and not let you be scared off by possible threats. This means you've got a lot of people behind the scenes working for your security and safety, both by improving the reliability of their own controls and security and by fending off attacks on the ActiveX security mechanisms by outside sources. It's like having your own personal Internet Police Force-and it's a good thing to have.
Combining functionality and safety is a tough job. In Biotechnology and other fields, you often encounter the term Best Available Technology (BAT) when dealing with potential risks and their solutions. It means that a better solution may come along in the future, but if you're dealing with the issue right now, a better solution doesn't come to mind. VBScript and ActiveX take advantage of the Best Available Technology for protecting themselves and for protecting you. Like any security measures, there is always a way around them, but just like putting doors and windows in your house, you sacrifice complete security for convenience, aesthetics, and functionality.
Don't box yourself in without an opening into the functionality that VBScript and ActiveX provide. As a developer, you can't afford not to think about security, but you can't hope to have a 100% secure solution. If problems and security breaches occur, your duty to the end users is to protect them from potential problems that are within your control, and try to keep your use of controls reasonable, so as not to crowd their systems and possibly breach their defenses. As an end user, you need to act as a careful consumer. Don't let things onto your system that you question, but don't be afraid of every new thing that comes out. You can always disable Java, ActiveX, and VBScript in your browser if you're nervous, but for the benefits that you'll get by leaving them all enabled, it sure seems like a reasonable risk.