HD DVD / Randomness... : VSTO

Back to VBA

ptorr — Thu, 20 Jan 2005 14:01:00 GMT

Today I needed to write a fairly simple piece of code to manipulate some Excel documents, and I chose to do it in VBA. That might sound like heresy for someone who used to work on Visual Studio Tools for Office, but since I switched teams I feel no obligation to use that stuff any more ;-)

Just kidding, but I chose to use VBA for a few reasons:

·My main machine has the Whidbey CLR but only the Everett Visual Studio, which makes debugging a pain

·I wanted to deploy this to a small set of users without worrying about them having the CLR or updating policy correctly (yes, the security guy didn't want to worry about security)

·I was hacking this code as I went (ie, there was no design!) so in order to ease development I wanted to take advantage of Edit and Continue, "unfrozen host" debugging, etc.

·It was a quick-and-dirty solution and I didn't want to spend a lot of time messing around with a "heavy-weight" tool like VSTO

I'm actually pleased to say that whilst the first two reasons (infrastructure / logistics) were valid, the second two (developer productivity) weren't -- I would have been much better off using VSTO.

Using the VBA editor is painful. The IntelliSense is primitive, the mouse scroll wheel doesn't work, the forms designer is sooooo 20th century, the Forms3 controls don't make much sense, and so on. I had to deal with silly VB6-isms like the Set statement and the lack of a Return statement. When I was debugging, I never actually got to use EnC -- all the edits I needed to make ended up being "rude" edits that forced a project re-set. And my code turned out to have very limited interaction with the Excel OM itself, so being able to access the "unfrozen host" wasn't a killer feature.

So all in all a big thumbs up for using VSTO; you just can't beat all the cool productivity features in Visual Studio :-). Deployment is an issue with VSTO, so it's good to know that VBA is still around for the times when you need it.

One day I'll re-write the tool "properly" in managed code and take advantage of all the cool new Whidbey features... in my copious spare time!

Dr. Strongname, or: How I Learned to Stop Worrying and Love the URL

ptorr — Sun, 07 Nov 2004 06:12:00 GMT

One of the problems with the Trustworthy Computing initiative is that many of our products have become harder to use as a result, either due to configuration changes or documentation changes. For example, Windows Server 2003 now ships with pretty much everything turned off by default, but customers that just want to "plug it in and go" get frustrated because now they have to configure everything that used to just be turned on automatically.

For VSTO, the problem is more to do with the way we document / blog about / evangelise the product to customers. Whereas in the past the documentation might have told customers the easiest way to accomplish something and left the more secure method to a side note or appendix, nowadays we focus on the more secure methods first and this can also be frustrating for customers who are willing to make the usability / security trade-off in favour of usability.

So, customers hear about VSTO, they hear about its strict security requirements, and they hear about this thing called "strong naming" and conclude that they need to strongname their code in order for it to work. It doesn't help that every time someone asks a question about VSTO security, we usually say "Well, you could just trust the folder, but that's not really recommended - you should use a strongname to be more secure!" But that's pretty much the responsibility we have with Trustworthy Computing; we need to tell people the "better" way of doing things rather than the "easier" way.

Anyway, the problem with strongnames is that they weren't really designed to be used as security principals -- they were designed to uniquely identify assemblies and to detect tampering or spoofing attacks against assemblies. In order to ensure that two assemblies with the same name get different identities, strongnames use the same kind of public-key digital signature technology that Authenticode signing does. This means that, cryptographically speaking, the kinds of guarantees that the system can make about an assembly are the same for both strongnames and Authenticode signatures. Couple this with the fact that anyone can generate a strongname keypair for free with sn -k mykey.snk (versus setting up a certificate server or dropping cold hard cash to Verisign or another 3rd party CA) you can see why strongnames are a popular way to trust assemblies.

But strongnames are first and foremost are about guaranteeing the identity of an assembly, and one of the properties of an assembly's identity is its version number. When one assembly Budget.dll is dependent on a strongnamed assembly Helper.dll, the information baked into Budget's manifest includes the version number of Helper as part of the reference information. If, at runtime, the CLR cannot find the exact version of Helper that Budget was originally compiled against, it will fail to load the assembly and probably cause the application to die horribly as a result. (Publishers can supply version-redirection information with their assemblies to modify this behaviour, but that's another complication I don't want to get into right now).

So let's say that you build an Excel-based VSTO solution with Helper.dll version 1.0.0.0 and Budget.dll version 1.0.0.0, you put them both on a share, and people start using them. Someone reports a bug in the application, and you track it down to a problem in Helper.dll, which you re-build as Helper.dll version 1.1.0.0 and upload it to the share, over-writing the old version.

But now you get calls from people saying that the solution is broken, so you run the app in the debugger and determine that it is because Budget.dll is looking for version 1.0.0.0 of Helper.dll, but only version 1.1.0.0 is available. Since you probably didn't know about <bindingRedirect> and/or you don't have time to investigate further, you take the easy way out -- just change the version of Budget.dll back to 1.0.0.0, re-build it, and ship out the "new" version of the assembly to the share again.

Ah-ha, but now something else goes wrong. You get calls from a different set of users who claim that you haven't fixed the bug at all -- it is still happening on their machines. You double-check to make sure that the "right" version of Budget.dll version 1.0.0.0 is on the share, and sure enough it is. You fire up the VSTO solution on your desktop and verify that, sure enough, the fixed version of the assembly is loading. Just to be sure, you make some additional changes to the code (like, say, putting MessageBox.Show("This is the fixed version!") in the constructor), re-build it, copy it to the share, and run the solution again.

Hmmm, that's weird -- the message box never popped up. You do a bit more poking around and add the following line to the assembly:

MessageBox.Show(this.GetType().Assembly.Location);

Now when you run the solution, you see that the assembly is running from some seemingly random location in your profile folder -- not from the network share where you would expect it to be loading from:

c:\documents and settings\joe_user\local settings\application data\assembly\dl2\a7dn830f.ad2\aofhwldc.vc0\72d679a8\8368c70e_93af78bc\helper.dll

What's happening? Well, when you open the project, the CLR loads Budget.dll and sooner or later it tries to use a type defined in Helper.dll. Fusion is asked to load the assembly, and since it has a strong name with the version 1.0.0.0, Fusion looks in the local download cache to see if it already has that assembly -- why download it again over a slow network link when you can load it right off the local disk (and Windows may already have it mapped into memory, too)? Of course Fusion sees that it does already have a local copy of version 1.0.0.0 of Helper.dll, so it loads that without going out over the network to download the other copy -- after all, you strongnamed the assembly so it's guaranteed to be the right one. If it had been changed, the digital signature wouldn't match.

But of course it's the "wrong" copy of version 1.0.0.0, because you made changes to it but didn't update the version number. You're lying to Fusion about the version of an assembly, and then you're wondering why the system isn't working as expected. (As an aside, the first set of users who complained about getting assembly load failures due to the wrong version number would have been the ones who had never previously downloaded the buggy version of Helper.dll, so Fusion didn't have a copy in the cache).

So now you're really in a bind:

·You have to use strongnames, because you need to be secure

·But if you use strongnames, you have to keep updating the version numbers to play by Fusion's rules

·And if you update the version numbers, your applications break

·But the only way to bypass Fusion's cache lookup is not to use strongnames

· And you have to use strongnames!

·Argh! What's a poor developer to do?!?

Well, take a step back; as I noted in a recent post, security is all about managing risk. If your efforts to be secure cause more problems than they solve, it may be time to re-think your strategy.

We recommend that users rely on some form of cryptographic evidence such as a strongname or Authenticode signature because it provides a high degree of assurance that the assembly you are running really is the one you think you are running -- even if a malicious user can gain write-access to the location of your assembly, they can't modify its contents or replace it with an entirely different assembly without breaking the signature and thereby causing the CLR to reject any requests to load the assembly. Only if the malicious user has access to your private key (ooops!) and they have write access to the assembly's location can they cause damage in this scenario.

But if you have good controls over access to the assemblies' location (ie, you ensure that only trusted parties can upload or modify files on the server) then you may be comfortable with just using URL-based evidence for your VSTO solutions. Besides, in a typical scenario there are likely to be other things on that server that a bad guy could take advantage of if they gained write-access to it, so you're really no less secure than you were before by relying only on URLs.

So, if you're running a controlled environment inside the firewall, maybe you can drop the strongnames (and the versioning issues that come with them) and just rely on publishing your assemblies to a trusted server location. For information on how to set up policy based on URLs, you can consult the VSTO documentation.

Show me the money!

ptorr — Fri, 29 Oct 2004 08:32:00 GMT

A member of the VSTO team just came to my office and asked, "Is it bad to trust all Office documents on the Local Intranet?"

That's a good question, and after answering it for him I thought it was also worth blogging about (plus I'm hanging around the office waiting until I have to leave to take a friend to the airport ;-) ).

From a pure technical standpoint, yes it is bad. You are increasing the risk to your systems and your network by allowing operations that were not previously allowed. If there is ever a vulnerability discovered in VSTO that allows a malicious Office document to take unauthorised actions on a user's PC then being susceptible to documents hosted anywhere on the local network (versus just documents on the local machine) is A Bad Thing.

But the world is not that black-and-white.

And just as an aside, the "absolute" risk involved in trusting Office documents to run VSTO solutions is actually fairly low; without an already-trusted assembly to somehow exploit through malformed document content, there isn't much a malicious document could do save spin up the runtime and create an AppDomain with no user-supplied code inside it, or possibly take advantage of some parsing errors in the VSTO loader or the CLR loader (both of which, fingers crossed, are robust against such attacks). So what we're talking about here is actually a fairly low-risk activity to begin with.

But back to the story at hand.

The purpose of security is not to avoid risk, but to manage it. A computer that is unplugged, sealed in concrete and glass, and then dumped at the bottom of the ocean has very little risk of being infiltrated by a hacker, but it also has very little value to the owner. We want to enjoy the benefits of putting the computer on a desk, turning it on, and jacking it in to the internet, but at the same time we want to do what we can to avoid attacks whilst not unreasonably cramping our style.

More importantly, if I expect to make more money with a computer turned on and plugged into the internet than I expect to lose due to malicious attacks, common sense says that I should plug it in. This is the way business works.

So, is it a bad idea to trust all the documents on the local intranet? I can't answer that for any given person, because their specific scenarios and their attitudes towards risk and their cost structures and so many other things can come into play, but I can help someone make a decision that is right for them.

The real question though is "Why would someone want to trust the entire network -- every single machine behind the firewall, possibly including random laptops from vendors, contractors, customers, etc. -- instead of just a small set of well-managed and secure servers?"

It comes down to cost.

Let's say that you decide to only trust documents from the server http://officedocs/ and you roll out policy to your organisation for that purpose. Things are going well, but after a few weeks everyone realises how cool your VSTO solutions are and they want to put them up on http://anotherserver/. So you update policy to include the new server, and roll that out. A week later it's http://finance/, then it's http://marketing/public/docs/, then it's \\randomserver\ and pretty soon you're getting a new request every week. How much is this costing you (and your business)?

·Lost productivity from end users who are unable to do their work until the servers are trusted

·Lost time due to management approval process to get a formal request through

·Time spent evaluating the request, updating policy, and testing it

·Time taken to actually deploy the policy and get all users (including remote / offline users) updated

·The risk of making a mistake with the new policy either opening up a security hole or breaking existing applications

·And so on

When you look at the potential costs involved trusting documents on a server-by-server basis in a large organisation, it might start to approach (or even exceed) the potential costs involved in their being a successful attack launched from some rogue laptop.

For example, let's say you estimate the cost of adding each additional server to policy to be $1,000 (an imaginary figure, of course -- it would probably be at least an order of magnitude higher in real life!). And you estimate (with 80% probability) that over the next few years there are going to be about 10 sites that you expect to want to host documents. So the expected cost of this approach is:

$1,000 x 10 x 80% = $8,000

Now, let's also assume that you estimate the cost of a successful VSTO document-based exploit document is $100,000 (again, a completely arbitrary number) but that there is only a 1% chance of it happening inside the intranet. This gives an expected cost of trusting the whole intranet as:

$100,000 x 1% = $1,000

Which would you go for?

Even if you factor in a "risk multiplier" of 5 (ie, you're risk averse and want to up the numbers a bit "just in case") it's still $3,000 "cheaper" to trust the entire intranet than it is to deal with each server on a case-by-case basis. Obviously these numbers are completely made up and you'd have to do the math on your own for your particular organisation, but the point is that just because something increases risk, it doesn't necessarily make it a bad thing.

It's OK to tell people what they already know

ptorr — Fri, 03 Sep 2004 14:26:00 GMT

I like it when people send me e-mail with security questions. I like it because it implies two things:

1) The person is thinking about the security implications of their code, and has recognised a possible problem; and

2) The person realises that they need to seek help to get the right answer, rather than just saying "Oh we'll use $MAGIC_SECURITY_FEATURE$ here and it won't be a problem."

Anyway, recently I got the following (paraphrased) question from someone:

In Michael Howard’s book Writing Secure Code it says that you shouldn’t tell the attacker too much when you fail and gives the specific example of showing an exception stack trace to the user when there is a failure. When our application fails to load an assembly, it shows the user a dialog box with a stack trace in it to help the user track down the problem. I can see why this makes sense in debug mode, but is it a security problem in release modes? Aren't we giving away sensitive information by doing this?

Glad you asked! :-)

The specific advice in question applies when the attacker doesn't have direct access to the code. For example, in an ASP .NET application, the attacker is sitting across the world looking at their web browser and can't read the DLLs off your web server's hard disc. In this scenario, handing out information in a stack trace on an error page is bad because you might leak path names, source code, or other tidbits of information that the attacker can use to stage their attack.

Two other examples of this are a SQL Server application giving out detailed error information to an application running on a separate machine (or in a separate security context), or even a script on a web page talking to an installed ActiveX control and getting an error message back with too much information. In all these cases, you are giving the attacker access to information they couldn't get in any other way since they don't have direct access to the code on their machines.

But in the case of an application displaying an error dialog to the user, the "user" already has access complete access to the code (they're running it on their machine!) so they can already attach a debugger to it, disassembly it, poke it with a sharp stick, etc. if they really want to. No information is being leaked in this case (although you might not want to scare users with a full stack dump by default!).

A while ago, another person asked me a different question:

We're building an Excel solution with VSTO 2005 and using the new Task Pane functionality [ed: cool!]. Our solution talks to a secured web service to download sensitive information into the spreadsheet. We're worried about what happens when the user saves the spreadsheet -- should we blank the data out of the spreadsheet every time it is saved so that we don't "leak" sensitive information? We automatically refresh the data the next time the workbook is opened so legitimate users will still have access to it.

Glad you asked! :-)

First thing to do -- as always -- is to consider the threats you are trying to mitigate. The threat which appears to be most salient here is one of information disclosure. For example:

Alice creates a spreadsheet using the VSTO solution and uses it to download some sensitive information into a worksheet. She intends to e-mail the spreadsheet to her co-worker Bob, but accidentally e-mails it to a competitor with the same name. Obviously Competitor Bob doesn't have access to the sensitive information hosted by the web service, but now he can read the persisted data out of the spreadsheet and use it for his own nefarious purposes.

In this case, the person realised that their solution was an "enabling technology" that could allow sensitive data to leak to unauthorised people, and they wanted to take some responsibility to help stop any potential security breaches. That's a great attitude to have, but in this case the suggested solution attempts to protect the user from themselves, and in the process throws the baby out with the bathwater so to speak. It's also very fragile.

Using code to blank out values on save is unreliable -- what if the code crashes during the Save event handler and the code never completes its task, or if a bad COM Add-In crashes Excel and saves an auto-recovered version of the file with the data still in it? Additionally, whilst you may know to blank out cells A1 to C20 because that's where your code puts the data, you have no idea if the user has manually copy-and-pasted it to some other area of the workbook, so you can't guarantee you'll always blank out every cell that contains the sensitive data.

Even if you could technically perform this action, blanking out cells it may actually defeat the purpose of the solution. You have to ask yourself "Why are we building this solution on Excel?" One of the benefits of doing so is that you get local access to off-line data, and you can easily move it around. Is it an intended feature of the solution that people who are authorised to see the data can download it to a spreadsheet and forward it to people who are not authorised to see the data? What if two authorised people see different views of the data and they share a spreadsheet; what happens to the data in that case? Is it intended that User B can see User A's data (since it was cached in the spreadsheet), or are they supposed to re-run the queries and download their own data every time? (But remember that User B can always disable the code if they don't want the queries to auto-refresh and thus leave behind the original data)? If the desired functionality is that the data always auto-refreshes, how does Alice show Bob a snapshot of her data without having Bob physically come over to her desk and look at her monitor?

Really this one comes down to user education. Whenever the user opens / creates the spreadsheet, you could initially have the task pane show some descriptive text describing what the application did and require the user to click a "Download sensitive information" button before you contact the web service (this would also help prevent repurposing attacks). Now the user knows the spreadsheet contains sensitive information, and you have two possibilities:

1) If they are "good" people then they should be careful not to forward the document to the wrong person, just as they should be careful not to forward their Microsoft Money data file or their last Review document. Suggesting to the user that they can use IRM to protect the document might help here.

2) If the user is "bad" and intentionally wants to leak the data to other "bad" people, you can't stop them doing it anyway. They could just copy & paste the data, take a photo of the screen, print it out, etc. Depending on how determined the bad guy is, IRM may not be appropriate here because it is not strictly a security technology.

Moral of the story: Threat models are your friend :-)

Code Repurposing and Untrustworthy Data

ptorr — Fri, 03 Sep 2004 14:22:00 GMT

This is just a generic launching place for four other blog entries, since I seem to send them to people on a regular basis and sending one URL is easier than four :-)

Code repurposing

· http://weblogs.asp.net/ptorr/archive/2003/10/16/56270.aspx

· http://weblogs.asp.net/ptorr/archive/2003/10/21/56296.aspx

Untrustworthy data

· http://weblogs.asp.net/ptorr/archive/2004/04/12/111342.aspx

· http://weblogs.asp.net/ptorr/archive/2004/04/13/112404.aspx

When is the Local Intranet not the Local Intranet?

ptorr — Fri, 16 Jul 2004 10:32:00 GMT

When it's in another zone, of course.

One of the recommendations we give for setting policy on VSTO projects is to sign your assembly (either with an Authenticode certificate or a strongname) and then trust that key only for a specific computer (eg, your deployment server) or for a specific Zone (typically My Computer or Local Intranet). So people go ahead and they do this, and sometimes it works and sometimes it doesn't. They scratch their head for a while, and then they e-mail me and ask what's up :-)

Almost always, the problem is that although the person thinks the computer is in the Local Intranet zone, IE has a different opinion on the matter for one of two reasons:

1) You have previously added the web site to the "Trusted Zone" for some particular reason

2) You are using a dotted IP address (\\192.168.1.1) or a FQDN (\\computername.company.com) name instead of a NETBIOS name (\\computername)

The first one fails for obvious reasons -- you moved the site from the Local Intranet Zone to the Trusted Sites Zone, and the CLR is simply obeying your command. Fixing it is as easy as moving the site back to Local Intranet (if that makes sense for you) or changing your policy to trust the key inside the Trusted Sites Zone instead.

The second one is a bit less obvious. Basically (and I'm by no means a network protocol expert, so feel free correct me if I get the details wrong) IE knows that NETBIOS names (names without dots in them) can't be routed across the internet, so if it sees a name without a dot it knows it is a local name. If IE sees a name with dots in it (whether numeric or DNS) then it assumes it is coming from across the internet, and so it falls into the Internet Zone. One tricky thing here is that since an IP address is really just four bytes, you can represent an IP address as a single 32-bit number such as \\12345678, and this could indeed come from across the internet. So there is a special check to see if it is this kind of address in addition to the simple "does it have dots in it" check.

Fixing this is also quite easy; just add the computer's address to your Local Intranet Zone by going to Tools -> Internet Options -> Security -> Local Intranet Zone -> Sites -> Advanced and typing it in.

Note that the cause of this problem (but not the solution) is easily deducible by following my previous debugging tip to find out how the CLR is resolving your policy rules.

A useful regfile for VSTO

ptorr — Fri, 16 Jul 2004 10:11:00 GMT

Here's a quick post with a regfile you can use to help you test your VSTO projects.

Cut and paste the text below into a text file (be careful of line wrapping) and save it with a reg extension. Then open up regedit (as a member of the Administrators group) and select File -> Import... from the menu and navigate to the file you just saved (you could also just double-click on the reg file in Windows Explorer).

This will give you two new context menu items on DLLs, EXEs, and Folders. The first one will add a URL membership condition to user-level policy to fully-trust the file (or folder), and the second one will remove that entry from policy. Note that these shortcuts are pretty dumb, they won't actually "untrust" the file or folder (they just remove the "explicit" entry required by VSTO), they could completely destroy your computer and the surrounding countryside, they should be used at your own risk, etc. etc. etc.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\dllfile\shell\FullTrust]

@="Trust assembly"

[HKEY_CLASSES_ROOT\dllfile\shell\FullTrust\command]

@="C:\\WINDOWS\\Microsoft.NET\\Framework\\v1.1.4322\\caspol.exe -q -u -ag 1 -url \"%1\" FullTrust -n \"%1\""

[HKEY_CLASSES_ROOT\dllfile\shell\UnTrust]

@="Remove assembly trust"

[HKEY_CLASSES_ROOT\dllfile\shell\UnTrust\command]

@="C:\\WINDOWS\\Microsoft.NET\\Framework\\v1.1.4322\\caspol.exe -q -u -rg \"%1\""

[HKEY_CLASSES_ROOT\exefile\shell\FullTrust]

@="Trust assembly"

[HKEY_CLASSES_ROOT\exefile\shell\FullTrust\command]

@="C:\\WINDOWS\\Microsoft.NET\\Framework\\v1.1.4322\\caspol.exe -q -u -ag 1 -url \"%1\" FullTrust -n \"%1\""

[HKEY_CLASSES_ROOT\exefile\shell\UnTrust]

@="Remove assembly trust"

[HKEY_CLASSES_ROOT\exefile\shell\UnTrust\command]

@="C:\\WINDOWS\\Microsoft.NET\\Framework\\v1.1.4322\\caspol.exe -q -u -rg \"%1\""

[HKEY_CLASSES_ROOT\Folder\shell\FullTrust]

@="Trust folder"

[HKEY_CLASSES_ROOT\Folder\shell\FullTrust\command]

@="C:\\WINDOWS\\Microsoft.NET\\Framework\\v1.1.4322\\caspol.exe -q -u -ag 1 -url \"%1\"\\* FullTrust -n \"%1\""

[HKEY_CLASSES_ROOT\Folder\shell\UnTrust]

@="Remove folder trust"

[HKEY_CLASSES_ROOT\Folder\shell\UnTrust\command]

@="C:\\WINDOWS\\Microsoft.NET\\Framework\\v1.1.4322\\caspol.exe -q -u -rg \"%1\""

Why does Outlook have an OM?

ptorr — Sat, 17 Apr 2004 06:46:00 GMT

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.

Top 5 List

ptorr — Fri, 16 Apr 2004 07:36:00 GMT

Julie is looking for input on a Top 5 Good / Bad Things about VSTO list over on her blog. If you have any others to add, surf on over and help her out ;-)

Follow up to "Don't trust that data"

ptorr — Tue, 13 Apr 2004 23:19:00 GMT

Eric makes some good points in a comment to my last post. Nevertheless, the forces of evil within me compel me to respond anyway. (You should have blogged it, Eric ;-) ).

Eric's main point is that the employee doesn't need to use formulas in order to fool the expense report system -- he can simply redirect the TotalExpense named range to point to some arbitrary location that his boss will never look at. That would be correct in an automated system, but the supposition in the first example was that there was no code involved in the scenario; it was all based on people looking at the expense report and following a manual process. Hiding the column or re-directing the named range doesn't make much sense, because the payroll clerk will see the same column that the manager sees ($100).

Hiding / moving a named range (or any other kind of UI spoofing attack) will typically only work when a human makes a decision that a computer then acts upon (because the computer "sees" a different value to the human). You must understand your threats (or your opportunities... mwhahahahahahaaaa) in order to successfully protect (or exploit) a system.

Eric also points out that hacking the cached data blob is probably the hardest attack of all to mount, but that just means developers will be least likely to deal with it! Nobody expects the Spanish Inquisition! If I know you are passing the data to some unmanaged component, for example, maybe I can trigger a buffer overflow by fiddling with the bits. Or perhaps I can just break some of your other assumptions in the code by inserting too many (or too few) rows of data, etc. I just don't want developers to fall into the trap of believing (incorrectly) that the data cache always holds what they are expecting it to hold. We've seen far too many web developers fall into that trap and get themselves (and their customers) into all manner of nasty problems.

You cannot trust anything that was under the control of the attacker.

Using protected documents might help somewhat against a causal attacker, but you need a whole lot of infrastructure to set up IRM, and the other kinds of protection are trivially broken. Also it should be noted that IRM is not a security technology! It is not a foolproof way of thwarting all attacks by well-skilled evil doers; it is a technological measure to encourage users to adhere to existing corporate policies (such as "don't forward confidential e-mails outside the company").

Obviously these kinds of threats will not exist in the vast majority of cases -- most employees are not going to spend time hacking into your Excel based solutions in order to cheat on their expense reports; they're just going to try and get their jobs done. But you should be aware of such possibilities so that you can weigh up the costs of adding in additional protection (in terms of increased development time, reduced productivity / usability, more help desk calls, etc.) against the risks / likelihood of employees rorting the system (if you are a large bank or a secret government agency, the risks might be pretty high).

Oh and this is nothing unique to Office -- if you built a custom WinForm application (or even a Java application!) and used it to connect to a server, I would be giving you the same advice; you would be asking for serious trouble if you blindly accepted all data coming from those clients and acted upon it without first doing some kind of verification. Just as the employee can dork with the spreadsheet in order to send you fudged data, so too could they dork with the client application (or just write their own!) and use it to connect to your server and send you bogus data.

Don't trust that data!

ptorr — Mon, 12 Apr 2004 07:04:00 GMT

A while ago I wrote a couple of blog entries on code repurposing and some mitigations, and one of the main causes of that problem is that developers inherently trust data. The text box caption says Name, so it's always gonna contain the user's name, right? Nobody is ever going to put a SQL query or a JScript statement in that field... are they?

But I want to talk a bit today about users inherently trusting data, and how it's just as bad. I'll eventually talk about Excel and some of the cool new stuff we're doing with VSTO 2.0, but let's start a bit smaller than that.

And a bit less techy.

Imagine you're a caveman (or woman) and you've just discovered how to cultivate crops. You have two fields of corn ready for the winter, and one day your neighbouring caveman comes by and says "Ugh, me see sabre-toothed tiger nearby. Ugh. You hide in cave, ugh, and me go fight tiger. Ugh-ugh?" Being very afraid of sabre-toothed tigers, you are more than happy to let your neighbour go off and fight it while you roll a big rock over the entrance to your cave and hide away in fear. The next day you roll back the stone and emerge, only to find that all your crops have been pillaged and your neighbour is no-where in site. Congratulations! You just fell for the world's first matchstick man!

Fast-forward to the (very) late the 20th century. You're sitting at work looking through your e-mail, when the subject line "HOT STOCK TIP!" catches your eye. You've always wanted to make a killing on the stock market (and quit your crappy job) so this could be the answer to your prayers! You read the message and jump onto your E*Trade account to buy up as much of the stock as you can. Three days later the stock is unlisted and you're left penniless on the street. Oops!

There could be an infinite number of examples here -- the basic problem is that you are acting on information furnished to you by people whom you should not trust. I gave these examples (and will give a few more) mostly to placate any fears that what I am about to describe is a new problem that we are introducing with VSTO 2. Nothing could be further from the truth; it is just that VSTO 2 will provide many amazingly cool features that, like all features, can be used for good as well as for evil.

You have been warned :-)

Let's talk about using Excel to implement an expense report (a common scenario we use here at Microsoft) and how that can be abused by untrustworthy employees. We'll start off with an expense report that doesn't use any kind of code (VSTO, VBA, whatever) although it does use formulas. The expense reporting process is as follows:

1. The employee fills out an expense report and e-mails it to their manager

2. The manager approves the expense report and e-mails it to the payroll department (obviously they could also choose to reject it)

3. The payroll department receives the report and reimburses the employee with their next pay cheque

Note that in these scenarios I will only focus on the employee trying to abuse the system to get more money than they should; in a real system you would also think about all the players that could be trying to abuse the system -- the manager, the payroll employees, the vendor who wrote the payroll system, etc. -- and all the things they might try to do -- steal money, block legitimate payments, and so on.

The problem in this case is that the manager accepts an expense report from the employee and approves it or denies it simply by looking at the values in the cells. But those cells were under the control of the attacker (the employee)! Let's say the employee recently took a client out to lunch and is claiming a fairly reasonable $100 for it. This sounds good to the manager, so she approves the request and sends it on to the payroll team. Unbeknownst to her, the $100 in the expense report was not a static value added by the employee, but rather a formula that would change to the fraudulent amount of $1,000 when viewed by the payroll employees. The payroll guys see the value for $1,000, verify that it was approved by the manager, and promptly over-pay the employee to the tune of $900.

Note that using digital signatures or other "security" technologies wouldn't have helped here; the manager would just have signed the spreadsheet containing the formula. In fact it may have increased her liability because she can no longer claim that someone spoofed her e-mail account and sent the dummy report -- after all, it was signed with her private key!

About the only thing the manager could do in this case (short of performing a full audit on the spreadsheet) would be to take a new, known-trustworthy expense report template and manually re-key the employee's data into the spreadsheet so as to ensure no trickery was underway. This of course is a colossal waste of time, so nobody is going to do it. Of course they could also copy the entire spreadsheet and paste it back on top of itself with the "values only" option, but then it might break other parts of the spreadsheet (like the =SUM() field at the bottom). Basically, it's a big hassle.

(Oh, and in case you think this is a problem with using Excel and it's auto-magic formulas, imagine that the expense report is a plain text file written in Notepad. The manager gets an expense report from her employee and sees the single line item "Lunch with client: $100" and sends it on to payroll. Unbeknownst to her, the employee simply added fifty blank lines after the first item and added "Ticket to the Caribbean: $5,000" to the end, knowing full-well that the payroll system will not be fooled by blank lines and will pay out for both line items).

The reason I brought up VSTO 2 earlier on was that Eric and Eric (and the rest of the team) have been making data-binding and data-centric programming and server-side access to data so easy and powerful in Excel that I fear people will throw themselves into this cool new technology head-first and never stop to realise all the horribly bad assumptions they are making. Does the cached data your server-side component "see" have anything to do with the spreadsheet itself, or did the user hack it with a binary editor before e-mailing it to you? Does the TotalAmount named range still refer to $C$10, or did some nefarious employee move it to point to $D$20 instead? Has the user filled the "real" worksheet with bad data, hidden it, and then replaced it with a spoofed (look-alike) worksheet with benign data intended to fool other users? Did the user open your spreadsheet without the managed code executing, thereby bypassing any client-side validation functions you used to vet data before submitting it to a server system?

The solution to the problem is, of course, to ensure that the only thing the employee is in control of is the data, not the way it is presented or the behaviour of the program. And thankfully the great work being done on VSTO 2 helps you out here; you just have to know how to use the tools effectively. There are two fairly obvious solutions to this problem of the employee being in control of the cells in the spreadsheet:

1. Utilise a trusted third party (often a server) to perform the "copy and paste" operation noted above

2. Utilise a trusted UI (not under the control of the attacker) for displaying and confirming the values in the spreadsheet

You can probably think of other ways, too. (Note that here we assume the attacker does not have any control over the code you are executing on your machine; they only have control over the spreadsheet).

The first solution is (to me) the coolest, and it uses the VSTO 2 technology quite well. Instead of the 3-step process above, we build a more complicated (but less prone to abuse) process that uses a web site to help "cleanse" data:

1. The employee fills out an expense report and submits it to the server

2. The server strips out the data from the expense report, stores it in a database, and sends a notification to the manager

3. The manager clicks on a link to the server, which extracts the data from the database, shoves it into a brand new expense report template, and serves it up to the manager

4. The manager approves the expense report and submits it back to the server

5. Repeat steps 2-4 for the payroll people

In this scenario, the manager (and the payroll people) are guaranteed to see exactly the same data that the back-end processing system will see, because the Excel spreadsheet (which in the past may have held nasty formulas, hidden sheets, re-directed named ranges, etc) is never propagated from one user to another. The employee can dork with the expense report all they like, but they will not be able to get away with the same attack; when they submit the report to the server, they will get an error if they have placed formulas where numbers are supposed to be, and no matter how much they try and spoof the UI of the spreadsheet to make it look like it is for $100 when it is really for $1,000, the manager will see the true value of $1,000 and not approve the report (and hopefully fire the employee). You might realise that this is the way most web sites work, and you'd be perfectly correct; we're simply using the power of the Excel client to make the data entry and data viewing experiences better. It breaks down if you don't have a trusted server, or you need off-line support, or if for whatever reason your current process inherently relies on people e-mailing stuff to each other.

The second solution can help here. At its heart, this solution leverages the rich Excel user interface for the data entry portion (the employee), but completely bypasses it for the validation / approval portion (the manager / payroll clerk). The process is modified thusly:

1. The employee fills out an expense report and e-mails it to their manager

2. The manager opens the expense report, reviews the data inside a custom-built dialog box, approves the expense report and e-mails it to the payroll department (obviously they could also choose to reject it)

3. The payroll department receives the report and reimburses the employee with their next pay cheque

In this scenario, when the manager indicates their desire to approve the expense (by clicking a button, etc.) the solution gathers up the data from the spreadsheet (the same way that the server would do in the previous example) and shows it to the manager in a "trusted" user interface such as a data grid inside a modal dialog, or (dare I say it?) inside the "Document Actions" pane. The manager then ignores what is in the Excel cells and makes their decision based on the numbers inside the trusted UI. (They will most likely look at the original expense report anyway, just to see what the expenses were for, but they need to make their decision on the value shown in the dialog, not the one shown on the spreadsheet). Just to make doubly-sure there is no deception going on, you could require the manager manually insert the total amount into a "Verify amount" field on the spreadsheet before submitting it.

Update 12-04-04

Having a policy such as "No direct manager can approve expenses over $500" would also help here, because even though the manager would see an expense for $100, the system would see $1,000 and flag it as a policy violation. Now of course the manager would then complain about the stupid computer system messing up again, but hopefully someone would track down the discrepancy, ferret out the fraudulent employee, and fix the system so that the same kind of thing didn't happen again.

What this shows is that technology is not a panacea to solving security issues. Technology has no concept of morality and can be used for good as well as for evil. Having solid designs for your solutions and building quality threat model for them will help you way more than throwing random technology buzzwords at a solution. User education and having good policies & procedures goes a long way, too.

Oh, and hiring trustworthy employees (and keeping them trustworthy by treating them well) is also incredibly important.

Another VSTO Blogger

ptorr — Mon, 05 Apr 2004 22:41:00 GMT

Eric Carter has started blogging! That makes two out of our three Erics on the VSTO team blogging.

Eric Carter works on building the next-generation programming model for VSTO 2 and doing an amazing array of other really cool things. And if you happen to spill salsa all over your sweatshirt at a Mexican restaurant and then try to wash it off in the bathroom, he'll even hang it out to dry for you in the sun. What a guy!

Eric and I famously disagree on just about everything we talk about internally. He even sends me random web links throughout the day to distract me from coming up with any more crazy ideas about the next version of our tools :-)

OK, OK, I disagree with just about everyone on the team except Andrew. And sometimes John (who should probably be blogging but isn't). Maybe it's me?

Anyway, let's see if this whole blogging thing is big enough for the both of us ;-)

Oh and I should have some more real content up here soon... I've been battling my RSI lately so I've been trying to avoid too much typing. :-( Julie and Jennifer both recommend Ashtanga Yoga, which I will have to try. Anyone recommend a good place on the East Side (Redmond / Kirkland / Bellevue / etc) to do it?

Evidence is important, even if it grants no permissions

ptorr — Mon, 22 Mar 2004 03:15:00 GMT

In a comment to my old VSTO security blog entry, Enrico Sabbadin asks why we can't just remove the Zone evidence from an assembly before creating the AppDomain. Good question, and Siew Moi bugged me about blogging this a long time ago as well, so I guess now is as good a time as any (it's a blogging kind of weekend...)

Let's start with an analogy (oh boy do us geeks like our analogies):

Say Microsoft designed cars, and.... no wait, wrong analogy.

Say that in order to get a driver's license, you have to be at least sixteen years old and have good eyesight. (Replace "sixteen" with whatever makes sense in your neck of the woods). It is hopefully pretty clear that you must meet both requirements to get a driver's license -- we don't hand out licenses to twenty-year-old blind people, and we don't hand them out to six-year-olds with 20/20 vision, either.

Aside: I've always wondered whether it was "driver's license" (a license belonging to the specific driver), a "drivers' license" (a kind of license applying to all drivers) or just "drivers license" (a generic term with no connotation of ownership). The Washington DOL simply refers to it as a "driver license" -- perhaps they couldn't figure it out either?

Let's say you're the clerk filling out license forms at the licensing office, and the form looks something like this:

[ ] Applicant is at least sixteen years old

[ ] Applicant has good vision

Now some PFY comes into the office to get a license and you start to fill out the form. The youth hands you their birth certificate and their latest medical report from the optometrist (their evidence) and you have to fill out the form.

Question: Since being sixteen isn't (by itself) a good enough reason to get a license, should you as the license-application-filler-outerer ignore the youth's birth certificate? Surely since the evidence grants no permissions, it is unnecessary? Right?

Wrong.

Evidence is critically important! You should never throw away any evidence, even if in and of itself it doesn't appear to buy you anything. If you've ever watched any movies or TV shows involving police investigations, you should know this :-)

Just to make it painfully clear why this is unacceptable, let's say you've been working at the license office long enough to figure out a time-saving optimisation: As soon as you fail to check any check box in the form, you know that the applicant will not be eligible to get a license and so you terminate the application without asking any more questions. So if you ignore the birth certificate, you won't check the "Applicant is at least sixteen years old" check box and will send the youth back home without a license even though they also had the optometrist's report.

And they you'll get sued <g>

It's the same in the CLR. Let's say that instead of the application form with the two checkboxes, you have policy like this (look familiar? :-) ):

LocalIntranet Zone: Nothing

ACME Corporate Key: FullTrust

Now VSTO tries to load an assembly from http://appserver/ that is signed by ACME Corp's key.

As is hopefully clear from the above discussion, we can't throw away the LocalIntranet zone evidence -- even though it grants no permissions -- because if we do we'll never evaluate the ACME Corporate key and thus fail to load the assembly.

Balancing Security and Usability

ptorr — Sun, 21 Mar 2004 05:58:00 GMT

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:

if (publisher.Diposition == Disposition.Good)

InstallAndRunCode()

else

CallTheFBI()

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.

Stalemate.

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!

The Amazing Disappearing Templates Act

ptorr — Sun, 29 Feb 2004 12:11:00 GMT

As reported in the VSTO Newsgroup (can't...find...link) and on Julie's blog, if you try and access ThisApplication.Templates.Count from VSTO, you end up with only one (Normal.dot) instead of the n (where n > 1) entries you were expecting.

I finally got off my lazy body part and did a quick test, and the explanation / solution is pretty simple. It seems that when you boot Word with a document on the command line, it doesn't open any templates in the STARTUP folder. Since this is how VSTO launches your projects for debugging (winword.exe c:\path\to\your\document.doc) you only ever see one template.

Just to prove to the non-believers that it wasn't some voodoo CLR magic that made the templates disappear <g> I also verified this with VBA, and VBA only sees one template in this scenario too.

If you boot Word normally (from the Start menu) and then manually open the document, everything works fine. You could also modify the Project Properties of your solution to just boot Word when you start debugging, and then manually open the document (which should be in your MRU list, anyways).