Thread by @AnsonHorton

1/ It's been very busy at MS ever since the new year started, and you've probably seen a bit of what we're working on with Visual Studio 2022 (devblogs.microsoft.com/visualstudio/v…).

2/ I'm going to go further back in history though, and talk about a defining moment for Visual Studio .NET (2002) and really all of Microsoft. In early 2002, Bill Gates sent a memo to the entire company that kicked off the Trustworthy Computing initiative.

3/ There had recently been a raft of serious computer viruses, coupled with the September 11th terrorist attacks; it was a turning point for the country, industry, and company.

4/ In DevDiv, that translated into a concentrated three month effort in which every single line of code was reviewed. Threat models were built, architecture inspected, trust boundaries defined, and fuzz testing performed.

5/ Visual Studio is unique – its primary purpose is to develop applications that, by definition, can and should be able to execute arbitrary actions in the security context of the logged-in user (and, indeed, in other contexts as dictated by the application being developed).

6/ There was, at the time, significant skepticism about whether there was any need to secure Visual Studio given its use cases. There was concern that no such protection could be given anyway.

7/ Finally, there was disagreement about whether developers needed such protection; surely developers were savvy enough to understand that VS would ultimately run code, and therefore the developer must always trust the code being run.

8/ This was institutionalized thinking at the time, and it took effort to reorient.

I will talk more about this in other posts, as well as where we are today. However, our focus on security revealed some surprises.

9/ The framework team spent a lot of time thinking through possible ways that a malicious user, extension, etc. may compromise an application. That led to an analysis of what was possible with IL that wasn't possible with C#.

10/ I honestly cannot remember exactly when this specific issue was discovered, but ultimately, the .NET team realized that they had assumed visibility and accessibility were the same, because that's largely how C# treated them. However, that's not true for the CLR.

11/ They are two distinct concepts. Visibility was a top-level concept that is basically split between exported and non-exported types. Accessibility is controlled by accessibility modifiers. The ability to call a method was controlled by accessibility.

12/ The ability to override a method was controlled by visibility. This meant that in the framework there were internal virtual methods within public types that could be overridden external to the assembly (even though they couldn't be called).

13/ This couldn't be done from C#, but could be done from IL. This was non-obvious, and there was a large amount of framework code that needed to be reviewed as a result.

14/ However, when we discussed this, we didn’t think this would be obvious to any user of C# and we ran the risk of other applications having security issues in their APIs if we shipped this way.

15/ There were several very heated discussions about it, because initially the C# team suggested changing the semantics of the runtime, and the CLR folks pointing out that C# wasn't the only language and there were cases where visibility and accessibility shouldn't be tied.

16/ I won't go into detail about meetings where there was literal yelling and table pounding, suffice it to say, people expressed their passion in ways that I'm happy to say are basically unheard of at Microsoft today.

17/ The resolution was to add a new strict flag MethodAttribute which the runtime enforces as a method may only be overridden if it's also accessible. The C# compiler was updated to emit this flag for any non-public virtual method.

18/ This was a great lesson for everyone about assumptions and the value of threat modeling as a way to locate potential security issues.