.NET Security Blog : Other

CLR Inside Out: Digging into IDisposable

shawnfa — Wed, 20 Jun 2007 19:10:09 GMT

My third MSDN magazine article, Digging into IDisposable, appeared in this month's issue in the CLR Inside Out Column. It's a bit of a departure from my usual security fare; this time looking at how to best handle writing class libraries that must manage resources.

Also in this month's issue, Kenny Kerr provides a good introduction to the new CNG APIs available on Vista. Especially interesting is the code snippets he provides translating from CNG RSA keys to RSAParameters for use with RSACryptoServiceProvider. (And for a quick rundown of the managed CNG classes Kenny mentions in the v3.5 framework, you can see the posts in my CNG category).

Introduction to the Orcas Add-In Model

shawnfa — Tue, 20 Feb 2007 21:08:29 GMT

One of the features the CLR team is adding in Orcas is that we're providing a new model to help enable your application to host Add-Ins. I've got a special interest in this set of features, as I always try to make my hobby applications pluggable for some reason, and I tend to end up writing a ton of infrastructure that, once Orcas ships, I will no longer have to. The Add-In team has done the work to enable discovery, versioning, and most importantly (from my perspective at least :-) ) securely sandboxing those Add-Ins.

Recently, they've done a pretty big brain-dump of how their feature is going to work. Some of the resources available are:

MSDN Magazine Articles:

Blogs

Jason's blog is interesting because he's decided to go through the steps to upgrade Paint.NET to use the new AddIn model, and discuss his experiences. If you're intereseted in making your apps extensible, it's worth checking out this feature to see if it's made your life any easier.

Happy Holidays!

shawnfa — Sat, 23 Dec 2006 04:00:00 GMT

In an effort to escape Seattle's ... interesting ... weather patterns of the last few months, I've taken off to New York for the holidays. (And unlike last year's 19 degree temperature drop, this year it's actually going to be warmer in the Northeast. Go figure.)

So, until January, Happy Holidays!

-Shawn

SecureString Redux

shawnfa — Thu, 02 Nov 2006 01:17:22 GMT

A few times over the last couple of days discussion about a tool on the Internet which can attach to your process and dump out the contents of your SecureStrings has come up. If this tool can exist, then what benefit does SecureString really provide?

The fact that this tool can exist is not a hole in the SecureString feature. Presumably at some point you'll want to be able to access the data you're storing in your string (after all, if you didn't want to ever access that data again, why store it in the first place?). If you're going to want to access it, then the process that did the encryption on the string data will need a way to decrypt the data again. So it's not a failure that code in your process can decrypt the SecureString contents, it's by design. (Note that to access the Marshal APIs which do decrypt the string, you need to be have SecurityPermission/UnmanagedCode -- or essentially be fully trusted. This means that arbitrary partial trust code in your process cannot in fact access the plaintext contents of your string).

Back in my original post about SecureString I mentioned several problems with storing sensitive data, such as a password in a standard System.String. SecureString solves these problems. Namely:

The string is not stored in the managed heap while standard strings are. This means that a string can be moved around by the GC, leaving multiple copies of the sensitive data in memory. Your code will not know that this has happened, and even if it could figure out that the string was moved, you have no way to clear out the other copies. Instead you have to wait for the CLR to allocate another object where the sensitive data is so that the memory gets erased.
SecureStrings are stored in an encrypted form. While they will have to be decrypted during the periods of time that they are used, this period can be kept as small as possible. If your process is swapped out to disk while the string is encrypted, the plaintext will not end up in the swap file.
The keys used to encrypt the string are tied to the user, logon session, and process. This means that any minidumps taken of the process will contain secure strings which are not decryptable. If Watson sends dumps off to Microsoft or if you have to have a client send you a minidump of a crashing application, they can rest assured that you cannot access the sensitive data in the strings.
SecureStrings are securely zeroed out when they're disposed of. System.Strings are immutable and cannot be cleared when you've finished with the sensitive data.

While the SecureString class does not prevent fully trusted code which is running in your process from decrypting the contents of the string and doing whatever it wants to do with it, it does provide several other features. It's all about risk management -- keeping the sensitive data as inaccessible as possible when it's not being used, and being able to erase your records of it when it is no longer needed.

Quickly Testing Code Under Different Cultures

shawnfa — Fri, 20 Oct 2006 21:27:00 GMT

Earlier this week, a situation came up where we needed to make sure a new feature worked when it was used with a non-English culture. Normally we'd run some tests on a Japanese machine, but one wasn't readily available at the time. Instead, I put together a quick tool that our tester could use to run his tests under.

The tool simply switches the current culture (and UI culture by default) of the running thread, then proceeds to execute the target application. The obvious downside is that the tool only changes the culture of the main thread, so any work done on newly created threads or the thread pool will not automatically pick up the culture change. However, for cases where you know that your work will only be done on one thread, or you manually propagate culture information, this will work as a quick and dirty way to launch applications.

(The usual disclaimers apply -- this code is provided as-is and if it happens to cause your monitor to explode while you run it, Microsoft is not responsible, etc, etc.)

using System;
using System.Diagnostics;
using System.IO;
using System.Globalization;
using System.Security;
using System.Threading;
 
/// <summary>
///    Tool which runs an application with the main thread set to the specified culture
/// </summary>
public static class RunLoc
{
    private static string application;
    private static string[] applicationArguments;
    private static CultureInfo culture;
    private static bool onlyUI;
    private static bool verbose;
 
    public static int Main(string[] args)
    {
        if (!ParseArguments(args))
        {
            Usage();
            return -1;
        }
 
        Debug.Assert(!String.IsNullOrEmpty(application), "!String.IsNullOrEmpty(application)");
        Debug.Assert(culture != null, "culture != null");
 
        if (verbose)
        {
            Console.WriteLine("RunLoc running on .NET version {0} ({1} bit)",
                              Environment.Version,
                              IntPtr.Size * 8);
            if (!onlyUI)
            {
                Console.WriteLine("  Current culture:    {0} [replacing with {1}]",
                                  Thread.CurrentThread.CurrentCulture.DisplayName,
                                  culture.DisplayName);
            }
            Console.WriteLine("  Current UI culture: {0} [replacing with {1}]",
                              Thread.CurrentThread.CurrentUICulture.DisplayName,
                              culture.DisplayName);
            Console.WriteLine();
        }
 
        try
        {
            if (!onlyUI)
                Thread.CurrentThread.CurrentCulture = culture;
            Thread.CurrentThread.CurrentUICulture = culture;
        }
        catch (NotSupportedException)
        {
            Console.Error.WriteLine("Error: Culture {0} is not supported.", culture.DisplayName);
            return -1;
        }
        catch (SecurityException)
        {
            Console.Error.WriteLine("Error: RunLoc does not have sufficient permission to change the culture");
            return -1;
        }
 
        try
        {
            return AppDomain.CurrentDomain.ExecuteAssembly(application, null, applicationArguments);
        }
        catch (FileNotFoundException)
        {
            Console.Error.WriteLine("Error: '{0}' could not be found", application);
            return -1;
        }
        catch (SecurityException)
        {
            Console.Error.WriteLine("Error: RunLoc does not have sufficient permission to run the application");
            return -1;
        }
    }
 
    private static bool ParseArguments(string[] arguments)
    {
        Debug.Assert(arguments != null);
 
        if (arguments.Length < 2)
            return false;
 
        // All of the RunLoc arguments must come before the application name, since that is just followed
        // by its own arguments. Loop until we hit the last argument, or until we find the application name.
        int currentArgument = 0;
        while (currentArgument < arguments.Length && application == null)
        {
            if (String.Equals(arguments[currentArgument], "/v", StringComparison.OrdinalIgnoreCase))
            {
                verbose = true;
            }
            else if (String.Equals(arguments[currentArgument], "/onlyui", StringComparison.OrdinalIgnoreCase))
            {
                onlyUI = true;
            }
            else if (culture == null)
            {
                try
                {
                    culture = CultureInfo.GetCultureInfo(arguments[currentArgument]);
                }
                catch (ArgumentException)
                {
                    Console.Error.WriteLine("Error: culture '{0}' is not found", arguments[currentArgument]);
                    return false;
                }
            }
            else
            {
                application = arguments[currentArgument];
            }
 
            currentArgument++;
        }
 
        // Make sure our required parameters are present
        if (culture == null)
        {
            Console.Error.WriteLine("Error: No culture given.");
            return false;
        }
        if (String.IsNullOrEmpty(application))
        {
            Console.Error.WriteLine("Error: No application given.");
            return false;
        }
 
        // Any remaining arguments belong to the application
        if (currentArgument < arguments.Length - 1)
        {
            applicationArguments = new string[arguments.Length - currentArgument];
            Array.Copy(arguments, currentArgument, applicationArguments, 0, applicationArguments.Length);
        }
 
        return true;
    }
 
    private static void Usage()
    {
        Console.WriteLine("Usage: RunLoc [/v] [/onlyui] culture application [application arguments ...]");
        Console.WriteLine();
        Console.WriteLine("  /v                    - verbose mode");
        Console.WriteLine("  /onlyui               - only change the UI culture");
        Console.WriteLine("  culture               - culture to set the main thread to");
        Console.WriteLine("  application           - path to the application to run");
        Console.WriteLine("  application arguments - arguments for the application");
        Console.WriteLine();
    }
}

Using this is pretty easy:

C:\RunLoc>FloridaBreakfastFruit.exe
Mmm ... grapefruit

C:\RunLoc>RunLoc /v fr-fr FloridaBreakfastFruit.exe
RunLoc running on .NET version 2.0.50727.42 (64 bit)
  Current culture:    English (United States) [replacing with French (France)]
  Current UI culture: English (United States) [replacing with French (France)]

Mmm ... pamplemousse

[WeddingPermission(SecurityAction.Demand, Unrestricted=true)]

shawnfa — Sat, 05 Aug 2006 06:06:00 GMT

Having just checked in my last few bug fixes and the Orcas feature I've been working on, it's time to take off on a vacation.

But not just any vacation ... Tomorrow I head back to New York for my wedding on August 12th. (Here's hoping that it cools down before I get there. Big church - air conditioning + 100 degree heat + me in a tux != good times)

After a quick night Seattle on the 13th to swap wedding luggage for honeymoon luggage, we head off for a two weeks of sitting on the sand drinking tropical drinks, learning to surf, and eating lots of pineapple. (And I do mean lots of pineapple). We'll spend 4 days in Kauai, 4 days on Oahu, and 6 on Maui catching a couple of luaus along the way. Did I mention that our hotel on Maui has a 150 foot long water slide?

That means that this blog is going quiet until early September; but once I get back we'll continue with our regularly scheduled managed security content ... just in a more tan and less single fashion.

Aloha!

$20 on Double Zero, $20 on LUA please

shawnfa — Mon, 17 Jul 2006 21:35:33 GMT

I spent last weekend in Vegas, and on Saturday night / Sunday morning decided to recreate those college bar crawls with a bit of a casino crawl. Starting a Caesar's we bounced up the strip hitting every casino on the way with one rule: start with $40 ... double it or lose it, and move on to the next one.

At Aladdin, the last person in our group was still going at the roulette tables, and as I was waiting for him I took a look at the electronic board listing off the previous results. This one listed the name of the person running the table in addition to the results:

"Your dealer is: Administrator"

Now, maybe its just me, but I don't think you need admin privileges to note that the last number to come up was 21 :-)

Test Signing in Action: IronPython Beta 7

shawnfa — Wed, 24 May 2006 22:00:00 GMT

The IronPython team just announced their v1.0 beta 7 release, which is especially interesting to me because they’ve enabled IronPython to be signed with a test key signature.

Beta 7 has four configurations, the standard Release and Debug along with Signed versions of both. If you choose a Signed version, the build will look for an IronPythonKey.snk in the solution directory which it uses to delay sign the generated assemblies. After the build, it looks for a TestKey.snk file in the solution directory to test key sign with, generating it if necessary. Finally, it runs SN to extract the public key from the test key file, and register the output assemblies as test key signed (using both the 32 and 64 bit SN tools if present).

What’s interesting to notice here is they automatically generate the test key pair if they don’t find it, which is a completely reasonable way to setup developer machines. In fact, we can see one of the big benefits of test key signing in this scenario. Since each developer will have a different test key pair, everybody will have a different skip verification entry for the IronPython assemblies. Even within a single company, where you might have a standard IronPythonKey.snk that everybody is using (and perhaps trusting in policy), an attacker would be unable to craft an assembly which impersonated that key, since each development machine would require the assembly be test signed with a different key.

Adding a UAC Manifest to Managed Code

shawnfa — Thu, 06 Apr 2006 17:00:00 GMT

The UAC feature of Vista is one of my favorite new features -- it really makes running as a non-admin much less painful than it has been in the past. One of the requirements that UAC puts on developers is that we must mark our applications with manifests which declare if the application would like to run elevated or not. Documentation for this manifest format can be found on MSDN, where you can find the schema and information about what the various settings mean.

If you'd like to add one of these manifests to your managed application, the steps are relatively straight forward:

Create a manifest resource
Compile the resource
Embed it in your application

1. Create a manifest resource

The first step is to create a resource file containing your manifest. The manifest should be of type RT_MANIFEST, and have id 1 for an exe (id 2 for a dll). For instance, the resource script for an exe that does not need to elevate might be saved in UacManifest.rc and look like this:

#include <winuser.h>
#define IDR_MANIFEST 1 // 2 for a DLL

IDR_MANIFEST RT_MANIFEST MOVEABLE PURE
{
    "<assembly xmlns=""urn:schemas-microsoft-com:asm.v1"" manifestVersion=""1.0"">
       <asmv3:trustInfo xmlns:asmv3=""urn:schemas-microsoft-com:asm.v3"">
         <asmv3:security>
           <asmv3:requestedPrivileges>
             <asmv3:requestedExecutionLevel
               level=""asInvoker""
               uiAccess=""false"" />
           </asmv3:requestedPrivileges>
         </asmv3:security>
       </asmv3:trustInfo>
     </assembly>"
}

2. Compile the resource

You'll need to install the Platform SDK for this step so that you have access to the rc tool and the winuser.h header. Once you've gotten the SDK setup, you can then compile your resource script into a .res file:

C:\src\App>rc.exe UacManifest.rc

Which will create a UacManifest.res for you.

3. Embed it in your application

Now that you've compiled your .res file, you can pass it to your managed compiler when building your application to embed in your exe. The exact switch will vary depending on your compiler:

Compiler	Switch
C#	/win32res
VB	/win32resource
ILAsm	/resource
AL	/win32res

You can also select the resource file in the project properties in Visual Studio.

FxCop Transparency Rules

shawnfa — Tue, 04 Apr 2006 17:00:00 GMT

The FxCop team has just announced the availability of RC 1 of FxCop 1.35. Notable in this release is the introduction of the first three rules around security transparency. Namely, you'll see:

SecurityTransparentAssembliesShouldNotContainSecurityCriticalCode - fires when an assembly which is marked transparent contains any code which is marked critical.
SecurityTransparentCodeShouldNotAssert - fires when a block of transparent code attempts to execute a CAS Assert.
SecurityTransparentCodeShouldNotReferenceNonpublicSecurityCriticalCode - fires when transparent code attempts to use critical code which is not public or TreatAsSafe.

Return of the Mailbag

shawnfa — Tue, 21 Mar 2006 23:17:00 GMT

Over the last week or so I've seen a few questions pop up multiple times. In no particular order:

Q: Is calling a virtual method with a non-virtual call verifiable?

A: It depends :-) In v1.x of the CLR this was verifiable. We made a change in v2.0 which disallows a non-virtual call to a virtual method. Joe Duffy has a good writeup about this change and why we made it on his blog. Note that going the other way is verifiable -- using a callvirt to call a non-virtual function works just fine. In fact ildasm shows that the C# compiler always emits a callvirt regardless of the target being virtual or not.

Q: I want to create a signature using RSA and SHA-256, is that possible with the managed classes?

A: Not as of v2.0. The fundamental problem is that our only RSA implementation, RSACryptoServiceProvider, uses CAPI to do its work. However our only SHA-256 implementation, SHA256Managed is unknown to CAPI. This is on our radar for the next CLR release though.

Q: Is there any way to use ADMHost with a WinForms app so that the console window doesn't show up?

A: Sure. The underlying issue here is that in Windows, a PE image has its subsystem burned into its IMAGE_OPTIONAL_HEADER. Generally this is one of IMAGE_SUBSYSTEM_CUI or IMAGE_SUBSYSTEM_GUI ... although there are other options (they're listed under the comment "subsystem values" in winnt.h of the platform SDK if you're interested). Applications with a CUI subsystem always run with a console, weather or not they use it. (Windows has no way of knowing ahead of time if you do plan on using it or not). The opposite is true of GUI apps, which by default will not have a console window.

ADMHost.exe by default is compiled as a console application, using the CUI subsystem. Switch it to a Windows application and the console will go away. You can do this in the ADMHost.exe properties -- change the subsystem type to Windows.

The best part about today ...

shawnfa — Wed, 15 Feb 2006 00:33:00 GMT

... the availability of peanut butter cups 6 2/3 times bigger than normal.

The best part about tomorrow? They'll probably be available for less than a dollar at Safeway. I can feel the waistline growing already :-)

Happy Holidays

shawnfa — Mon, 19 Dec 2005 19:49:00 GMT

It's that time of year again when most of the offices around Microsoft start going dark, and I'll be adding 42/2221 to that list for the next couple of weeks as I head off to New York for Christmas. My traditional weather.com check shows that I should be expecting a 19 degree drop in temperature -- something that I'm not looking forward to :-) Once I thaw back out in January, we'll get back to our regularly scheduled security programming. Until then, keep those suggestions coming ... and Happy Holidays!

What Do You Want to See in Crypto / ClickOnce?

shawnfa — Thu, 15 Dec 2005 18:30:00 GMT

Now that Whidbey's out the door, it's time to look at what we want to do in future releases. If you've run into any issues with the crypto classes or with ClickOnce let me know! You can leave comments here or file requests in the MSDN Product Feedback...(read more)

A Look at the Xbox 360 CPU Design

shawnfa — Mon, 12 Dec 2005 20:38:00 GMT

Jeffery Brown has posted his paper on the Xbox 360 CPU Design from the Fall Processor Forum over on IBM's DeveloperWorks. Since I have my degree in hardware design, I always find these types of things interesting. While this paper is at a relatively high level, I still found several of the details fun to read about.

Especially interesting was the section on testing, debugging, and design validation. I clearly remember the day in ECE 323 (Hardware Design and Organization) when we discovered the benefits of adding test pins to our circuit design -- the final project for that class was to design a processor which executed some simple set of instructions and circuitry to host it. In order to grade the project, we gave our professor the byes for each opcode, and he ran a program on the board. If our design executed the program correctly we passed -- I believe that he had several different programs to step down to if you wouldn't work on the first one.

Needless to say, debugging a microcode programmed CPU design was no easy task -- and since we hadn't designed testing into the chip from the start, we were basically left hooking the oscilloscope up to various wires on the circuit board (wait -- which ones are the address bus again?), and executing repetitive code until we could narrow down the problems. Obviously this was not the most productive use of our time, and the semester was quickly drawing to a close.

After a late night of debugging the circuit, I finally hooked up some test pins. Basically there were two sets of debug pins -- input and output. The output pins went to a set of multiplexers, which switched over the various interesting parts of the circuit, while the input pins controlled the multiplexers. Finally there were one pair of input pins in particular which greatly aided debugging. The first enabled single step mode -- basically set a flip flop, which caused the processor to only execute an instruction if the step flip flop was also enabled. The second pin just set that step flip flop. So the logic looked like:

ip = ip + ( (singleStep & doStep) | (!singleStep) )

This worked well since our opcode design was that each opcode fit into a single byte, so we only ever had to increment by one. Once that was done, all that was left was to create a second debug circuit, which contained:

a seven segment display, with a decoder hooked up to the output debug pins
a set of toggles to select what the display was showing
a toggle switch to set debug mode
and a button to take one more step

Adding that basic debug support took a few hours that night, but the hours of time it saved us made it easily worth it. And from that point on, the leson was learned. Circuit design always included test and debug support from day one.

My other memory from that evening was getting back to the dorm after missing dinner due to getting this up and running. I was starving, and was looking forward to microwaving up some Ramen (since most of the pizza places were also closed by that point). My dorm room was right at the corner of the hallway, and as I rounded the corner my girlfriend at the time was coming around the other corner holding a bag with a Big Mac and super sized fries from the 24 hour McDonald's drive through in town. Not that there's anything wrong with a Ramen dinner, but was that ever a sight for sore eyes! :-)

Updated 10:31 AM - fixed xbox link