HD DVD / Randomness... : Visual Studio

Sliced bread ain’t got nuthin’ on this!

ptorr — Tue, 02 Oct 2007 21:49:21 GMT

Forget being the best thing since sliced bread – this is the best thing ever. Well maybe not quite that good, but it's still darn cool!

Finally – FINALLY! – you can get decent IntelliSense for JScript inside Visual Studio!

Holy hotcakes, Batman! This is so awesome you have to download Visual Studio 2008 Beta 2 right now and try it out.

Back when I was on the script team, we couldn't get any features into Visual Studio (much to the chagrin of our customers) because all the hype was around ASP.NET. The rich client was dead. It was all about the server. Nobody needed client-side script any more. Everything was a web form post-back.

But now that AJAX and Silverlight and all these other buzzwords are suddenly important, people taking notice of the little script language that could.

Congrats and thanks to the Visual Web Developer and JScript teams – at last, JScript is getting some of the respect it has always deserved! :-)

Inheritance Demands for Interfaces

ptorr — Sun, 16 Jan 2005 08:27:00 GMT

I'm cheating here by re-posting an e-mail I sent the other day... but hey, you don't expect me to come up with new content for this blog do you? :-)

Here is a deliberately contrived example of why you might need to protect interfaces with inheritance demands.

Say I have declared an interface, IWhichFileShouldIDelete, that has a single property string FileName that returns the name of a file to delete.

I also have a fully-trusted object, FileDeleter, which has a FileToDelete property and a DeleteFile mehod. The FileToDelete property takes an IWhichFileShouldIDelete object that is then queried in the DeleteFile method. (I already said this was contrived, right? :-) ).

The problem with this design is that the way in which the interface / object interact allows partially-trusted code to delete sensitive files. This is because the actual implementation of the FileName property doesn't require any special permissions (it just returns a string), and when the DeleteFile method is called there is no code from the IWhichFileShouldIDelete object on the stack, so any stack walks for FileIOPermission will succeed. This is bad because now partially-trusted code can cause random files to be deleted.

As an example, you might have code like this:

// Inside fully-trusted code...

IWhichFileShouldIDelete file = new GetTheFileName(); // See below

FileDelete deleter = new FileDeleter()

// Here is where the design falls apart...

deleter.FileToDelete = file;

// Note the call-stack will be 100% FT code at this point

deleter.DeleteFile(); // Deletes c:\boot.ini -- Ooops!

// ----------

// Assembly boundary

// ----------

// Inside partially-trusted code...

class GetTheFileName : IWhichFileShouldIDelete

{

public string FileName { get { return @"c:\boot.ini"; } }

}

In this scenario, the IWhichFileShouldIDelete interface should only be implemented by fully-trusted code, because only fully-trusted code should be able to say which files are deleted. To ensure that only fully-trusted code can implement IWhichFileShouldIDelete, you have to put an inheritance demand on the interface itself for unrestricted permissions (or maybe just unrestricted File I/O). This is necessary because the CLR's security system is based around code (stack walks), not information (data flow analysis).

A really cool (but most likely completely impractical) thing to add to the CLR would be a "forward" demand -- "Make sure the code that I am about to call has such-and-such a permission" -- to complement the current "Make sure the code that called me has such-and-such a permission" we get from normal demands.

For now, the best we can do is to make sure bad people can't implement methods that they shouldn't be allowed to, and we can accomplish that with inheritance demands.

Changing Abstractions in an Object Model is Hard

ptorr — Sun, 19 Dec 2004 04:29:00 GMT

Up until recently, I was working on a rather large spec for an as-yet-un-announced product. The majority of the spec consisted of class definitions and the details surrounding their interactions, but there was also a rather large conceptual component to the spec as well; you can't really dive into 50+ pages of object model specifications without knowing about the kinds of abstractions involved, how the different pieces fit together, and so on. I also spent time on a 30+ page threat model for the feature, but that's another story :-)

Anyway, I can't talk about this feature specifically (because it's not announced yet), but let's pretend the spec was for an object model for a car. When deciding how to design an object model for something complicated like a car, there are a lot of things you need to consider, such as:

·How accurately do you want to represent the modelled object?

·How easy do you want it to be for "typical" developers to use?

·How extensible does it need to be for "advanced" developers to customise?

·How performant / version-resilient does it need to be?

·And so on

In particular, you can probably tell right off the bat that the first two considerations are at odds with each other -- to accurately model a car, you would need to have objects representing every component of the car, perhaps even including the individual nuts and bolts holding the thing together (or, depending on the task at hand, maybe even the types of materials from which those nuts and bolts were fabricated). But to make a car object model easy to use, you want to simplify (abstract away) many of the details so that the developer has less concepts to understand (after all, they're a computer programmer, not an auto mechanic) and so that they can "discover" and use the features of the object model in a natural way.

For example, we'd rather write:

myCar.Color = Color.Red

than, say:

myCar.Body.Panels.Exterior.PaintJob.MajorColor = Color.Red

But on the other hand, we'd also rather write:

myCar.Tyres.Width = 18

than, say:

myCar.TyreWidth = 18

when you consider all the other properties of tyres that might be desirable.

So before you start designing the object model, you want to decide on your major abstractions (well, actually it's more of an iterative process, but anyways...). What details are necessary (the colour of the car), and what details can be glossed over (only the outer panels are painted)? What pieces of functionality can be logically grouped together (make and model of car), and what pieces need to be separated (car colour and tyre width)?

Now one of the abstractions we decided to make in this particular spec was something akin to saying that a car and its engine were one and the same thing. You couldn't have a car without an engine, and you could only have one engine in your car. Additionally, there weren't really any interesting properties of the engine (in our scenarios) so it didn't make sense to split off a separate Engine type. Nevertheless, there were still a few interesting things about engines that we needed to expose (like the Start method or the Stalled event) that we attached to the Car object.

Put another way, when speaking in plain English about their cars, people tend to say things like "I started my car" or "My car stalled the other day," rather than "I started the engine in my car" or "My car's engine stalled." Mapping object models to the way people think about The Real World is often more important than actually modelling The Real World.

So we have a design around one engine per car, and the world is a happy place. But then Someone Important says we have to support the new "hybrid" cars in our design -- those that have both an electric motor and an internal combustion engine (like the Toyota Prius or the Honda Civic Hybrid). Now, we've always known that hybrids existed, but we deliberately kept them out of our original design because (i) they are an edge-case scenario and (ii) they overly complicate the design for the rest of the users. (We like to have a "pay for play" approach at Microsoft -- you only pay the tax for advanced / complicated features if you want to use them. Never make the simple case overly complicated just to support some bizarre non-standard scenarios unless there's no other way around it).

So, we grudgingly add Hybrids to our model. And to be safe, rather than move from one engine to two, we abstract a bit more and say that you can have a collection of arbitrary types of engines with an arbitrary length. Need thirteen engines in your car? No problem. And we also need to make our concrete Engine class (which was an internal implementation detail of the old code) into a public IEngine interface that anyone can write a custom implementation of. Need an engine that channels psychic power into kinetic energy? No problem!

Now we can have a PetrolEngine class and an ElectricEngine class and stick them both inside a collection of IEngine objects inside a single Car object. Cool!

But there is a problem: what happened to the object model?

In the simple (non-hybrid) case, we go from:

myCar.Start()

to:

myCar.Engines[0].Start()

and in the more generic case we go to:

for each (engine in myCar.Engines)

engine.Start()

But realistically, what will happen is that developers will always use the first code snippet. Why? Because all the cars in their system will only ever have one engine, and the for each loop just looks ugly. Why loop through a collection that only has one element? And the program will work fine -- maybe for years -- until the first time someone plugs a hybrid into the system and it crashes [hah, a pun!] because the second engine isn't started.

The other (more important) thing is that we don't actually know how hybrids (or future variations thereof) will work. Do we really want to start both engines at the same time? Or do we want to just ask the hybrid to "start" and have the engines communicate with each other and decide when each one should kick in? What we need is another abstraction over the basic "collection of engines" that hides this detail. But since we don't know how the engines work, we must define some abstract interface that allows us (the car object model builder) to provide the developer (object model user) to deal with engines in an abstract way, whilst allowing the engine providers to plug in whatever features they need to make their engines work.

So now we have another new interface, IEngineCollection, that exposes things such as the Start method and Stalled event and provides some way for interested clients to dig deeper into the individual IEngine elements of the collection if they need to. We then provide a default implementation of IEngineCollection that supports a single petrol engine and simply forwards all the interface members on to that engine. We might call it SinglePetrolEngineCollection or some such thing, and have a nice easy way for clients to get an instance of it (or even just assume it's the one they want if they call the default Car constructor and don't supply their own implementation).

Manufacturers of hybrids can supply their own custom IEngine implementations (one for the petrol engine, one for the electric engine, one for the Mr. Fusion engine, etc.) and then their own IEngineCollection implementations that do clever things inside the Start method to decide which engine(s) to start, and so on. Then when users want to create hybrids they simply use the Car constructor that accepts a custom IEngineCollection implementation, and they're good to go.

Now to get rid of the "complexity tax" we can put back our original Car.Start method, which is just a simple wrapper that defers to Car.EngineCollection.Start, and the developer who just wants to start the stupid car can do so without worrying about multiple engines or about writing bugging code based on bad assumptions.

So why didn't we do this in the first place? We knew the problem existed, and there was a way to solve it that still followed the "pay for play" model.

One answer is that basically you don't want to make your system more complicated than it needs to be. Complications lead to bugs, and unnecessary complications lead to unnecessary bugs. Having lots of "pluggable" components (interfaces, abstract classes) makes it hard to reason about the system (and to threat model it!) because you can't be sure what any given extension will do. Allowing multiple, non-communicating developers to change the heart of the system also leads to reliability problems and other concerns that can't be tested or fixed by the OM developer (the AcmeEngine and the ContosoEngine both assume they have exclusive access to the fuel tank and don't co-ordinate their accesses to it, for example).

Another answer is that although we have hidden the complexity at a source-code level, we still have to expose it at the documentation level. The developer only needs to write myCar.Start to start her car, but if she ever looks at the documentation for the Start method she will be rudely yanked into a world of engine collections and layered abstractions and other such nonsense that she really has no desire to know about. Or, if she is just getting started with the object and starts to read the conceptual overview, there will be far too many things obscuring the basic design that she won't be able to see the forest for all the trees. This is a real concern, since documentation is incredibly hard to write and minimising the number of concepts a developer must grasp to use an object model is crucial to making it usable.

So I'm not sure what the point of this post was... ;-) Maybe it helps explain some of those really complicated Microsoft APIs where everything is an abstract interface and there are fifty different moving parts, none of which you really need to understand to use the API, but you're confused by them anyway.

Or maybe it just re-enforces the notion that you really should lock down your scenarios before you start designing, and then hope to %DEITY% that the Important People don't change their minds half-way through ;-)

Tin Foil Hat Tool

ptorr — Mon, 26 Jul 2004 11:22:00 GMT

Based on some of Nicole's feedback, I decided to write a basic app that checked your .NET security settings for you -- kind of like a very basic version of the Windows XP SP2 "Security Centre" tool which pops up and annoys you if you don't have the firewall or Automatic Updates turned on. (Whilst I disagree with Nicole's opinions on the role of CLR security, I do agree with her that we need to keep users more informed about the state of their machine).

Anyway, you can get the source for the app as a UUEncoded blob (I really need to organise some place to host binaries...). Copy the contents of that page (not including the menu, comments section, etc.) into a text file and save it with a UUE extension. Then open the file with WinZip or an archive utility of your choice and extract the contents somewhere on your machine.

Build the solution and copy the two output EXEs into the same folder. Then run CasHealthMonitor.exe and behold its unrivalled suckiness. Play around with CAS and make some "dangerous" changes (eg, caspol -en -cg 1 -levelfinal on) to see what happens (you'll have to wait a few seconds). Then immediately revert your changes (caspol -en -cg 1 -levelfinal off) to reduce the chances of your machine being hacked.

Some notes:

·This application doesn't prove anything; all it does is show you coloured tin foil hat icons depending on what the CLR reports for the various security zones, but there are various ways to spoof this (see below)

·I hate the way Notify Icons are implemented in the CLR. So many bugs / annoying behaviours

·I really wish I could have a proper Balloon notification window (see previous point)

·The app could be extended to use a config file mapping arbitrary evidence to arbitrary expected permissions (eg, you could map \\server\foo\bar to FullTrust and make sure it was doing OK)

·Don't run this app on your production machines (all the usual disclaimers apply)

·The code is ugly; I'm not a Windows Forms coding expert

·In fact, I'm not any kind of coding expert

How it works:

Every ten seconds or so, the app spawns a little helper process (casstate.exe) that spits out some basic security information to stdout (it has to do this because policy is never reloaded by a process). This output is captured and parsed and the results are displayed in the tray icon / list view. The helper process checks a few things, but they aren't foolproof:

·It checks if CAS is enabled, but a trojaned CLR install could lie about this state

·It checks to see if each Zone is using the default permission set for that zone, but a badly / maliciously configured system could have changed the contents of the Internet named permission set to be the same as FullTrust and this app would be none the wiser

Although I really don't think there's much value in this app, maybe you can learn a bit about resolving policy groups or something from it. Or, more likely, you can learn how NOT to program a system tray application in Windows Forms.

I wonder if Whidbey is any better...?

RequestRefuse and RequestOptional example

ptorr — Wed, 21 Jul 2004 13:13:00 GMT

Dave asks for an example of how to use RequestRefuse and RequestOtional. Here's my attempt to post a short blog entry that describes it (luckily I had the code already at hand... ;-) ).

The code consists of two libraries ("Optional" and "Refuse") and a main program for accessing them both. Basically just copy each bit of code into the right file, run build.bat and then run main.exe.

The "Optional" file has the following declarations in it:

// Let us show MessageBox windows

[assembly:UIPermission(SecurityAction.RequestMinimum, Window=UIPermissionWindow.SafeSubWindows)]

// Nothing else is required

[assembly:PermissionSet(SecurityAction.RequestOptional, Name="Execution")]

As you can see, it requests the ability to display "safe" windows (MessageBoxes and the like) and says that Execution is optional (and since Execution is always granted by RequestOptional, this basically means that nothing else is required).

The "Refuse" file has the following declarations in it:

// Let us show MessageBox windows

[assembly:UIPermission(SecurityAction.RequestMinimum, Window=UIPermissionWindow.SafeSubWindows)]

// Refuse access to the Environment

[assembly:EnvironmentPermission(SecurityAction.RequestRefuse, Unrestricted=true)]

As you can see, it requests the ability to display "safe" windows (MessageBoxes and the like) and says that it refuses to access the Environment, even if policy grants it that permission.

The main program then simply tries to run a handful of (identical) methods on an object from each assembly, some of which will demand specific permissions:

Console.WriteLine("\r\nBasic execution:");

try { Console.WriteLine(t.ReturnAString()); }

catch (Exception ex) { Console.WriteLine(ex.Message); }

Console.WriteLine("\r\nMessageBox:");

try { t.ShowMessageBox(); }

catch (Exception ex) { Console.WriteLine(ex.Message); }

Console.WriteLine("\r\nEnvironment:");

try { Console.WriteLine(t.GetUsername()); }

catch (Exception ex) { Console.WriteLine(ex.Message); }

Console.WriteLine("\r\nFile IO:");

try { Console.WriteLine(t.ReadFile()); }

catch (Exception ex) { Console.WriteLine(ex.Message); }

If you have done everything successfully, you should see that code using RequestOptional fails to run both the GetUserName method (which needs EnvironmentPermission) and the ReadFile method (which needs FileIOPermission), whilst the code using RequestRefuse only fails to run GetUserName because it explicitly refused EnvironmentPermission but was still granted FileIOPermission.

The "Optional" code is therefore less susceptible to luring attacks because it can't do anything except execute and show MessageBox windows (even by accident), whereas the "Refuse" code could theoretically be tricked into doing anything other than accessing environment variables (yes, this is a very convoluted example ;-) ).

Everett SP1 Tech Preview and VSA / VSTO

ptorr — Mon, 19 Jul 2004 02:25:00 GMT

Updated information about VSTO below

As you may know, the .NET Framework 1.1 ("Everett") Service Pack 1 Tech Preview is available for download. You should try to install this on your non-production machines and test to make sure your existing applications continue to run. Please report any problems you find to the .NET Framework Tech Preview newsgroups.

Just a quick word of warning though:

I wasted about 5 hours the other night tracking down a "bug" in a brain-dead simple VSA host app I had built. Turns out that whilst the JScript engine works flawlessly (of course :-) ), the VB VSA engine doesn't work in the Tech Preview. Basically any attempt to call IVsaEngine.Run will result in a "The parameter is incorrect" error due to a communication problem between the native and managed code portions. It will apparently be fixed for RTM.

Update Monday 19th July:

It turns out that VSTO 2003 is also affected by this same problem, but in a different way. VSTO customisations will run OK with the Tech Preview, but they may not get unloaded when you close the associated Word or Excel document. This means that if you hook application-level events, or you run code off a timer, or perform some other actions that can get triggered by things outside the scope of the document, your code may continue to run and receive these notifications even when the original file is closed. Closing down the host application will of course unload the code correctly.

This message brought to you by the number '4' and the letters 'F' and 'S.' You figure it out ;-)

Developing as Non-Admin

ptorr — Sun, 21 Mar 2004 07:10:00 GMT

Keith Brown writes a comment in one of my older posts about a chapter in his book dealing with developing code as a non-Admin. A great read if you're still one of those people running as an Administrator because you think you need to in order to do programming. Maybe you should buy the book if he ever gets the link working :-)

One addition: you can run Windows Explorer (and the related control panel applets) from your Admin account as long as you've set the "Run Explorer windows in a separate process" option from the admin account. Run regedit from your Admin console, navigate to:

HKEY_CURRENT_USER\ Software\ Microsoft\ Windows\ CurrentVersion\ Explorer\ Advanced

and set the SeparateProcess DWORD to 0x01.

Developers frustrated by Administrators

ptorr — Sun, 07 Dec 2003 00:57:00 GMT

A link on Slashdot points to a rant about why one developer thinks that administrators are the scum of the earth. There are some good counter arguments on the comments page.

It's interesting because we spend quite a bit of time at work trying to make sure that the products we design for developers will actually be sanctioned by administrators. There's no point in building the world's best enterprise development tool if nobody is allowed to install it.

Getting most developer scenarios to work as a normal user in Visual Studio is one aspect of this ongoing effort.

VSTO Security Model

ptorr — Tue, 04 Nov 2003 00:10:00 GMT

I somehow (?) came across a blog where a customer wonders how VSTO tightens up security. That's an interesting story.

As many of you will know, Office already has a security model for VBA and COM Add-Ins that is based on two types of evidence (digital signatures and "installed" code) and a fairly simple run / prompt / don't run policy system. You can read more about these security levels in one of Siew Moi's articles.

The CLR also has a very rich, extensible security model based around evidence, permissions and policy. You can read more about it on MSDN, or perhaps look at Don Box's article (which I haven't actually read... it just turned up in a search result and I trust him to write good stuff ;-) ).

Anyway, when it came to defining the model for VSTO we knew we didn't want to invent a 3rd way of doing it, so we had to choose whether to use the Office model or the CLR model. Now in hindsight it may seem obvious to some readers that the .NET model was the only way to go, but we were very concerned about confusing existing Office developers with the new model and having them just turn off security altogether to "make it work," so we looked quite hard at integrating with the Office model. Nevertheless it had to be implemented on the CLR policy system, and whilst this was perfectly doable (did I mention the system is very flexible?) it would have been abusing the system somewhat...

So anyway, what we thought about was basically the following (you could even use this for a blueprint of your own model, if you really need to proxy trust decisions from a legacy system to .NET...):

1) Borrow from the digital signatures evidence that Office uses

2) Honour only the "High" mode (must be signed to run; never prompt for elevated privileges)

3) Use the Office trusted publishers list

4) Build our own TrustedOfficeMacro membership condition and evidence objects

Basically how it would work would be that we'd get a request to load an assembly and check if it had an AuthentiCode signature that was generated by a certificate in the Office Trusted Publishers list. If so, we'd load the macro with the TrustedOfficeMacro evidence (essentially "vouching" for the goodness of it). Otherwise, we wouldn't load it. We'd also rely on you having a rule in your .NET policy that granted FullTrust to things loaded with TrustedOfficeMacro evidence. Another thing we could have done (and probably would have done eventually, although it's not in the original spec) was that if the assembly was "installed" (in the Templates directory) and the user had the "Trust installed templates and add-ins" feature checked, we'd load the assembly with TrustedOfficeMacro evidence.

[Aside: When presenting this to people, many of them initially said "hey, that's a security hole -- anyone can claim to be loading TrustedOfficeMacro-s and get arbitrary code to run!" But of course in order to present evidence to the CLR, you have to be fully trusted yourself (or so close as it makes no difference) so if you could load arbitrary code with bogus TrustedOfficeMacro evidence, not only could you also load it with bogus Microsoft Strongname evidence, you could also just go ahead and do whatever bad stuff you wanted to do by yourself. The point being that whenever you're thinking about security problems, think about the preconditions required to execute the attack and move on if it's already "game over" (defence in depth techniques not withstanding... :-) )]

This kind of seems cool because if you have a lot invested in VBA or COM AddIn solutions, and you already have a code signing certificate that's trusted on all your machines, you could just move to .NET code and still have it run on all your users' machines without any configuration changes. Unfortunately it had some limitations, not least of which was that it didn't mesh at all with all the new .NET stuff, so if you wanted to write both WinForms and Office code you'd have two security stories to play with instead of just one, even if you never wrote a line of VBA in your life. Also handing out evidence at assembly load time is something you want to avoid if possible, since in general you will not be in control of subsequent assembly loads in the same domain (eg if the assembly links to a second assembly, then that assembly will automatically be loaded by the CLR as needed, and you don't get any say as to what evidence it should have).

So we decided 100% .NET was the way to go, but as I thought I'd mentioned before (but I can't find a link), we thought that the default .NET logic of "if it's on the local machine, you obviously installed it, and if you installed it you obviously trust it, so it should get FullTrust" didn't really work for Office documents, so we had to do something about it.

[This blog is already longer than I thought it would be, and I haven't even started to answer the question yet! Such is the way of the blogger]

The problem was how to get Office documents to ignore the default Machine-level rule that granted FullTrust to MyComputerZone, but left policy as-is for all other applications. Some ideas that floated (and were immediately shot down :-) ) were to simply modify Machine policy when you installed Office to lock down your machine, or to somehow cleverly modify policy just before you launched Office and then put it back again as soon as it had been cached in the app. But of course the first one would have broken every locally-installed app from here to next Tuesday, and the latter was a complete hack that was just not going to happen. Oh and you need to be an admin to mess with non-User policy, and normal users had to be able to run (and even develop!) VSTO documents.

It was clear we couldn't mess with persistent policy, but luckily the CLR folks were very clever and had the foresight to include AppDomain-level policy that let AppDomain hosts (like Office) tinker with policy to their hearts' desire. So there were some initial (again, very short-lived) plans to simply slap a static "MyComputerZone : Nothing" rule into AppDomain policy and be done with it. Great! No code would run from MyComputer. Unfortunately, this was an absolute statement -- no code would ever run from MyComputer - EVER! Because .NET policy is intersected between levels (Enterprise, Machine, User, AppDomain), even if someone had added a rule at Machine or Enterprise level to say "Code signed with ACME certificate : FullTrust", we'd blow that away with our more restrictive "Nothing" rule at the AppDomain level.

Back to the drawing board.

We had to honour any and all changes that users might have made to their policy, at any level, with arbitrary degrees of complexity. And not only did we have to preserve the rules themselves (ACME gets FullTrust), we had to preserve the hierarchy of rules as well (trusting ACME in the Intranet Zone is very different to trusting them in all Zones!). The only things we would throw away would be "implicit" or "generic" rules based on Zones (MyComputer, Internet, etc) and AllCode (which matches everything in existence). And herein lies the beauty / simplicity / wackiness of it all.

We copy all the code groups from all the other policy levels into the AppDomain, and kill off the ones we don't like.

So let's say you have a "typical" machine at ACME corp, with the following policy (simplified to only mention the MyComputer and LocalIntranet Zones):

Enterprise
AllCode : FullTrust

Machine
  AllCode : Nothing
    MyComputerZone : FullTrust
      ECMA Strongname : FullTrust
      Microsoft Strongname : FullTrust
      ACME Corp Publisher : FullTrust
    LocalIntranetZone : LocalIntranet
      http://coolserver/ : LocalIntranet
        ACME Corp Publisher : FullTrust

User
AllCode : FullTrust

This is basically the out-of-the-box policy, with some additional rules to allow code signed by ACME Corp to run off the http://coolserver/ machine and on the local machine. We then create an AppDomain policy that is the concatenation of those three levels, so it looks like this:

AppDomain
  AllCode : FullTrust
  AllCode : Nothing
    MyComputerZone : FullTrust
      ECMA Strongname : FullTrust
      Microsoft Strongname : FullTrust
      ACME Corp Publisher : FullTrust
    LocalIntranetZone : LocalIntranet
      http://coolserver/ : LocalIntranet
        ACME Corp Publisher : FullTrust
  AllCode : FullTrust

It looks funny because AllCode appears three times and can't make up its mind about whether to grant FullTrust or Nothing, but we don't worry about that. All the granted permissions at this level will eventually be union-ed together, so we can duplicate as many things as we want as randomly as we want.

Finally we "clean" out the AllCode and Zone groups so it looks like this (changes in bold; we'll have colour one day, I promise!):

AppDomain
  AllCode : Nothing
  AllCode : Nothing
    MyComputerZone : Nothing
      ECMA Strongname : FullTrust
      Microsoft Strongname : FullTrust
      ACME Corp Publisher : FullTrust
    LocalIntranetZone : Nothing
      http://coolserver/ : LocalIntranet
        ACME Corp Publisher : FullTrust
  AllCode : Nothing

Now we have preserved 100% the semantics of the user's "explicit" policy changes (trusting URLs, publishers, sites, etc.) but we've thrown away the "implicit" default policy of giving FullTrust to the local machine. Because of the way policy resolution works, the AppDomain level can never grant more permissions to code than would otherwise have been granted (it can only take them away), although at first blush it sometimes seems that the AppDomain policy can "leak" permissions, especially when you have a LevelFinal codegroup. But it all comes out in the wash.

To this day people still say to me "I don't know how this system works, and it looks really crazy, but it seems to do the job." And it does (at least I hope it does!). I spent most of the last 18 months or so worrying about this (along with many other things :-) ) and it's been through a bunch of testing and modelling and "desk checks" manually walking through the algorithm. Hopefully no-one finds any holes with it!

A final note on the development experience. The strict policy we made for Office documents was meant to protect end-users against accidentally running malicious software, so it made sense to lock everything down by default. But of course the developers building those applications probably do want to be able to run them, and in general they won't have access to (or won't want to use) code signing and won't want to mess with policy too much (because it's hard to get right, and they'd likely turn off security altogether to make their stuff work, which is a bad idea). So we needed a different story for developers.

We went round and round on possible solutions for this one for most of the product cycle. There were three main possibilities:

1) A machine configuration setting (regkey) to disable our policy

2) Runtime checks between Office and VS to disable our policy

3) Design time changes to policy to grant permissions to code

The first one sucked because it meant that a dev machine was wide open to attack. Just because the developer was doing VS development with Office and wanted to run their own code, that didn't mean we should leave their machine open to attack from malicious code. Devs sometimes open bad attachments too, you know ;-)

The second one was an improvement because it would only disable the policy if Office detected that a debugger was attached, and that the document being opened matched the one inside the debugger. This was cool because it meant that the dev machine was no longer wide open -- policy would be enforced for all documents except the ones the developer was actively debugging -- but it had another drawback. It worked if the developer hit F5 in VS (Run with Debugging), but would fail if the developer hit Ctrl+F5 (Run without Debugging) or if they ran their code from Explorer.

The third one (which we shipped with) ensured that developers could always run the code they built themselves, because we'd update their user-level policy to trust the output location of the VS project. This meant that you were still protected from random malicious code (unless you happened to save over the top of one of your own previously-trusted projects!) and it didn't rely on having the VS debugger attached. The main drawbacks were that it didn't work out-of-the-box if you developed on a network share (you can't trust network shares by modifying user-level policy unless an admin has already updated machine policy), it didn't work if you moved your solution after building it, and you could end up with hundreds of entries in policy over time as you built more and more solutions. <sigh> oh well, you can't have everything.

So there you have it. Many people think that the stuff that comes out of Redmond is just rubbish with no real thought behind it and with the only purpose being to make as much money as possible as quickly as possible and with no real concern for the user. Hopefully you'll see from my blog (and everyone else's) that this isn't the case. We think long and hard about all the features we ship, and we often have to trade off several different design ideas based on conflicting requirements, changing priorities, tight schedules, etc.

I'm the first person to admit that the VSTO policy is very draconian and, quite frankly, a pain in the neck for a lot of developers who just want their code to work. But I'll also be the first (and loudest) person to defend that design as being the only "right" choice for where we are today. (And if Siew Moi wasn't on vacation, I'm sure she'd be second in line :-) ).

Thoughts?

PDC Session on Office Development with VS "Whidbey"

ptorr — Thu, 23 Oct 2003 09:38:00 GMT

If you're going to the PDC in LA this year and you're interested in Office development, you should add Reza Chitsaz's session to your calendar (TLS346). He has some great content and some really cool demos showing the new stuff that will be coming out in the future. And we only just released VSTO 1.0 the other day! <g>

Mention this blog at the session and you'll receive a free... um... well nothing really. I don't have anything to give you. Sorry.

Mitigating Code Repurposing Attacks

ptorr — Wed, 22 Oct 2003 01:26:00 GMT

As I mentioned in a previous blog, there are some pretty creative (and destructive) things people can do with your code if you're not careful. Just as a kitchen knife can be used to cut cheese or to kill someone, so your code can be used to increase productivity or wreak digital havoc.

It's not all bad news though. There are several things you can do to help mitigate attacks based on code repurposing, although unfortunately there is no panacea and many of these techniques will not be applicable to all given scenarios. A much shorter article that mentions some key mitigating factors can be found in the VSTO documentation online. But if you've got a spare chunk of time, by all means read on.

Thanks to Siew Moi, Mike Howard, and the Office security folks for giving this a once-over before posting :-)

Root Cause

The root cause of repurposing comes from trusting input data. Michael Howard has a lot to say about this in Chapter 10 of Writing Secure Code 2nd Edition (aptly titled All Input is Evil), but in repurposing attacks it's not just your code that is trusting potentially bad data, it's the end-user, too!

With a typical web-based application, checking your inputs isn't so hard since you mostly need to worry about things like form fields, query strings, and HTTP headers. (You may also need to worry about any external systems you connect to, such as a database, if that figures into your threat model). In most cases, you can assume that the server your application is being hosted on is trustworthy, along with any other data on it such as configuration files, web page content, and so on.

The problem with Office-based development is that your code is hosted inside a very dynamic, very mobile container (the document), and in general you cannot assume that any part of that document's content is trustworthy.

Not the warning text you put in BIG BOLD WARNING TEXT at the top of the document.

Not the names or positions of the controls on the document.

Not the hidden worksheets where you store database connection strings.

Not the configuration settings you put inside a hidden region with white text on a white background in 1 point WingDings font.

Nothing.

So our goal is to do one or more -- always think of "defence in depth" --Â of the following things:

Eliminate our dependence on information inside the document
Ensure that the information in the document is trustworthy
Check that the information inside the document falls within a "reasonable" range
Provide cues to the user about the purpose of the code they are running
Elicit explicit user consent before performing potentially harmful actions
Probably some more things here!

So let's look at these in turn.

Eliminate dependence on untrustworthy information

In my previous blog, I used the example of a "Format my Drive" document that contained instructions for formatting your hard drive, along with Yes and No buttons that invoked the appropriate code. In this sample, the code doesn't make any decisions based on inputs (it has none), but the user does. The code assumes that the user will always be presented with adequate contextual information (eg, "clicking this button will format your drive!"), but this is not the case. The user has no idea that there is no link between the text surrounding the buttons and the actions the buttons take; they think if the text says "Download unlimited free MP3s now!" then that's what the button will do.

Oops!

So even in this case, the code implicitly trusts its "inputs" (the user invoking the code) and it should not be. Something as dangerous as a "Format my Drive" control should provide additional feedback to the user about the actions they are about to perform, as noted in one of the next sections of this blog.

It's also a good idea to think about the things you can depend on. Resources on the local machine, such as files or registry keys, should in general be trustworthy (see note below!). So should other servers that your code communicates with, as long as they are under your control. And of course you can trust your own code not to have been tampered with, as long as it is signed or living in a secure location.

NOTE: I said above that you can trust the local machine. This assumes we are trying to mitigate against repurposing attacks where one user sends a malformed document to another user in an attempt to get them to do something harmful to themselves. You cannot trust resources on the client computer in other scenarios, such as when you are building a server-side solution, because then a hostile client could be used to subvert your security system. Servers need to protect themselves from malicious clients, and clients need to protect themselves from malicious servers. Different scenarios call for different threat models and different mitigation strategies.

So if your solution needs to persist data such as user preferences or other snippets of information that you come to rely on, you can write it to the registry or to a config file (not in %ProgramFiles%, but in %UserProfile%) or use some other mechanism to persist it. Just don't persist it in the document, because then you'll never be able to read it out again without worrying about the contents.

Contacting servers is a bit trickier. You might want to contact, say, a trusted web service on http://myserver/ to download information, but if you hard-code that URL into your solution then you will have trouble when you need to move the service to another machine. The obvious answer is to stick the URL of the server inside the document... but you can't do that because it's not trustworthy! This is where you could do something like an Active Directory lookup to figure out which server to contact. I've been told it's possible, but I'm not an AD expert so you'll have to figure that one out on your own ;-).

Ensure the information is trustworthy

Let's say you absolutely have to rely on the information inside the document, for whatever reason. Now you have to make sure the content in the document is as trustworthy as your code itself, which means severely limiting what can be done with the document.

Two properties of code that makes it "easy" to secure in the CLR are that:

i) You can sign the code, which can be used to detect any modifications made to it

ii) You can keep it in a fixed location, which can be used to ensure nobody can modify / overwrite it

Unfortunately, neither of these two properties apply to documents in the general sense. The whole point of having document-based solutions is so that you can modify them (thereby making signatures pretty useless) and that you can send them around to people, copy them to your hard drive, and so on (thereby making location pretty useless). Nevertheless, depending on the scenario you may be able to do one of these things in your solutions.

Signing a document in Office 2003 is pretty easy -- go to Tools -> Options -> Security and click on the Digital Signatures button, where you can select one of your certificates and add your signature to the document. Once the document is signed, no-one can tamper with it in any way without breaking the signature, but as I mentioned in my Old Fashioned Security blog, there's a big problem with signing content:

Unless the recipient expects the document to be signed (and knows how to verify it), it doesn't really help you. An attacker will just remove the signature altogether and go on their wicked way

So either you have to educate all your users about how to inspect digital signatures, or you can do something about it yourself.

In Word, you can use the object model inside your code to check if the active document contains a signature, and if so if it is from the right person (ie, you) and if it is valid. Inside your startup code, you can do something similar to the following to ensure that your code is running inside a genuine document that you created (if Rob had finished the WordML to HTML transform by now, this would be in glorious Technicolor, but alas he hasn't so it's not):

  Private Sub ThisDocument_Open() Handles ThisDocument.Open

    Dim signature As Office.Signature
    Dim foundSignature As Boolean = False

    If (ThisDocument.Signatures.Count < 1) Then
      MessageBox.Show("This document is not signed.")
      ' Take appropriate action here...
      ThisDocument.Close()
    End If

    For Each signature In ThisDocument.Signatures
      ' Bail out early on invalid signatures
      If ((signature.IsValid = False) Or _
        (signature.IsCertificateRevoked = True)) Then
        MessageBox.Show("This document's signature is bad.")
        ThisDocument.Close()
      End If

      ' Add the appropriate strings here
      If ((signature.Signer = "ACME Corp") And _
        (signature.Issuer = "Verisign")) Then
        ' You could also check the sign date if you want
        MessageBox.Show("This document is signed correctly.")
        foundSignature = True
        Exit For
      End If
    Next

    If (foundSignature = False) Then
      MessageBox.Show("This document's signature is missing.")
      ' Take appropriate action here...
      ThisDocument.Close()
    End If

  End Sub

There's a bit of a chicken-and-egg problem here for both VBA and VSTO developers here, but for different reasons. With VBA, because the code is included in the document's signature you have to sign the document after you have written and tested your code. This could require you to build, test, and re-sign your document many times, or it could require you to have some kind of mode where the document ignores invalid signatures while in development (remember, this cannot be a flag stored in the document itself, but it could be a registry key you use to disable signature checking on your dev box). With VSTO, the assembly is built and signed independently from the document, but since the custom properties which link to the assembly form part of the signature, it is not possible to move the assembly after the document is signed, so that must be done as the final step before officially releasing the document.

This "problem" of having the code (or the link to the code) be part of the signature actually helps us prevent some attacks as well. Imagine, as outlined in my previous blog, that you have a Budget document and an HR document. Both documents are signed, and both assemblies are signed, but by some horribly bad coincidence, it's possible to point the HR document at the Budget code (or vice-versa) and do some damage to the document recipient. This will not work, since swapping out the code (or the link to the code) will break the signature. The only real attack possible here is if you can take over the URL at which the linked code lives, in which case you could replace the HR assembly with the Budget assembly. So you need to make sure your servers are protected from having unauthorised people uploading content!

One potential problem here is that the Signature object in Word only tells you the name of the signer and the authority that issues that certificate, but not the rest of the trust chain up to the root authority. It is possible (but unlikely) to have two signatures, both created by "Bob Smith" and issued by "ACME Corp Authority", but for them to be two different Bob Smiths issued from two different ACME Corp Authorities. (Thankfully you still have to trust the root authority, so it's not as if any old hacker could create such a hierarchy in order to fool your code, but it's something to keep in mind). Siew Moi has written a great article on Word signatures, and it includes a download that has some more code to play with.

Unfortunately, there is no programmatic support for checking digital signatures in Excel, so you cannot use this technique. Also, you may not have the money to buy a certificate from Verisign or Thawte or one of the other big vendors, and you may not have your own PKI servers with which to issue your own certificates. In this case, you can "tie" your document to a specific location, such as a trusted (and read-only) share on a server, or to a specific "install" location on the user's machine. (This is similar to how the SiteLock feature works for ActiveX controls). At startup, you can check that the document's location is where it is supposed to be, and take appropriate actions (such as closing the document) if the document comes from a suspicious location. This has the problem of baking URLs or other locations into your code, which means it's impossible to ever move the solution if you need to, so you may want to use a Registry key or Active Directory property or some other external (but still trusted) mechanism to figure out if the document is hosted in a secure location:

  Private Sub ThisDocument_Open() Handles ThisDocument.Open

    If (ThisDocument.FullName <> _
      "\\appserver\secure\myapp.doc") Then
      MessageBox.Show("This document is not secure")
      ThisDocument.Close()
    End If

  End Sub

Obviously if you require your document to be signed, that means the user can never actually modify it and then save it. And if you require it to be in a specific location, that means the user can't put it on their desktop or mail it to a friend. That's kind of a problem for most documents, since they are designed to be modified and saved and moved around. (I show a slightly less draconian version of this in the next section).

One way around this is to have your "document" act like a mini application hosted inside Word or Excel, and have it load and save its own "documents". This is made super-easy by the XML support in Word and Excel 2003, where you can import or export the XML content of a document to a separate file without actually saving all the markup and other stuff that makes up your "application". As long as your solution lends itself well to having only the data saved and loaded into your static template, you should be good to go -- just provide your own "Open" and "Save" mechanisms inside your document that load and save XML files that are pumped right into the mapped XML structure of your document.

Here's some sample code for doing it in Excel -- Word is harder since you can't automatically import XML into a Word document; you need to load the DOM yourself and insert text into each node of the document. For this simple solution, you can create a spreadsheet with pretty formatting, etc. and then do the following:

1) Map an XML Schema into the document (a really basic one follows if you need it)

2) Add a single Command Button from the Controls Toolbox toolbar. Open the Properties window for it and give it a name of cmdLoad. Delete the Caption so it is blank.

3) (Optional) Digitally sign the document with a certificate to prove that you can do this without modifying the content

Here's a simple schema you can map to a spreadsheet. Save it with an extension of .XSD

<?xml version="1.0" encoding="utf-8" ?>
<xs:schema id="simple"
  targetNamespace="http://tempuri.org/simple.xsd"
  elementFormDefault="qualified"
  xmlns="http://tempuri.org/simple.xsd"
  xmlns:mstns="http://tempuri.org/simple.xsd"
  xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="SimpleTest">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="FirstName" type="xs:string" />
        <xs:element name="LastName" type="xs:string" />
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

And here's the code you can use - just dump it into the default codespit of a VSTO solution, nuking the original ThisWorkbook_Open handler:

  Private WithEvents cmdLoad As MSForms.CommandButton

  ' Called when the workbook is opened.
  Private Sub ThisWorkbook_Open() Handles ThisWorkbook.Open
    InitialiseUI()
  End Sub

  Private Sub InitialiseUI()
    cmdLoad = FindControl("cmdLoad")

    If (cmdLoad Is Nothing) Then
      MsgBox("Document is corrupt!")
    End If

    cmdLoad.Caption = "Load XML"
    cmdLoad.AutoSize = True
  End Sub

  Private Sub cmdLoad_Click() Handles cmdLoad.Click
    LoadXml()
  End Sub

  Private Sub LoadXml()
    ' Gather the filename through a custom dialog, etc.
    Dim filename As String = "C:\temp\export.xml"
    ThisWorkbook.XmlMaps(1).Import(filename)

    ' Don't prompt user to save
    ThisWorkbook.Saved = True
  End Sub

  Private Sub SaveXml()
    ' Gather the filename through a custom dialog, etc.
    Dim filename As String = "C:\temp\export.xml"
    ThisWorkbook.XmlMaps(1).Export(filename, True)

    ' Don't prompt user to save
    ThisWorkbook.Saved = True
  End Sub

  ' Handle the Save event to just save the data
  Private Sub ThisWorkbook_BeforeSave( _
    ByVal SaveAsUI As Boolean, ByRef Cancel As Boolean) _
    Handles ThisWorkbook.BeforeSave
    SaveXml()
    Cancel = False
  End Sub

Another way to ensure that the information in the document is trustworthy without resorting to signatures or site-locking your document is to ensure that you create it all yourself, from within your code, and that you make it easily understandable by the user. For example, if you have a button on a Word document that will format the hard drive when it is clicked, don't just give the button a caption of Yes and rely on the surrounding text to explain what it does. A more descriptive caption, such as Format Drive C: will be much better.

And don't just set the Caption of the button using the property grid in Word or Excel, since that value can be changed by the attacker and is not stored as part of your VBA or .NET assembly. Even if your code is signed, the attacker can change that property and not invalidate the signature (it will invalidate the signature of the document, if it has one, but it won't invalidate the signature of the code). Instead, you should explicitly set the caption of your button during your initialisation code, so that it always says what you want it to say. This is what I did above in the sample Excel code.

Don't rely on automatically generating warning text into the document though (eg, injecting "This will format your drive!" in big red letters at the start of the document), since no matter what you do the bad guys will probably figure out a way of obscuring it (hiding the region, placing a white bitmap over the top of the text, etc.).

If you need more UI than you can get by putting captions on your buttons, then you need to implement some kind of form (see below) or <gasp> build an ActiveX control where you can display all your information in a reliable manner. If you don't have to have your control hosted directly on the document surface, a SmartDocument solution offers a really good alternative because the attacker has no way to influence what appears in the Task Pane. You can be sure that any warning text or other UI you place in the Task Pane will be there when the user runs the solution.

Another way to avoid "untrustworthy" callers in VBA is to make your methods Private (VSTO does not have this problem since there is no way through the Office UI to invoke managed code). If you are placing controls on the document surface, make sure you use ActiveX controls (from the "Control Toolbox" toolbar), not Forms controls (from the "Forms" toolbar). Adding an event handler to an ActiveX control creates a private method that cannot be invoked by any means other than firing the event on the named control, whereas the macros you assign to Forms controls are just public subroutines that can be hooked up to any old event source. Also, since Forms controls aren't programmable, you can't programmatically change their content (as described above).

If you are building CommandBars or menu items, don't use the Office UI to hookup event handlers, since again they must be public and hence repurposable (swap the "Save" event handler for the "Delete" one...). Instead you should build up the CommandBar programmatically (so you can set the text and images on each control as outlined above) and declare all your controls inside your solution WithEvents so you can handle the events with a private handler, not a public sub. There is some sample code for VSTO in this article, and the sample solutions that ship with the product also show how to create menus and toolbars. Some sample VBA code is below:

  Private WithEvents cmdSave As CommandBarButton
  Private WithEvents cmdDelete As CommandBarButton

  Private Sub Document_Open()
    CreateCommandBar
  End Sub

  Private Sub CreateCommandBar()
    Dim bar As CommandBar
    Dim i As Integer
    Dim oldContext As Object

    On Error GoTo Handler

    ' Delete any existing instances of the bar
    ' Must loop backwards since we're deleting items
    For i = CommandBars.Count To 1 Step -1
      Set bar = CommandBars(i)
      If ((bar.BuiltIn = False) And _
        (bar.Name = "My Bar")) Then
        bar.Delete
      End If
    Next

    ' Create our own temporary bar
    Set bar = CommandBars.Add("My Bar", , , True)
    bar.Visible = True

    ' Add new buttons
    Set cmdSave = bar.Controls.Add(msoControlButton)
    cmdSave.Caption = "Save"
    cmdSave.Style = msoButtonCaption

    Set cmdDelete = bar.Controls.Add(msoControlButton)
    cmdDelete.Caption = "Delete"
    cmdDelete.Style = msoButtonCaption

    ' Exit the sub
    Return

  Handler:

    MsgBox "CommandBar not created:" & _
      vbNewLine & _
      Err.Description, _
      vbOKOnly Or vbInformation, "Error"

  End Sub

  Private Sub cmdSave_Click( _
    ByVal Ctrl As Office.CommandBarButton, _
    CancelDefault As Boolean)
    MsgBox "Save clicked!"
  End Sub

  Private Sub cmdDelete_Click( _
    ByVal Ctrl As Office.CommandBarButton, _
    CancelDefault As Boolean)
    MsgBox "Delete Clicked!"
  End Sub

Check the information for "reasonableness"

Sometimes you really do need to rely on the information in the document. In WordBlogX, for example, I persist all the information about a blog entry (content, unique ID, creation date, etc) into a document, and then next time you load that document I suck it all back out again.

Oh No! I'm breaking all my own rules!

Well, here's where you need to take a step back and consider how the data is used (what's the worst thing that could happen?) and what kinds of reasonable limits you can place on the data inside the document. For example, if you have a budget spreadsheet that accepts a value for the current year's maximum budget, it probably shouldn't be negative and it probably shouldn't be more than ONE MILLION DOLLARS (or whatever is appropriate for your organisation). If there's simply no valid reason for such values, you should check for them and reject them -- building correct, robust software gets you half way to building secure software.

Same goes for (eg) embedded URLs -- if you have to embed a URL in the document, but it should only be one of 3 known servers, make sure it really is one of those servers. One common mistake in web programming is to use a <select> object to provide the user with a "fixed" list of options in the browser, and then to blindly accept whatever value the client returns in the server code. This is broken because users can send ANY values to your web server; they're not limited to the options shown by the browser UI. Office applications are no different (depending on the scenarios) -- just because you provide the user the convenience of 3 or 4 different options, it doesn't mean they can't inject their own.

Do you store dates in the document? Does it make sense to have a date outside of a relatively small range, such as today +/- a month? If not, then check for it and throw away the bad values. Are you expecting a range of 10 cells in Excel? Then don't just "loop until done" -- explicitly check for the 10 cells and if there are more or less then take some defensive action. Unfortunately in these cases developers (including Microsoft developers) often try and "help" the user by trying really hard to work-around all the errors the user makes, inferring things from partial information, and so on. But whilst this can help users in some situations, it usually comes back around to bite you when an attacker figures out how to fool your oh-so-smart algorithms into doing something unexpected.

In the case of WordBlogX, there's no real validation I can do on the document content (it's just arbitrary text) but I do check that the GUID is in a valid format and that the persisted date and time values are in a valid format. I could do extra work to check the GUID against some trusted store (eg, the Registry) but that complicates the solution and then I'd have a bunch of essentially useless GUIDs hanging around. Even if Rob gets the WordBlogX setup working, he could in theory delete the registry data when the program was uninstalled, but since it's probably considered "user data" we couldn't even do that. So the registry keys would live forever, and it would be impossible to move documents from one machine to another without also moving the regkeys. I should probably make sure that the Modified date is on or after the Created date, and that neither of them are in the future or the distant past.

I take the approach that I can be quite lax with WordBlogX in this instance because it's not protecting anything too valuable, other than my credentials to the web server. About the worst thing someone could do (other than steal my login) would be to send me a document with the GUID and creation date of an existing entry, and fool me into "updating" (ie, clobbering) the old content instead of creating a new entry. Or they could put some nasty text in the Description field and hide it, hoping I won't see it. Neither of those are likely to happen since I don't accept blog entries from anyone else, and even if I did there's a confirmation step before posting where I would get to double-check the content. But your solutions will have different threat models and thus require different levels of attention.

Regular expressions are a really cool way of validating input, and Michael has some things to say about them in his book <plug notagain="oh yes">Writing Secure Code</plug>. You can weed out all kinds of nasty things using a few expressions, and that will help you stop not only security bugs, but general code quality issues, too.

One other really cool thing that you get for "free" with VSTO is that the document itself is subject to security checks. I don't worry too much about WordBlogX because it's simply not possible under a default security policy for someone to send me an e-mail attachment that links to the code, or for someone to point me to a web site that opens a document and links to the code. Unless the document is copied to my local machine, it cannot access any assemblies, even if they are trusted.

Unfortunately VBA does not provide this degree of protection, but you could attempt to mimic it by parsing the document's location during your startup routines to see if the URL is in an expected location or not. This is a slightly different approach from locking the document to a very specific location as mentioned above (which lets you "guarantee" that the content is trustworthy). Instead this enables you to flag "suspect" uses of the document (eg, hosted off external web sites) while still enabling users some degree of freedom about where they save the files.

Rather than looking for "http:" at the start of the string (or some other "black list" approach), you should use a "white list" approach where you know the "good" locations and look explicitly for them. Why should you do this? Well, for one thing, if the attacker learns what "bad" patterns you are looking for, they'll just pick a new pattern that isn't caught by your code. There's only a small, finite number of "good" locations that the average document should be in, but there are an infinite number of "bad" ones and you can't check for them all. Also if you just do the naive thing and check for a protocol like http:// you'll get confused by the Temporary Internet Files folder and treat things that really came from the web as if they came from the local machine (bad bad bad!)

As an example, if budget spreadsheets should only ever be stored in the Budgets folder, then you should make sure that the path to the document begins with that text. Of course this means that the code won't work outside of an e-mail attachment, but maybe that's not such a bad thing.

  ' Note this is VBA, not VB .NET :-)
  ' Makes sure the file is in the right folder
  Sub CheckDocumentFolder()

    Dim path As String
    Dim expectedPath As String

    expectedPath = Application.DefaultFilePath & _
      "\Budgets\"
    path = ThisWorkbook.path

    If (InStr(path, expectedPath) <> 1) Then
      MsgBox "This is a Budget document. It should be " & _
        "stored in the 'Budgets' folder."
      ThisWorkbook.Close
    End If
  End Sub

NOTE: If it were possible to call MapUrlToZone from VBA I'd also recommend you do that, because you should never really attempt canonicalisation or parsing yourself, as outlined in <plug shouldgetkickback="true">Writing Secure Code</plug>, chapter 11. Nevertheless, using a white list is better than nothing. If someone knows of a way to get MapUrlToZone to work from VBA, that would be really cool info to share!

Provide cues to the user

A strategy that you can use to help alert the user of impending doom is to provide them with some (subtle) cues that they are using your application and not some innocuous document. Returning to the mis-matched Budget vs. HR spreadsheet scenario, if the HR code displayed some kind of a splash-screen upon loading then a user who believed they were opening a Budget spreadsheet would become suspicious and presumably shutdown the document and contact their administrator.

Of course relying on a splash-screen alone is not a good idea, since the user may never see it depending on how they are interacting with the computer. It's just something else you can throw out there to make it even harder for people to accidentally shoot themselves in the foot.

If you have other forms of non-spoofable UI, they would be good places to post some warning messages or other cues as to the purpose of your application, but as I mentioned above this is hard to do unless you are building a SmartDocument or you have a custom ActiveX control which you completely own.

If you show a form or some other UI as part of your solution, ensure that the user can garner enough context from the information you show to make good decisions, even in the face of malformed document content. Returning to our favourite "format hard drive example", let's say there was a confirmation dialog that popped up (see next section) asking the user if they wanted to continue or not. If the message box simply asks "Continue? [Yes] [No]" then the user has no context other than what is presented in the document itself, which could be anything at all (especially if you didn't use the other strategies, such as using descriptive captions and initialising them through code at load time). So make sure you give the user enough information to make an informed choice, but don't overload them too much such that their eyes glaze over and they learn to ignore your warnings.

Get consent from the user

You've done everything you can to help prevent your code from being repurposed, but at the end of the day you have to send some sensitive information to a URL stored in the document or perform some other kind of operation that you're not entirely comfortable with. Whaddayoudo? (Yes that link will get old eventually).

Well, it's probably not a bad idea to ask the user. Try not to ask them in a really obscure, technical manner -- unless your user base is technical, of course -- but in plain English (or the language of your choice :-)). Describe the badness that could happen if this code were being used incorrectly, taking into account the other mitigations you have employed. Speak in general terms if the specifics are too technical, but don't over-simplify the gravity of the situation. Having professional staff on hand to help with error messages, confirmation messages, and other UI text is very helpful.

This section is really quite general and doesn't apply only to code repurposing mitigation; it's just good application design. If users are empowered to make informed choices, they're more likely to make good choices.

One of my pet peeves in this area is people who use MessageBox calls with the "[OK] [Cancel]" buttons, but then they ask a Yes / No question. Or even worse, they ask an ambiguous question, or put more than one decision point in the dialog, or use double negatives. What's up with that?! I can partially forgive it in DHTML programming, where window.confirm only allows for OK and Cancel, but even there all you need to do is re-phrase the prompt so it makes sense. I guess that in many cases they're just trying to side-step the need to build their own dialog and try to hack their requirements into MessageBox, when really they should just crack open the forms designer and do their users a favour.

Users are generally confused enough about computers and security already; you don't need to make it worse by asking silly things like "Do you want to upload data or rollback the transaction? [OK] [Cancel]". Picking a bad default button is also a sign of poor design; you should generally pick the "safe" default (usually No, Abort, or Cancel) so that if the user blindly hits <Enter> they aren't toast. And don't skimp on the Cancel button either, if it makes sense to cancel the entire operation in addition to assenting or dissenting to a particular question. You can set the buttons, the icon, and the default button for both MsgBox in VBA and MesssageBox.Show in .NET, so there's no excuse for not doing it.

Finally, be consistent with the way you word dialogs -- don't have one prompt saying:

"Would you like to save changes before closing? [Yes] [No] [Cancel]"

and another one asking:

"Would you like to close without saving? [Yes] [No] [Cancel]"

Don't laugh, I've seen applications like this.

Closing thoughts

It's not easy to build complex solutions that are both easy-to-use and hard-to-repurpose, especially when you factor in user ignorance or error. But as I mentioned earlier, it's a trade-off you have to make based on the types of threats you think your solution might come up against, and the consequences of someone successfully executing one of those threats.

If you're writing a macro that bolds the active paragraph in Word, you probably don't have much to worry about. It's kind of hard to make it bold anything other than the active paragraph, and even if you could get it to do that, what's the damage? Nothing that can't be fixed with an Alt+Backspace (that's the old-fashioned equivalent to Ctrl+Z, for those who don't know).

But if you're building a spreadsheet for managing multi-million-dollar portfolio accounts, or you deal with sensitive material like HR records or legal contracts, you'd better be thinking of security.

Code Repurposing

ptorr — Thu, 16 Oct 2003 11:22:00 GMT

[Ed: I've now posted a follow up entry to this blog that talks about some strategies you can use to mitigate the kinds of problems outlined in this blog entry]

<sigh>

Code repurposing really blows. And it sucks. It sucks and it blows. And not necessarily in that order!

This blog could be short, or it could be long. It depends on how much I ramble and how many side-topics I need to bring in to talk about this most heinous of concepts. Hope you can stay along for the ride.

So what is code re-purposing? I talked about it a bit in a previous blog, but I'm just going to brain-dump again so please forgive me if I repeat myself.

Myself.

But before I start, I want to talk a bit about the difference between dangerous code and malicious code. Eric touched on this subject in his blog a while ago, but in case you didn't read it or in case you're still not sure, I'll start with a bit of a story. I'm doing this is so I can talk about the difference between installing bad code, and having good code get repurposed (something that a lot of really smart people don't understand).

[Ed: Word just crashed so I have to re-type this paragraph... argh!]

If I told you that the other day I discovered some code on my machine that could erase all the files on my computer and any network shares I have access to, you might be a bit alarmed. If I told you that I also found some code that could send e-mails to all the people in my Outlook contacts, you might start getting nervous. If Mr. Paranoid can't even keep his machine virus-free, then how can the rest of the world? Run to the hills!

Well... someone just jumped to a conclusion :-). I never said I had a virus; I said I had software that could delete files (it's called the DEL command), and I said I had software that could send e-mail (it's called Outlook). The DEL command is pretty dangerous -- it deletes data! -- but its operation is well documented and only trusted entities can use it to delete files. It's not malicious. Same for all recent versions of Outlook -- it can send mail, but only when I want it to.

Installing vs Repurposing

At work when we're talking about security problems, we often invoke a mythical ACTIVEX CONTROL OF ULTIMATE DESTRUCTION, a control that will proceed to format the user's hard drive as soon as it is initialised.

This control is talked about in two different contexts:

1) The ACOUD is not installed on my machine, but I visit a web site or open a document that attempts to download the control for malicious purposes

2) The ACOUD is installed on my machine and I visit a web site or open a document that attempts to invoke the control for malicious purposes

There is a significant difference between these two scenarios, although quite often I have to expend large amounts of time and effort trying to explain this difference to people to show why they do (or do not) have a security problem with their designs.

In the first case, we assume that the control is 100% pure evil and has been developed by a hax0r. The purpose of the control is to be downloaded to your machine and do as much damage as possible as quickly as possible. When you visit the web page, the browser attempts to download the control, and one of three things can happen:

i. The control is blocked by your security settings

ii. You are prompted to download the control

iii. The control installs without prompts

The first one is most likely to occur if the code is unsigned -- it's the default behaviour of IE -- and it's A Good Thing. It will also happen if you browse the net in "High" security mode, or if you are not running as an Administrator. In this case you are safe from the ACOUD because it will never be installed and hence it can never do its dirty work.

The second one is likely to occur if the control is signed (remember, the bad guys can get certificates, too!) or if you have lowered your security settings to allow unsigned controls to be downloaded with a prompt (not a good idea!). In this case, you are prompted for your permission / consent to download and install the control. If the browser can determine any interesting security properties about the control (ie, its signature) then it will show you this information; otherwise it will just kind of shrug its shoulders and go "eh?" at you. Now if you decide to install and run the ACOUD, then it's your own fault! Yes, that's right! You and you alone are responsible for deciding whether or not to install code on your computer. If you make a bad trust decision (trusting unsigned code, or code from an untrustworthy publisher, or code from someone you've never heard of like "Permissioned Media") then there's nothing Windows (or any other OS, for that matter) can do to protect you.

Aside: It's quite funny in a sad kind of way how all the ABMers (Anything But Microsoft) think that the point of Palladium (aka NGSC, Next Generation Secure Computing Base) is to control what software people install on their machines. They think it's some nefarious plot to stop them installing Linux or Mozilla or OpenOffice.org or whatever on their PCs.

[Ed: Oh dear, he just provided links to competitors' sites. He'll probably get fired tomorrow!!!]

Boy would I sleep well at night if I knew people couldn't install bad software on their PCs. No more viruses or buggy user-written code to worry about! Of course I'd also be out of a job, because a PC is useless if you can't install arbitrary code on it. Of course the public just likes to talk about the OS, a browser, and a productivity suite (usually in the context of Windows / Internet Explorer / Microsoft Office vs. Linux / Mozilla / OpenOffice) but any given corporation could have tens or hundreds or even hundreds of thousands (no, that's not a typo) of custom applications that they need to run their business on every day. And if they couldn't install or use those applications, they would never move to the next version of Windows, which would mean I'd be out on my ear and deported back to Australia.

Sure, we could definitely make the experience much better than the dog-ugly and confusing AuthentiCode dialog we have today, and it's something we really need to work on in the future, but at the end of the day the user has to take on some responsibility. Driving a dump truck into a bank vault and then telling the police "I didn't know how to use the brakes!" doesn't work very well (go on, prove me wrong!), so installing malicious software and claiming "I didn't know how to stop myself from doing it!" shouldn't work well either. (I'm deliberately being harsh here -- I really do believe we must do a better job of helping users make informed decisions when it comes to their computer use -- but the fundamental problem remains: if people want to take actions of questionable merit and / or don't want to take the time to understand even the basics of computer security, there's not much we can do to help them).

Anyway, back to the story. If you tell IE to install the ACOUD then you are toast, plain and simple, and it's not our fault. Time to reformat your machine (oh wait, the control already did that for you -- how helpful!) and start again.

And of course if the third one happens, it's just like second one except you were saved the inconvenience of clicking "Yes" :-).

So in this case, the problem is getting the control on the user's machine. If the bad guy can trick the user into installing the bad code, or they can trick the computer into installing it automatically, they've already won. What we try to do with our product designs is of course make it impossible for the attacker to do this without the user being made aware of the possible consequences.

So far, so good.

[Ed: I just had a really bad espresso experience -- note there is no "x" in "espresso"! Although I have a pretty decent coffee machine, I just switched beans and so the grind wasn't right. Grrrr]

Now the second big scenario I mentioned was when the ACOUD is already installed on your machine. In this scenario, we assume that the ACOUD is actually a well-designed piece of software that you installed and perhaps regularly use. This might sound shocking, but remember the example of the DEL command. I as a user may have a common requirement of formatting hard drives (especially if I'm in a tech support role at a large company) and in order to make my job easier, I may have written a tool that automatically formats drives without any kind of prompting or warnings, because only I should be able to access the tool, and I presumably know what I'm doing. It's actually VERY HARD to convince people -- even really smart people -- that the ACOUD is a legitimate piece of software in this instance. It intuitively seems to go against everything we know about security. "You mean as soon as I call into this control it formats my hard drive? Without prompting?!? How can that be a good idea?!?" But trust me, there's nothing wrong with such a control if it is properly designed and protected. (This also applies in the case where you have some slightly less risky control that just happens to have an exploitable bug in its initialisation routines, but again the absolute coolness of the ACOUD trumps such a boring example in this case).

So anyway, we have the ACOUD sitting on our machine, and now the attack we are worried about is a web page or Office document that somehow manages to create and initialise an instance of that control without our consent. Holy whack exploitable software, Batman. We've got a problem. This is where the Safe for Initialization (SFI) attribute is used by Internet Explorer -- by default it will not try and initialise controls with data embedded in the web page because, in general, controls are not very good at protecting themselves against malicious input (overly large values that cause buffer overruns, spoofed URLs that accept leaked information, etc). So unless a control says "Yep, it's OK to feed me random garbage!" IE will not initialise a control with untrusted data.

In this case, the problem is allowing unauthorised agents to access more-privileged software in unexpected and dangerous ways.

If we design software that somehow fails to honour the semantics of SFI then we are in deep, deep trouble. And this is very hard to explain to someone -- yes the user installed the ACOUD, but it doesn't pose a security problem until YOUR CODE decides to activate it on behalf of www.hackmeplease_noreallyimbeggingyou.com. Eventually the point is made, often via analogies with knives, scissors, axes, teddy bears (yes, teddy bears) and other real-world objects, but it takes a tremendous amount of effort. Which is one of the reasons why I'm writing this.

Another aside -- I initially tried searching for Safe for Initialisation (the correct spelling) and ended up with a bunch of links to research papers, presumably written by people in Microsoft UK :-).

So there is a big difference between a hacker installing malicious code of their own design, and a hacker coopting otherwise benign software for evil doings of their own design. In once case we throw up our hands and say "the user made a bad trust decision!" and there's really nothing else we can do (other than provide additional mitigations via a defence-in-depth strategy), and in the other case we throw up our hands and say "Ouch, we gotta fix that before we ship!" (and also consider other mitigations as part of a defence-in-depth strategy). For some reason I've started writing "defence" as "defense"; I don't know why. I wish I would stop doing it, but at least Word corrects it for me so I don't look silly when this finally goes up on the web.

[Ed: Don't kid yourself -- you DO look silly]

Anyway, since I've rambled about random stuff for quite some time now, it only seems fair that I should ramble some more. Here's a common thread that you might have found on one of the Microsoft scripting newsgroups a few years ago:

FrustratedDev: I built a cool ActiveX control for my company, but it won't load in the browser. I keep getting security errors. Help!

HelpfulPoster1: Just lower your security settings and it will work!

Me: Nooooo, don't do that! You'll open yourself up to malicious code in the future.

HelpfulPoster2: Just sign your control with a certificate!

Me: Nooooo, don't do that! Signatures have nothing to do with whether a control will load in IE or not; it determines whether the control can be downloaded and installed or not

HelpfulPoster3: Just mark it "Safe for Scripting"!

Me: Nooooo, don't do that! Your code almost certainly isn't safe for untrusted callers.

The point being, well.... I forget now. But the moral of the story is don't sign ActiveX controls or mark them as Safe for Scripting unless you really REALLY need to enable arbitrary users to download your code and have it run against arbitrary web pages. And unless you're Microsoft or Macromedia or Apple or a similar type of company trying to reach millions of desktops across the world, and you have the resources and expertise to thoroughly review your code for security vulnerabilities that probably means "not you". (And even if it is you, you probably missed a bug or two along the way).

In case you care, more info on building secure ActiveX controls can be found here.

Get to the point already!!!

[Ed: Yeah, you rambling fool! Get to the point!]

OK, so something about repurposing ActiveX controls. Let's start with an example. A rather extreme example that is used quite often internally here in our team at Microsoft to get across the general idea of the badness of repurposing.

Let's say that OTG (our internal IT department) builds a "Format your Drive" web page, using a signed control that is marked "Safe for Scripting" (so that it loads without any errors). When you go to the Helpdesk web site and click on the "I need to format my drive" link, it downloads the helpful web page for you. The document has some informational text about what formatting means, why it is a dangerous thing to do, and so on. It also contains two buttons labelled "Yes" and "No", and it links to the code that does the actual formatting. The code is signed with the internal corporate signature, so all users at Microsoft implicitly trust it. When the user clicks the "Yes" button, it calls into the code to format the drive, which is perfectly acceptable and the right thing to do, since the user has been made aware of the consequences and has made an informed decisions.

The problem is that some pesky trickster creates a copy of the web page and replaces all the text about hard drive formatting with some text about downloading pictures of famous celebrities in various stages of undress. They maintain a link to the original formatting ActiveX control (which, remember, is signed and trusted), and send a link to the page around to all the people in their team. An unsuspecting user or three hundred decides to open the link and click the "Yes" button, in eager anticipation of seeing Margaret Thatcher in her winter underwear. (My apologies to those readers who just passed out). This of course invokes the original FormatDrive() function in the trusted control, and the user is toast.

A more subtle (but perhaps more realistic) scenario is where a less obviously dangerous piece of code gets repurposed from another document that is expected to contain code. For example, let's say that the IT department builds a new kind of budget forecasting web page that links to custom ActiveX control to implement certain functions similar to an Excel workbook. Let's also say that the HR department has built a web page (using another control) that enables users to balance their benefits (for the non-US people: that means your non-salary compensation, such as a medical plan, gym / health club membership, life insurance, etc.). And let's also assume that the HR control takes the URL of the web server it should contact as a parameter to the <object> tag in the HTML document.

Now assume that malicious user Bob wants to know how much money Alice earns, so he modifies a copy of the HR web page so it looks like the budget web page (by formatting so that it looks like a budget spreadsheet) but he updates the <PARAM> tag to point to his own web server and sends the document to Alice with a note saying "Please check these estimates and get back to me".

Now we see the problem. Alice opens the web page, and instead of the Budget code being executed, the HR code starts executing and uploads her personal information -- salary, stock options, health coverage, etc. -- to the web server that Bob controls. Remember the HR code is already signed and trusted; this is not a malicious code injection attack, but a repurposing attack. Even assuming that Alice's machine was setup to prompt before executing code, she expects the budget web page to execute code and so will most likely consent to the request, even though it's executing the wrong code.

I'm sure you can imagine other scenarios. The possibilities are endless! :-)

[Ed: I think that should be ":-("]

As I explained in my previous blog entry, insofar as VSTO goes we try somewhat to stop this attack from e-mail attachments and random web sites, but it doesn't help if users copy documents to their desktop or start publishing such malicious documents to trusted internal web sites.

And now you know why all my blogs are posted past midnight -- I can't sleep with all these nightmares about code repurposing going on in my head!

One last thing for the evening -- a real life tale of a security bug that could have been... in my very own WordBlogX!

The current version of WordBlogX on GotDotNet is pretty bad, mostly because it is lacking useful features. One feature I've already added in the build on my machine is the ability to put the URL of the blog server in a config file, thereby enabling people to post blogs to servers other than GotDotNet without recompiling the source code. Another feature I really want to add (but haven't done so yet) is a "remember my password" feature that securely stores my credentials on the local machine so I don't have to type them in every time I make a post. I'm going to implement this feature RSN (Real Soon Now; often used sarcastically to mean "never" but in this case I really do hope to do it soon!).

Can anyone see the problem with this design? Anyone? Beuller?

The problem is that anyone who gets a copy of the assembly can put it on a server of their control, modify the config file to point to a web server of under their control, send an arbitrary document that links to this code to anyone who uses WordBlogX, and then wait for the cached passwords to flow in. The attacker simply needs to have a button on their document with the programmatic name of cmdPost and somehow socially engineer the user into clicking it ("Free life-time supply of dental floss -- click here now!").

[Ed: Note that the root badness here is trusting the URL in the config file; sending usernames and passwords is just a bad side-effect that drives the point home]

Is this a bad design? Yes, it is.

Would the average developer, faced with similar requirements, come up with the same design? Quite probably.

Would this same developer threat model their code and try to mitigate against this attack? I don't think so.

Luckily for me I have the assembly for WordBlogX "installed" in a particular directory on my system, and it will only ever try to load the configuration file from that directory. The assembly is not signed and I do not trust it to load from any other locations (eg, malicious web sites), so I should be safe from this kind of attack for the time being (as should anyone else who installs WordBlogX in the future). But if I was the IT department in a large corporation, I'd probably just sign the code with the corporate certificate, and the code would be trusted from any location inside the LocalIntranet Zone (or perhaps on a server where malicious users have some degree of write access), in which case it wouldn't be long before the code was exploited.

I will probably add a confirmation dialog box to WordBlogX that displays the remote URL before retrieving credentials or sending any information to the server just to make sure, but this will no doubt annoy some users and they will turn off the confirmation.

(A lot of people downplay the likelihood or severity of internal attacks because, well, you only ever hear about high-profile public attacks in the news. But don't kid yourself -- attacks from people inside the firewall are much more common and much more likely to cost you big money than attacks from faceless hackers sitting half way across the world).

Thus ends tonight's effort. It's been long and random, and I probably scared the willies out of some people, but that's the way life is.

P.S. I managed to talk about teddy bears in the context of security when talking to a fellow PM about trusting the "Safe for Scripting" flag on controls. His argument was that SFS buys you nothing because hackers will always just set that bit and so therefore you are hosed when the control loads in IE. This is a concrete example of failing to understand the differences between installing malicious code and repurposing trusted code, as I tried to outline in the ACOUD example. Anyway, we had been talking about knives and how he wouldn't trust his young child with a big kitchen knife, so in a moment of desperation I came up with "The Teddy Bear Defence". When you buy a teddy bear from the shop, it comes with a safety tag that says "suitable for children 3 years and older" or something similar. As part of the purchasing act, you (implicitly) trust that the manufacturer is not lying about the toy being suitable for anyone 3 years of age or older. If the toy was manufactured by an evil company, all bets are off as to whether it is even safe for ANYONE to have the teddy bear, no matter what their age -- maybe it spontaneously combusts on the third Sunday of the month. In this case you made a bad purchasing / trust decision. But if the toy was manufactured by a responsible company, you can use the information printed on the warning label to deduce that it is OK to give the teddy bear to your 5-year-old but not your 2-year-old. And there you have it.

[Ed: This guy is ccccrrrraaaaaaaazzzzzyyyy!]

P.P.S. Who's this "Ed" fellow, and why does he keep popping up in my blog?

[Ed: Mmmmmuahahahahahaaaaa.......!!!!!]

Another debugging tip

ptorr — Mon, 13 Oct 2003 23:45:00 GMT

I wrote about a few debugging tips for VSTO the other day. Something else just came up this morning that I should add. Does this scenario sound familiar?

You decide to create a new VS project
You click through all the default dialogs, ignoring the silly default name (you'll change it later)
You build and debug WordProject238 for a while until it is looking good
You give the finished project to someone and they complain that the name is not very descriptive
You rename the document to MyCoolTemplate.dot and rename the assembly to MyCoolAssembly.dll
You test the document and it fails to find WordProject238_bin\WordProject238
You kick yourself for forgetting the AssemblyLinkLocation, and make the custom properties point to MyCoolTemplate_bin\MyCoolTemplate instead
Your code still fails to run with some spurious "Can't be found or loaded" error

Well guess what? You just broke a fundamental rule of the CLR -- the "assembly name" (the thing you pass to Assembly.Load) must match the internal "assembly name" (the thing inside the Manifest). The compiler sets the Manifest's name to be the same as the DLL's name when you build the project, and manually re-naming the DLL after the fact will cause problems.

You have to go to the Project Properties inside VS, change the output name to MyCoolTemplate.dll, and then re-build the project. (This should also fix up the custom properties for you).

This "bug" came up several times during the product cycle, and it just came up again today. If it ever comes up again, I'll have a URL to point to ;-)

More VSTO Press

ptorr — Mon, 13 Oct 2003 18:55:00 GMT

VSTO has been picked by a few more places; you can pick your favourite link from Google News results or just go straight to the Australian version :-)

Now if this would somehow make it to Slashdot, I could retire happy.

I would have written an entry last night had my laptop keyboard not died on me; it seems to be doing better today, so maybe this evening I'll waffle some more.

Successfully debugging VSTO projects

ptorr — Mon, 06 Oct 2003 09:43:00 GMT

It seems that everyone I know who is writing a blog has a long list of things they want to talk about, and the list grows faster than they can write entries. This is fundamentally different from the way newsgroup postings work, where it's very much a reactionary thing (someone posts a question and then you post the answer). I've often wanted a "low priority" flag for news posts (the same way e-mail has low priority flags) so that I could just write random stuff for people to read at their leisure. But of course then you'd have to have a corresponding "high priority" flag, and everyone and their dog would abuse it.

But now I have this blog. Hmmm.

My wish list contains some things that will take a while to write about, but nothing like what Chris Brumme is able to do on a regular basis. Even his e-mail replies to casual questions are incredibly long and detailed, and we're very lucky to have him at Microsoft!

Anyway, a small topic for tonight. One thing I'd like to do is talk a lot about some of the finer points of VSTO (in particular its security model), but unfortunately (!!!) the documentation is actually pretty detailed and so I'm not sure how much value I can add. Oh well, we'll see how often things come up on the newsgroups and in internal support e-mail aliases.

Oh well, on to my 3 main tips for the evening:

Swallowed Exceptions

If you have some code in your solution that generates an exception, and that exception propagates back to the caller (Word or Excel) then you will not be notified about it. This is in contrast to VBA which will tell you when your code has messed up, and it often confuses people -- their code just silently dies.

As Chris points out in his latest treatise on exceptions, the CLR tries to interop with the unmanaged world when it comes to exception propagation, and the way that managed exceptions are returned to the COM world is via failed HRESULTs and the IErrorInfo interface.

For better or worse, when Word or Excel receives a failed HRESULT from a method call (usually an event handler in this case) they just ignore it and move on. In the VBA case they have a much tighter integration with the runtime portion and VBA will do its thing when it realises it's about to lose control of execution, and so you get the error message (which of course is very annoying if you're an end-user because you have no idea what a Type Mismatch is, and can't do anything about it).

So in VSTO, if you have any code that is called by Word or Excel, you should wrap it in try-catch blocks so that you can display an error or do other processing as appropriate before the error is forever lost in the transition to unmanaged code. Another trick is to turn on the "Break on 1st chance exceptions" setting, although this will get you more exceptions than you need. Fine-tuning the exceptions that will break into the debugger by expanding the TreeView and unselecting some of the exception types you are uninterested in can help.

Failing to execute

A common problem people have is that their assembly does not execute at all. They got the original solution working in Visual Studio (where we handle the basic security policy changes for you), but when they move it to another machine or a different directory it fails to load. The most likely reason for this is that policy was not updated correctly, and the thing I always ask people to do is run the following commands and send me the results:

caspol -all -lg

caspol -rsg path_to_assembly

What this will tell me is what their security policy looks like (lg == list groups == list all policy rules), and then how the CLR thinks the evidence of the assembly maps to those rules (rsg == resolve groups == list groups the assembly matches). This tells me whether or not they have set up policy correctly, and whether or not their assembly is matching the code groups they think it should match. Most problems are caught here for one of three reasons:

A network rule (eg, http://server/ --> FullTrust) was added to the MyComputer zone, but it's in the LocalIntranet
There's a typo in the filename or URL
The asterisk (*) was not added after a directory to indicate "and all folders under here"

I'll show an example of a fourth problem I've only seen once, but the effect is the same as for the three cases above:

A simplified output of caspol -all -lg

Enterprise

All_Code: FullTrust

Machine

All_Code: Nothing

MyComputer: FullTrust

LocalIntranet: LocalIntranet

http://localhost/*: FullTrust

TrustedSites: LocalIntranet

RestrictedSites: Nothing

User

All_Code: FullTrust

A simplified output of caspol -rsg http://localhost/myassembly.dll

Enterprise

All_Code

Machine

All_Code

TrustedSites

User

All_Code

Immediately it is obvious to the trained eye that the user thought http://localhost/ was in the LocalIntranet zone (which it is by default), but for one reason or another they have added it to the TrustedSites zone in IE. The answer is simply to move the localhost rule from LocalIntranet to TrustedSites, and you are golden.

Other random security failures

If your main assembly loads, but you get random errors at some other time (especially if you are using 3rd party components or some code that may be automatically generating assemblies via ICodeCompiler or VSA) then you may be able to use the technique I describe in this newsgroup post. Essentially you can temporarily grant unrestricted permissions to all code on your local machine and then at some opportune time in your program you dump out the evidence used to load all the "interesting" assemblies. For example, if you use a component that dynamically compiles and loads assemblies via ICodeCompiler, you will probably find some randomly-named assembly loaded into your AppDomain with a certain set of evidence.

Depending on what control you have over the generated assembly, you may be able to force it to be generated in a particular location which you can then trust. It is likely to be tricky to get these kinds of solutions working though, and your best bet in this instance may be to create a new AppDomain with its own (probably default) security policy that can load the dynamically generated code. But then of course you'll have problems marshalling the stuff between AppDomains.... sigh.

----------

Something else I may talk about in more detail at some stage is the Excel / .NET mismatched locale issue. This is a problem that came up during beta, and spawned many person months of discussion and brainstorming to come up with a workable solution. At the end of the day, the best we could do was document the problem (ie, the link above) and try and work something out longer-term. The problem is really quite hard to solve, and maybe I'll delve into it in a bit more detail later on. (Actually there is a fairly simple solution that will work in most cases, but it "feels" like a hack and it just wasn't feasible at this point in time).

Oh and some trivia for the evening:

1) IUnrestrictedPermission is the thing in the CLR that lets a permission become part of the FullTrust pseudo permission set.

2) There are no Microsoft-provided implementations of ICodeParser

Notes for #1: Pretty much all permissions except StrongnameIdentityPermission implement the IUnrestrictedPermission interface. The difference between the Everything permission set and the FullTrust pseudo permission set is that Everything contains a static list of all permissions that Microsoft ships out of the box but no 3rd party permissions. FullTrust on the other hand is a dynamically computed list that includes all permissions that implement IUnrestrictedPermission, including any 3rd party permissions. You should probably never use the Everything permission set unless you have a really good reason to, and if you ever find yourself in the position of having to implement your own permission (not something you'd do for an ordinary application) then you should strongly consider implementing IUnrestrictedPermission if the semantics of your permission mean that FullTrust code should get it (and since FullTrust code can do anything it wants, including lie about evidence, call unmanaged code, read and write random memory locations, etc. it can do whatever it is you're trying to prevent anyways, so you shouldn't really think you're buying any additional security by not implementing IUnrestrictedPermission).

Notes for #2: Every now and then someone asks a question about ICodeParser, and how they go about getting their eager little mitts on an instance for C# or VB (strangely no-one ever seems to ask about JScript...<sniff>). Anyway, you can't. Obviously someone designed that interface because they had planned to ship something along the lines of a source-code-to-CodeDOM translator, but at some point in the long and arduous journey of shipping a product it got left behind. I even remember hearing about a feature of VS where you could copy VB .NET source code and paste it as C# (and vice versa), but this was a year or more before VS 7.0 shipped and it's still not in the product today. I may have even seen a demo at one point in time, but I don't know if I'm imagining that or not ;-).

That's it for now!