Why does Outlook have an OM?

This one could be controversial πŸ˜‰

In a recent comment, Edd James (note to Edd: that link gives a 403) asks why Outlook and Excel "need this ability to run scripts/macros[?]"

First I want to clear up a common misconception about Outlook: Despite what the endless ill-informed posters on Slashdot might claim, no recent version of Outlook (or recent update to an old version of Outlook) is designed to run code out of e-mail messages in the default configuration. Every once in a while someone finds a bug in the IE rendering engine or in Outlook that enables such execution, and that bug is fixed. Customers who want "dynamic" e-mails can still enable the feature through the Outlook security settings, but it is not the default and is not at all recommended.

But moving on, let's turn the question around: why shouldn't Outlook have a rich object model? I challenge you to give me a sound answer to that question based on security concerns (I can understand why you might not want the feature for "code bloat" reasons, etc.)

The obvious answer is that having an object model in Outlook makes all those mass-mailing viruses possible. Apparently anyone who uses that argument hasn't heard of the recent viruses going around; that latest "virus technology" doesn't rely on Outlook to do its dirty work. It scans files on your hard-disc to scavenge e-mail addresses, and then it uses a built-in SMTP mailer to send out the mails. If you are running Lotus Notes or Pine or Eudora or Mozilla Mail or any other e-mail client and you execute a MyDoom-like virus program, you are in trouble. (At this point, someone may point out that their e-mail program of choice is not susceptible to the virus de jour because the virus only understands the Outlook address book file format. True, but that has nothing to do with whether or not Outlook exposes an object model, and everything to do with the size of the installed user base).

The next answer is that having an object model in Outlook makes all those mass-mailing viruses easier to write. It is too easy for a "script kiddie" to cobble together some VBScript code and take over the world, so the argument goes. But the term "script kiddie" doesn't necessarily literally refer to "kids" writing "scripts." It refers to relatively unskilled people (of all ages) downloading sophisticated attack tools (written by the "real hackers") and then using them in some possibly-automated fashion. I doubt the average "script kiddie" has enough m4d c0ding 5ki11z to even write "Hello World" in VBScript, let alone craft something sophisticated like MyDoom. What the kiddies can do is surf around on #hacker IRC channels, download pre-canned exploit code from hackers, double-click on the icon on their desktop, and then brag to all their other 1337 friends. Basically, the really bad people (the criminals) who write real viruses don't need the Outlook OM to do their dirty work; sure if it is there they might choose use it, but they don't need it.

Of course the other point is that having an OM makes it easy for legitimate developers to write applications that better meet their customers' needs, and that is A Good Thing. We don't want to make it arbitrarily hard for "the good guys" to build solutions using our technologies, and in the end it won't really buy us anything since the bad guys are more determined than the good guys and so they will persevere with writing their malware whether we "help" them or not.

In fact, by making it hard for ISVs to write against the Outlook OM, you can argue that the world has gotten worse because customers now typically install 3rd party applications such as ClickYes or Redemption to re-enable access to Outlook... and those programs may have security bugs of their own!

The next answer (and a slightly better one) is that many people don't need the object model, so in order to reduce the attack surface of Outlook it should not be installed. The same argument has been used for WSH (Windows Script Host) as well, and you could make it for all sorts of other features, too; installing anything on your system (even security software) increases the attack surface of your system in one way or another. But the fact is though that these kinds of features don't actually present a very compelling "attack surface" as we usually define it. The person making this particular argument is probably missing the point. Once the malicious code is running on your system, it's game over man, GAME OVER!

I think this calls for an analogy πŸ™‚

One day a burglar breaks into your house. You surprise them in the kitchen, so they grab a sharp knife out of the drawer and stab you with it before running away. In an attempt to prevent this from happening in the future, you banish all knives from your house when you return from hospital. Sure, it might be hard to cut your steak from now on, but that's the price you pay for security. (Thanks to Randy for pointing out that "cheese" was not a good choice of words here for an American audience... πŸ™‚ )

A few weeks later, the burglar breaks into your house a second time, and you surprise them in the kitchen again. This time they grab a big saucepan from the drawer and hit you over the head with it before running away. After returning from the hospital, you remove all saucepans and frying pans from your kitchen to improve the security of your house. No cheese and no fried food might be good for your waistline, after all!

A week or two goes by, and the burglar strikes again. This time you catch them in the bedroom, and bereft of cooking implements they pick up a shoe that is lying on the floor and throw it at you. One trip to the hospital later, you have no choice but to ban shoes from your house as well. Hmmm, this could make going out for a walk a bit tricky, but hey, you have to protect yourself, right?

What's the point of this analogy? Well, you have failed to perform a root cause analysis of the problem. The problem isn't that you have knives or saucepans or shoes in your house; it's that the burglar keeps getting inside! If only you'd invested in a good-quality front-door lock (and possibly a guard dog or an alarm) none of this would have happened. And to appease the "attack surface reduction" argument, removing knives and saucepans isn't a very effective technique because the burglar will just start packing their own weapons or perhaps they'll come in at night when you're fast asleep. A good attack surface reduction technique in this scenario would be to permanently seal the back door (so there's only one main entrance to the house) and to place bars on all the windows (so there's less room to crawl through).

In the same way, removing WSH or Outlook or any other piece of "end user" code on Windows doesn't really help with attack surface reduction, and won't improve the real security of your machine one bit (it simply makes you less vulnerable to the more "popular" attacks, which is cold comfort indeed). Now don't get me wrong -- attack surface reduction is a great thing and we should be doing more of it. But a better example of attack surface reduction is the disabling of unneeded services, or the blocking of dangerous attachments in e-mail messages (the thing most responsible for the drop in e-mail viruses, until ZIP files became the infection vector), because both of these represent possible attack vectors for malicious code. Once malicious FullTrust (native) code is running on your system, it doesn't need any help from installed applications. As an extreme example, imagine that Outlook completely dropped its object model in the next version, and imagine further that nobody else in the world knew how to write a program to send e-mail. Mass-mailing viruses would still be possible; they'd simply bundle an old copy of Outlook '97 into their virus payload and use that to do their dirty work!

This is where threat modelling comes into play. If you yourself are writing some software and are worried about exposing features to COM or .NET clients because of the security implications, then think of it this way. If your threat is:

·       User downloads malicious full-trust code that uses your application's OM to do harm

Then you also have the threats:

·       User downloads malicious full-trust code that sends windows messages to your application to do harm

·       User downloads malicious full-trust code that patches the binary (or in-memory image) of your application to expose an OM and then uses it to do harm

·       User downloads malicious full-trust code that duplicates the functionality of your application to do harm

What is the root cause here? It is User downloads malicious full-trust code and that is the thing that you (or rather we πŸ™‚ ) should be trying to address with things like firewalls, proxies, virus scanners, attachment blocking, Software Restriction Policies, and so on. We put a better lock on the front door so that you don't have to throw out all your kitchen knives.

Obviously this simple threat model doesn't apply if you have an ActiveX component marked "Safe for Scripting," or if you develop managed code that allows partially-trusted callers, or if you accept any kind of untrusted communications from other machines across the network. In those cases you have much more complicated threat models and you do have to start worrying about what happens when someone with restricted permissions talks to your application's OM, and it would be great for you to look at how you can reduce your attack surface. But for a rich-client full-trust-only application like Office 2003, these kinds of threats simply don't apply.

Finally, if you're still not convinced, then think of it this way: Outlook is nothing special. Sure, it's a great e-mail client and I spend most of my day using it, but at the end of the day it's just a piece of software. Whenever a destructive virus comes around, you don't see the whole world demanding that Microsoft remove the DeleteFile API from Windows because it makes it easy to write file deletion viruses; that would be ludicrous. It's the same with viruses like Blaster or Slammer -- nobody asked Microsoft to pull networking from Windows just because there were viruses that propagated across the network (although some people have asked for "raw sockets" to be pulled, even though they are a standard part of most modern operating systems).

Another angle: A recent InfoWorld article shows the prevalence of spyware and adware on users' machines; a lot of that stuff is "willingly" installed by the user as part of some other application (typically file-sharing software), although a lot of it is also "accidentally" installed by users who do not read the (very poorly designed) IE download dialogs (which will thankfully be fixed in SP 2). These programs are probably more "destructive" to the average user than any e-mail virus, since they completely violate your privacy (monitoring web surfing, stealing passwords and credit card numbers, etc.), can include "backdoors" to allow later access and complete compromise of the system, and often cause instability of the OS.

And none of this has anything to do with Outlook, or, indeed, any kind of e-mail program. It has to do with the users' basic right to install software on their own computer and make bad trust decisions in the process. This is the problem that we need to fix long-term; not the ability of software to expose powerful, flexible object models that can be freely and productively used by suitably-trusted clients to build great customer-focused solutions. And of course, since trust is inherently a social problem, not a technological one, so the best we can do is educate users and guide them into making good decisions; we cannot make decisions for them.

There is no silver bullet.

Comments (10)

  1. Here! Here!

    You are bang on Peter! All these damn users out there parading around as their own Admin on their box propagate the problems, not a rich OM. Many people get it and have stopped opening attachments from people they don’t know. Some still do… explains my vast collection of free Levitra samples. But we need rich programmablity else we will never get all the features we need.

    Vote here for more not less!

  2. Alex Angelopoulos says:

    > This one could be controversial πŸ˜‰

    Only because it is also pointless since arguments against automation on these grounds are rarely well thought out. But I want to add some suppressing fire. =)

    Let me be up front about pointing out that I am biased. Very biased. I do a lot of scripting, and see the lack of easy automation interfaces to every bit of Windows and Windows applications as a Bad Thing.

    Nonetheless, this is not a COM thing or even a Windows thing. It is fundamental to the concept of computing: automation is inherently good. Potentially dangerous aspects of a computing systems are made safe not by driving them underground, but by providing effective safeguards. There are lots of ways of safeguarding things, but the simplest and most rational is a perimeter defense with some depth – e.g., AV software to catch actual malware in the act, and a firewall to detect attempts to break in or out.

    Crude statistics from personal history here. I’ve helped about a dozen people with severe remailing virus problems in the last few months. One used Eudora, 2 used Outlook Express, and the rest used webmail of various kinds. What all had in common was:

    + Machine and network connections were "acting funny" (sometimes for months);

    + NO active and up-to-date antivirus application;

    + Did lots of surfing, online chatting, or instant messaging WITHOUT having a firewall in place.

    All were fixed by installing an antivirus application and using it to clean the system. In several cases, activating a firewall initially also caught the backdoors involved before the AV software was installed.

    The obvious lesson here: if you want to be secure, TRY to be secure. If you don’t use antivirus software, you’re sticking some stranger’s dirty fork in your mouth; if you don’t use a firewall, you’re leaving all of your doors and windows unlocked. It doesn’t even need to cost money; Trend Micro and McAfee have free online scanners, and a host of small commercial AV vendors make their packages free for personal use. Firewalls, the same: XP comes with one, and several others such as Zone Alarm have free versions.

    Miscellaneous quick comments below. I almost shouldn’t bother. πŸ˜‰

    > The obvious answer is that having an object model in Outlook makes all those mass-mailing viruses possible.

    Oddly enough, arguing against an Outlook object model for this reason looks a LOT like "security through obscurity". And of course since so many non-Microsoft email clients use plain-text address books and email storage, they are even easier to parse.

    Of course, if users have firewalls and antivirus software, they’ve reduced their attack surface and can stop a hypothetical application that does this, but it probably wouldn’t be on their system anyway then, would it? πŸ˜‰

    > It scans files on your hard-disc to scavenge e-mail addresses, and then it uses a built-in SMTP mailer to send out the mails.

    Note that some of these viruses don’t even do that. It seems viruses that "phone home" or just sit and wait for someone to find them are the big thing now – and then they get an email list and run it repeatedly. They also use random combinations of common names and large domains to autogenerate "possible" email addresses.

    A clever trick for users to stop these viruses cold: instead of uninstalling Outlook, try INSTALLING a firewall and an antivirus application.

    > If you are running Lotus Notes or Pine or Eudora or Mozilla Mail or any other e-mail client and you execute a MyDoom-like virus program, you are in trouble.

    This isn’t true. If they have an effective antivirus program they’ll stop it. And a firewall would catch the network activity.

    Of course, if they don’t have either one, it doesn’t matter if they have NO email client. πŸ˜‰

    > What the kiddies can do is surf around on #hacker IRC channels, download pre-canned exploit code from hackers, double-click on the icon on their desktop, and then brag to all their other 1337 friends.

    Common viruses, yes – and this probably makes up the bulk of the virus infection attempts out there. Oddly enough, these commonly "handed down" viruses and trojan horses are usually well-known to antivirus and firewall applications. But then, I repeat myself. πŸ˜‰

  3. Bob Riemersma says:

    I think the problem gets a little more complex than this.

    As most of us do, I have to wear a number of hats. One of these hats is as a Windows developer. Sometimes a Mort looking out for my own needs, other times as a pro hacking on some custom middleware service I need to build to plug a group of web developers into some random legacy system.

    The bane of my existence is Joe Admin. The guy who thinks it’s just spiffy to lock everything down to where nobody else can get any work done.

    I have to perform certain types of system management on a mainframe system from a distance, basically with boxing gloves on. No admin rights, no direct access to management tools, capacity monitoring software, or much of anything really. Instead they like to just crap out emails at me containing the "facts I need."

    To survive I have a number VBA routines to harvest these oh-so-wonderful reports from my Outlook inbox. Then there is a set of scripts to post-process the stuff (I get inline text, RTF or PDF attachments, you name it), archive it, and parse out the useful data and load it into a Jet database. Then I have a few HTAs to pull selected data over selected time ranges out and create Excel sheets and charts or do other types of analysis – then fire these back out as emails to those who pay the bills (and want to know where their money is going).

    What it comes down to is my hands are pretty tied already.

    The LAST thing I need is Joe Admin coming around and locking down Outlook VBA, WSH, and HTAs on me. What next? Strip out the Excel and Word object models too? Lock down Task Scheduler?

    We aren’t all Minnie the Administrative Assistant out here. Give us poor folks trying to get work done a break too. Please??

    I’m well aware of the exploit woes out there. Heck, I was the guy who had to embarrass our Joe Admins into looking at SUS after we got seriously Blastered one recent summer. πŸ˜‰ Ahh, anonymous forums! How would we ever get these folks to toe the line without ’em?

  4. Chris Quirke says:

    MS’s own advice is; if the bad guy can run code, it’s not your system anymore. So why do we want to transfer ownership to any unsolicied email message "text", "data" file, or web site we visit?

    Outlook may not auto-run scripts in email message "text" anymore, but it’s taken *years* for this clue to sink in since IE 4. Even post-Kak WinME shipped with OE running in email zone by duhfault.

    As to "running with admin rights"; us standalone PC users already have a security model we understand. The "home" concept is "a physical location where safety can be assumed". Those with physical access have full rights; those with remote access have zero rights.

    So why should we have to wear name tags while walking between rooms in our "home", just because our OS is designed to be a network client rather than a properly-frontiered stand-alone OS?

    As it is, user accounts in XP Home are unfit for use until:

    1) The base prototype account can be preset so that new accounts can inherit our choice of settings (shell folder locations off C: perhaps, less massive web cache allocations, show file extensions, kill eye candy, etc.)

    2) Limited rights accounts retain settings; at present they re-duhfault to hide files/paths/.ext etc. making WYSIWYG risk assessment impossible

    3) Admin can see and apply settings across all user accounts, e.g. when cleaning up commercial malware that’s patched into each account

    As it is, using anything other than "admin" not only tends to cause apps written for Win9x to fail, but also means having to lose the safety of more clueful settings. So before you start waving limited accounts around as a panacea, fix ’em so they work better, m’kay?

  5. Peter Torr says:


    Your home analogy is not complete. Do you randomly walk into any room in the house at any time — for example, into the bathroom when you know someone else is taking a shower? Most likely not. People like to have privacy even in their own homes, and it is the same with a PC.

    Would you want your kids (assuming you have them) rifling through your filing cabinet looking for financial information? Or leafing through your chequebook and writing cheques to themselves? If not, then why do you want them to be able to do the same things on your PC?

    Also you don’t tend to invite random strangers into your house, but computer users WANT to let random strangers into their computers (think of all those file-sharing networks).

    Limited user accounts are <ahem> limited at the moment, but I believe you can achieve some of what you want by modifying the .DEFAULT user account in the registry (but that’s probably not supported…).

    I also don’t have settings changing behind my back (and I am not an admin on my machine). Perhaps you are experiencing some other kind of problem?

    Admins can of course see and apply settings across all user accounts — that’s the purpose of the Administrator!

  6. I don’t see how you can argue that technologies like VBA and WSH don’t present a very compelling attack surface, given the billions of dollars and system availability that have been lost combatting Office macro and .VBS viruses over the years. And now MSH is coming down the pipe.

    XP SP 2 does *not* fix the problems with VBA and WSH viruses… precisely because it does not disable the technologies in question. As I understand it, SP2 adds the AES API to block attachments and integrates this with OE and Windows Explorer. Unless I’m mistaken, some of the features of AES may not protect users of other non-Microsoft software, email clients, P2P file sharing clients, etc.

    You don’t explain why it’s a good security practice [dare I use billg’s words, "secure by default"] to (1) leave these technologies enabled on, say, home computers, and (2) give the user absolutely no way to disable unwanted technology such as VBA despite numerous user requests. I’m not asking for Microsoft to get rid of VBA or WSH or MSH… just recognize that these are proven virus platforms, and that we should have an easy way to disable them if we want, or even consider the security benefits of making them disabled by default.

    You state that disabling WSH and VBA would just "make you less vulnerable to the more "popular" attacks." To me, that’s like saying "you shouldn’t run a firewall, because you’ll still be vulnerable to viruses." Yes, the virus authors would probably start using other attack vectors… at which point we would want to take steps to reduce the risk from THAT new vector. Also, making a truly secure by default computer does not mean secure yourself just from the most popular viruses. Even if few people are writing Word macro viruses nowadays, you’re still at risk from a teenager from Iraq writing one up to get into your nation’s infrastructure. Blaming the user here doesn’t increase security much, not when it’s a sure bet that at least 1 in every 100 users will execute an attachment, and you only need 1.

    Nobody argued for disabling RPC in Windows because Microsoft programmed RPC into many other products that Microsoft Windows customers are also running. Besides, there’s already a way to disable RPC/DCOM if you wish. There’s no way to disable VBA. I’ve asked.

    Did your company have to shut down its email server for the ILOVEYOU virus? We wouldn’t have had an ILOVEYOU virus if Microsoft had simply changed the default action on .VBS and other files from Execute to Edit. Users and administrators could still run VBS / WSH files by right-clicking instead of double-clicking, or by using a command line or a batch file that explicitly specifies CSCRIPT as the host application. Can you give me a good reason why this still hasn’t been done on the "secure by default" XP SP 2 and Windows Server 2003? Will you trudge out the old excuse that this would somehow "break functionality?"

    Running as a non-administrator does not stop viruses. A non-admin user can still execute a virus and access the TCP/IP ports necessary to spread an RPC or email worm. My understanding is that Linux prevents non-admin access to certain TCP/IP ports, but Windows does not. A non-admin user can still save to the Word normal.dot and to his or her My Documents Startup folder. The main thing a non-admin user cannot do regarding viruses is edit the startup locations in the Registry in order to remain persistent on reboot. However, this is about as effective at preventing viruses as making the Normal.dot file read only — based on my personal experience in a large financial environment across several states, it’s not effective in preventing infection or re-infection at all.

    Thanks for writing an interesting and thought provoking article. It’s interesting to see the thought process from the other side.

  7. Peter Torr says:

    Good comment; I will reply later in another post (hopefully this weekend when I have some time…)

Skip to main content