Share via

The history of attachment security in Outlook, part 1 [1]

  • Article

This posting is provided "AS IS" with no warranties, and confer no rights. Moreover, I'm describing the history of the situation from when I actively worked on this area several years ago. Some things may have changed since then.

 

I started my career at MS as a tester on the Outlook team, as a contractor; I moved to fulltime 6 months later. I was given the option of interviewing in the NT group or in this group called Outlook that I'd never heard of (Office 97 had recently released). I asked what Outlook was, the recruiter said "It does email and stuff", and I said sure, I like email, let's try that one. I had a smart interviewer who used my sysadmin experience as a basis for asking me questions, but as I realized later, the questions were really testing based questions about narrowing down the repro for a problem.

 

So 6 months after my contract started, I interviewed for and got a fulltime position in the same group, doing essentially the same thing.[1] And shortly thereafter, I was assigned the areas I would own as a tester for the next couple of years, one of which was "attachments". I owned attachments in Outlook - however you got them into or out of Outlook, I was the main tester for that area. Right around that time, I had my first experience with a security issue, a buffer overrun when downloading a specially formatted MIME attachment. That was my first taste of working around the clock to fix, test and release a hotfix, with many eyes watching what I was doing.

 

Later the next year, Melissa stopped by for a visit. Remember her? (Oh how we cursed Kwyjibo's name). A few months after Melissa came Explore.Zip. So around that time, we decided to do something about it. We knew that one problem was that many users didn't realize attachments could be so dangerous, and so we released (designed, coded, tested, and then released, that is) the first Outlook Attachment Security Patch. Another week or two of my life went to testing this patch (we released it for both Outlook 98 and 2000, and testing the installer + patch on both versions + a variety of operating systems created a lovely matrix for me).

 

This first patch put up a dialog when it encountered a certain type of attachment, the goal being to get the user to think twice about opening the file. The UI prompt looked like this:

We released it and eagerly waited to see if it would have the desired result... eventually ILoveYou happened, and we learned that no, it did not have the desired result. When ILoveYou hit us at Microsoft, I saved off every copy of it I received from anyone because I wanted to know what idiots opened the attachment. I also checked the version of Outlook each of them used to send me ILY (OutlookInternalVersion in the field chooser if you're curious), and for many of them it was the patched version.

We knew something more drastic was needed. So we put a stop to a lot of other work that was going on and focused on how to solve this problem. There were several core problems, of course - #1 was users getting to the file and executing it, #2 was the ability of the viruses to quickly scan through and grab addresses from Outlook and #3 was the ability of the viruses to programatically replicate using Outlook, i.e. send copies of themselves out.

So we came up with a design to address each of these problems (there was interest at every level in this project; I remember a couple of hallway conversations about how Steve Sinofsky was reviewing the spec and suggesting changes). First off was the more restrictive attachment blocking - we wouldn't just gently remind you that attachments are bad, mmmmkay - we would just plain not let you get at certain types of files[4]. We kept in the 'gentle reminder' type of file blocking[5] and figured that some customers would want to use that for attachments such as ZIP.

Next we worked on address gathering. At first glance this might seem simple (or at least I know it seemed simple to many people four years ago, but those were different times). It's not just programmatic access to the addressbook (which is what Melissa used, and mailed itself to the first 50 entries or something stupid like that IIRC [6]), but programmatic access to any email addresses you can get at via Outlook in any way [7]. So there are some obvious ones off the top - the email fields in contacts, the from/to/cc on email in your folders, etc. But what about the body of a message - when you reply to a message, the SMTP address can get quoted in the original. And don't forget about the methods in the object model to do a search and return the results of the search as a collection - so you could do a search on email messages to find the addresses, for example. The list goes on... you get the point. All of that stuff had to be blocked. Along with this was included the capability to bless programmatic retrieval of addresses for a certain number of minutes, up to 10, so that if you're doing something that's grabbing address properties for a short time, you didn't have to approve it for every single property.

Third was propagation, outlook.item.send. The approach to this was to prevent the ability to send messages so quickly that even if the user did figure out what was happening, by the time they were able to respond, the machine would have already propagated hundreds or thousands of times. So a dialog with a five second wait was implemented and the "Yes" button to send wasn't even accessible until the five seconds had passed. One of the main goals behind the five second wait is that even if a program did programatically hit the "Yes" button, there would still be a wait before the next send. So in order to propagate using this same method as had been used before, a user would have to get infected and then hit 'yes' on the button time and time again. And boy, if a user does that, then we're really in trouble. :-)

We also knew that the programmatic blocks would harm ISVs who developed solutions on Outlook, and so we worked on ways to allow third parties to allow their applications to work, rewriting them if needed (and to this day, not all third parties are playing nice). This is an area I didn't work on, so I don't have much to say here. I do remember one part about this, however - we knew the patch would have a huge impact on both ISVs and customers, so we released a beta version to the web for testing. This first version had no admin customizability (for some or all parts of it, I don't remember), and there was a huge backlash, so we went back to the drawing board to figure out how to give admins the control over what their users could and couldn't do (can you say test matrix increase? whoo-boy!). Personally, I don't know how anyone ever thought we'd be able to get away without admin customizability in the first place, so regardless of the additional test load, I was happy that we were doing the right thing.

At the end of the day, the goal was to get Outlook out of the picture as much as possible. We always knew that the virus authors would find ways around the blocks we implemented, but we wanted to make it so that it wasn't Outlook's fault[8]. These days, if a virus author can get their code to run on your machine, they don't need any email client at all to find addresses and replicate. Parsing web caches and writing a quick and dirty SMTP client is pretty straightforward, so preventing the code from ever executing on the machine as well as locking down SMTP servers (inside corporations) is still incredibly important to the end-to-end solution. We actually had a contest in the Outlook test team to write apps to send mail to one of the test managers. Mine was a simple VB app that used tcpClient to open a connection on port 25 and send a message, I think it was all of 11 lines of code and took about 10 minutes to write. The app that won the contest was an ingenious one that went to a web email provider and programatically signed up for a new account and sent a message (these days most web mail providers prevent this by requiring interaction that requires an end-user, such as typing in the characters in a distorted graphic that's not machine-readable).

I remember discussing this patch with the MVPs, and boy did they hate it - they called it the HELL patch and they made this awesome buttons with a screenshot of the graphic on it and flames all around it. Pretty much everyone hated it at the time, I can't tell you how many customers flamed me on the newsgroups because draconian Outlook and the evil Microsoft was telling them they couldn't get at their files. But nowadays, I can't imagine a customer running without some form of attachment blocking. Attachment blocking was actually one of the first features I designed for OWA when I moved to PM later that year (oddly enough, I interviewed for my PM job in Exchange the month after I finished testing the security patch in Outlook - you might say I was a wee bit burned out : -).

Many more changes continued to happen after this in Outlook and across all Office applications (and Exchange - such as the ability to block unpatched versions of Outlook from the server side), but May/June of 2000 will always stick in my head as a "fun time" to be the attachments tester (that was also my first experience with 80 hour work weeks). I got a great plaque out of it at a team meeting, and I display it proudly in my office to this day. I also used this experience as fuel to write an article for Exchange & Outlook magazine. My article ended up making the cover; I sent a copy to my parents, who were very proud of me. They didn't exactly know what this virus stuff was all about anyway, but really that's their daughter and did you know that she's a published author and what have your children done with their lives, did I mention she's published?

 

 

[1] I hope I don't pull a History of the World here and never write the rest of the parts. I do have some more thoughts about viruses in general, the wonderful debates I've had with many a microsoft-hater about attachment security ("Microsoft's so dumb, if they just saved the attachments without the executable bit set, that would have prevented this from happening in the first place!"), social engineering and other such miscellany.

[2] On a side note, my office mate was Marcus, mentioned in this article [3]. I've long been curious if the Katherine Smith in that article is a quote somehow taken from me, given that Smith is my maiden name, Kathryn is what the K in KC stands for and I am now a blue badge employee. It sounds like something I might say, make your own choices and lay in your own bed and all that.

[3] I don't know anyone who uses the term 'dash trash' or looks down on people in contract positions in any way. Pretty much everyone I know respects skill and work ethic regardless of full-time status. If you don't do your job, that's another issue entirely.

[4] A lot of work across a bunch of folks at MS went into defining this list of files. It's a tricky situation - you want to catch executable filetypes that would exist on a typical OS install, but we certainly didn't want to be in the position of blocking a third party's file type and getting sued, even if that executable file type was potentially dangerous and would exist on the typical install.

[5] Actually in the first iteration of the spec, the EXEs, BATs and COMs of the world were configured via a registry key called something like "BadFileTypes". The "gentle reminder" file types were configured via a registry key called "QuarantineFileTypes". During the spec review, we decided that "Bad" isn't a great word to use... so we went with Level1 and Level 2 :-). This is an example [admittedly a pretty simple one] of the kind of thing that you need to keep in mind when designing products at Microsoft - a whole lot of people are watching.

[6] At the time, a common stopgap measure was to create 50 dummy AAAAA entries in the GAL. We still had them until fairly recently.

[7] Explore.Zip was pretty brilliant at the time, as it was the first virus to reply to messages already in your inbox as a way of propagating. So the usual anti-virus user education such as "Don't open attachments from people you don't know" wasn't useful in this case.

[8] For the purposes of this statement, I'm not counting actual bugs... what I mean by fault is that the virus authors wouldn't be able to use Outlook in perfectly valid ways to do bad things. If there's a bug that allows a security problem to happen, then that's a problem plain and simple.

Comments