Writing Secure Code
One of the things that my team is responsible for is helping developers understand the importance of writing secure code and how to do it. Rick Samona has joined my team and is working with security experts like Jeff Cooperstein and Michael Howard to begin the process of helping developers think more about security. We did some research and we found that about 50% of developers think it is important to write secure code (what about the rest?) and that they even feel security is more their responsibility than the responsibility of system administrators. And about two-thirds of them they feel like we (that's we, the industry, not just we, Microsoft) don't provide them with enough information, tools, guidance, and so on to write secure code.
So Rick is going to start to make it easier to write secure code (right after he gets my coffee). [Rick made me add that last bit.] One of the things he did was to pull together information in response to a question about requiring administrator privileges to install or run an application. I found it to be a good read, so I'm including it below.
But my main question is, what should we be doing to make it easier to write secure code?
Microsoft Recommended Best Practice
Microsoft encourages that as a best practice developers write their applications to execute with the least privileges to get the job done. The reason for doing this is quite simple – if an attacker creates a security vulnerability and it penetrates your system, whether it be a Trojan horse or virus, this code will run at the same privileges as the compromised process. In Writing Secure Code, Second Edition, Michael Howard states that "I haven’t been [using an admin account] for over three years, and everything works fine. I write code, I debug code, I send e-mail, I sync with my Pocket PC…" Microsoft has been working on several things to make writing least privilege applications as easy and streamlined as possible.
We recommend that before a developer creates an application, he/she should write down the resources it must access, special tasks it must perform, and the necessary permission settings. Many times the developer will notice that there is not need to create the application to need admin privileges.
There are three main reasons for developers writing applications which require elevated privileges:
1. An Access Control List (ACL) issue
2. A privilege issue
3. Using LSA Secrets
Many times these can be avoided. More information can be found in "The Challenge of Least Privilege."
With Windows XP, Microsoft allows users to do something special when running an application that requires admin privileges. A user can use the runas command or click on the shortcut for the application and check the Run as Different User option.
Visual Studio 2005
Visual Studio 2005 has evolved to make writing secure applications easier than before, including least privilege applications. VS 2005 allows developers to develop and debug applications as a least privilege account. So, for example, if a developer is writing an application that targets least privilege users, the developer can now developer and debug this application as a least privilege user himself. This makes developing the application much easier, because if the developer inadvertently writes the application in a way that requires higher privileges (i.e. write to the registry), then the application will not run since the current login is not an administrator. This was not the case before. This will be true for both unmanaged and managed code.
Furthermore, VS 2005 will enable developers logged in as an administrator writing managed code to run the code in a sandbox using custom privileges. This is called Code Access Security and is provided by the .NET CLR. Let me give an example:
Assume that a developer is logged in as an administrator and he/she is developing an ASP.NET application that launches calculator on the computer. This is obviously not something a developer should want an ASP.NET application to do. If the developer tests this, it will obviously run since it is running on the developer’s privileges. Currently, the only way to know if the application will run under least privilege is to post it on the website and run it. With CAS, the developer can select what privilege the application should run at and test it. So, for this ASP.NET application, the developer can select "Internet privileges," and when he/she tests the application, it won’t run. It will also highlight the chunk of code that has the issue in order to aid the developer to fix the problem.
This will make the process of writing least privilege applications much more simplistic and streamlined.
Longhorn will introduce even more functionality for least privilege – the idea of Application and Deployment Manifests. Application Manifests will allow application developers the state what permissions their application requires to run properly. Deployment Manifests allows System Admins to indicate how much trust they have in an application. This is a high-level explanation of a powerful functionality which will work for both managed and unmanaged code.
To simplify security both for admins and end-users, Longhorn will have only two levels of system access: least privilege and administrative. Developers will need to make a choice of how they want their applications to run and write the code accordingly. For example, developers will have to store the application state in the user profile, not in the Program files directory.
The Challenge of Least Privilege
Security in Longhorn: Focus on Least Privilege
Chapter 1: The "Longhorn" Application Model
Michael Howard and David LeBlanc
Writing Secure Code, Second Edition,