I’m often tempted to write about viruses and what I think the next “innovation” might be, but then I get scared that I might get put in jail (or deported) should any of my ideas ever see the light of day. (Not that I think the virus writers need any help coming up with new ideas, but you know what I mean). Anyway, one thing I have been meaning to talk about is how I approach this problem for VSTO solutions, and since Raymond just blogged about some new shenanigans in this area I thought I’d do it now.
Aside: I say “how I approach this problem for VSTO,” but it’s not as if I am the only person thinking about this problem at Microsoft. Many smart people are thinking about it both from the security and the usability side of things, and we have spent (and will continue to spend) a metric boatload of time going over many different ideas and designs for the secure sharing and deployment of Office solutions. Hopefully, together we will come up with something that strikes the right balance between security and usability and lets the good people get their work done while keeping out the bad people. But this is my blog and I don’t want to speak for any other people. I know what my motivations / goals / guiding principles are, and I’ll try to share them with you.
I have a very simple set of metrics for deciding if a method of code installation meets my personal “it’s secure enough” bar — it has to be harder than double-clicking on an e-mail attachment, and easier than copying and pasting the source code into a new VBA project. (I’ll probably intermingle references to VSTO and VBA here because whilst I work on VSTO, it is not an end-user accessible technology whereas VBA is).
Let’s look at the current “state of the art” in viruses. Most new e-mail viruses like MyDoom rely on user interaction to spread (although they are often incorrectly termed “worms” — true worms like Blaster require NO user interaction). Running MyDoom “apparently” (I’ve never done it 😉 ) takes about three atomic actions:
1. Open the attachment
2. Accept the security warning
3. Open the EXE inside the attachment
(You could say that the first two are one and the same, and I’ll argue for that case below, so really there are only two user actions).
Clearly requiring only three (or two) basic user actions to go from “clean machine” to “virus infected spam bot zombie” is a little too easy. Now let’s look at the typical “Linux virus” approach as applied to VBA: you get an e-mail message with some source code in it, and instructions similar to the following:
1. Open Microsoft Word
2. Hit Alt+F11
3. Copy the code below into the clipboard
4. Paste the code into the VBA editor
5. Hit F5
Now five user actions isn’t a huge step up from three, but to most users all but the first step is unfamiliar, and it is very easy to mess up step #3 if you copy too much or too little from the e-mail into the VBA editor. The point being though that any security mechanisms we put in place that require more than five user steps are a waste of time — the hackers will just go with the copy-the-source-code route, which will still be easier for the end user than installing “legitimate” software through the imaginary 10-step “secure” process.
So we want a process that is harder than two trivial actions, but easier than five non-trivial actions. Time to focus our energies!
One important thing to note is that there are two entities involved in software distribution — the publisher (developer) and the installer (end user). In an ideal world we would want to make the distribution experience as seamless and easy as possible for both parties, but in a hostile, broadly-connected world that doesn’t cut it any more. Nevertheless, we can still try and simplify things for the developer; there’s no point in making it really hard to develop solutions while keeping the barrier for installing them very low — the bad guys don’t mind doing hard work to write their viruses, and the good guys will give up and go do something else if it’s too hard (and thereby not reach their full potential). And the end users will happily click on the attachments until the cows come home.
Instead, we want to make it as simple as possible to develop solutions, as simple as possible to install solutions from the “right” people, and virtually impossible to install solutions from the “wrong” people. Unfortunately, figuring out who is good and who is bad is the one thing in this equation that software alone can’t do. Once you know who’s naughty and who’s nice, it’s a Simple Matter of Programming:
But the burden of figuring out who is good and who is bad falls on the user of the computer (or perhaps their administrator). And, as history has shown us, users are less interested about who sent them the solution than they are about what the solution claims to do. It doesn’t matter if an e-mail comes from a random e-mail address with a random subject line and some random text inside it — if there’s an attachment entitled BritneySpearsNude then a significant number of users will open it and disregard any warnings. Even if the attachment is DoNotOpenMeBecauseIAmAVirusAndWillDeleteAllYourFiles, some people will open it just out of curiosity or because they think it is a joke.
Another aside: Modal warnings are horrible. It’s what we use today, but they are truly useless. I open BritneySpearsNude from my inbox. Clearly my intention is to open the attachment, but my e-mail program helpfully asks, “Are you sure you want to open this attachment?” OF COURSE I WANT TO OPEN IT! I would not have opened it if I did not want to open it!! Stupid computer!!! Stupid Microsoft!!!! Now where are my pictures of Britney????? And where have all my documents gone?!?!?!?!!!!!!
It also doesn’t help that you get redundant dialogs. I open a Word document from Outlook, and it tells me “Hey, y’know this could have a virus in it, don’t you?” even though the Word document may not have any macros in it. Then it opens in Word and (depending on my security settings and whether or not the document really has code in it) Word might warn me again. Now there’s a good reason for this — we call it “defence in depth” — since either of the two mechanisms could fail. Outlook is being ultra-paranoid: maybe you have your Word security settings at “Low,” so all macros can run. Maybe there’s a problem with the way Word checks for macros (we have issued at least one patch for just this problem in the past) and it won’t protect you from this particular virus. Maybe there’s a buffer overflow in the normal parsing of Word documents that doesn’t rely on VBA code to perform the exploit. You get the idea.
But of course the plain and simple truth is that Outlook is dumb and it just knows that .doc files need to prompt the user before being opened. It doesn’t know why, it just follows orders. Now if we could have Outlook, Word, Windows, Windows Update, Office Update, the virus scanner, the virus scanner’s update server, the firewall, and maybe a managed PC service provider all working together behind the scenes, maybe we could do away with the prompts altogether (or at least only show one prompt, and only when it was really necessary). But that’s a pipe dream right now.
That’s our goal — run good code and block bad code. But we can’t really get there without massive user education and a lot of infrastructure. So our next-best approach is to make it hard for end-users to run solutions. The idea here is that if it’s too hard to open the BritneySpearsNude attachment, then most people will give up and get on with their job. At the same time though, if it’s too hard to open Budget.xls with some cool Excel user-defined functions (UDF) in it, then people won’t be able to get on with their job.
Rant: I just tried looking for a good hyperlink to Microsoft documentation on UDFs in Excel. Could I find one? I’ll leave that as an exercise to the reader (thankyou Google). Anyway, when we did customer research on how people use VBA with Excel, we found that most people don’t know half of the things they can do. Workbook events — what are they? Worksheet functions — what are they? We have all these cool technologies and nobody knows about them. We suck. We need to do much better in the future, both in terms of increasing discoverability and in terms of documenting this stuff. And people say there’s no reason to keep building new versions of Office!
So anyway, back to where we left off the conversation… if it’s hard to install all solutions, then it’s equally as hard to install the good ones as it is the bad ones (remember, we can’t tell the difference between them). So the next best thing is to front-load all the pain of installing good code and require some kind of pre-arranged client setup (or, in the case of an enterprise, perhaps some domain-level policy) that will help to ease the installation of good code.
In this case, maybe we can require more than five non-trivial steps to setup the machine as long as those steps are done out-of-band and in a way that makes it very clear you should not do them as a normal part of your daily computer use. After all, you only need to do it once, and then all the good code runs with little or no fuss. You might note that not only am I a big fan of killing modal dialogs, I’m also a big fan of “out-of-band” activities for security-related actions. Don’t let somebody trust a piece of code while they are in the process of trying to run it! Force them to have thought about it before hand. That is what policy is all about — having a set of well-thought-out, generally applicable rules, and sticking to them. Don’t make ad-hoc decisions at the worst possible time!
And I’m going to stop here. Not because I don’t have anything more to say — I have lots to say — but because this entry is already quite long, and after all, I only ever said I’d tell you how I approach the problem, not how we solve it. We’re a long way from having a good solution to this problem at this point in time, although we’re all full of ideas.
Final aside: Regular readers will know I’m a huge fan of the Pet Shop Boys, but I’m also a big fan of Howard Jones. I think his song Someone You Need from the Perform.01 or The Very Best Of CDs is one of the most romantic songs I’ve heard in a long while. The lyrics are very simple, but it gets to the heart of the matter. Thanks Howard!