The Connected Information Security Group

This Blog URL Has Changed – Please Update Your Readers

cisg — Thu, 16 Apr 2009 17:52:32 GMT

Things have been quite on the blog for while. There is a LOT of code being cranked out at the moment as we work towards some deadlines in the summer on various projects.

Our team name has also changed from the Connected Information Security Group (CISG) to the Microsoft IT Information Security Tools Team. This reflects an increased scope of tools that we are building and areas that we are focusing on so we have updated the blog URL. Well leave all the content as is on this blog but all new content will be posted at the new URL.

As well as news about significant work on CAT.NET and a Beta for TAM 3.0 we plan to start sharing details of the development framework CISF that we are building and a Risk Tracker application; both of which we plan to release open source under an MS-PL license this summer. CISF is a set of reusable components and code from which you can assemble your own security management applications (including gluing various security tools and technology together). It’s built in C# and on the MSFT technology stack (.NET 3.5 (WWF, WCF. ASP.NET etc)), SQL Server 2008 and Windows Server. You can think of Risk Tracker as a “Security Starter Kit” using the CISF; it’s essentially a Risk Tracking application that we have built internally for the corporate information security team which we will generalize and share with the community. You will be able to run it as is or extend it with .NET and the CISF. We plan to extend both tools on a regular basis (quarterly updates) as we improve the tools and technology for internal use.

More news in a few weeks!

You can subscribe to the new blog at http://blogs.msdn.com/securitytools

Cheers!

Mark

CAT.NET New Build – 1.1.1.8

cisg — Fri, 20 Mar 2009 22:02:47 GMT

Mainly small bug fixes and a new feature to export the findings into an Excel spreadsheet.

Download link is -

http://www.microsoft.com/downloads/details.aspx?FamilyId=0178e2ef-9da8-445e-9348-c93f24cc9f9d&displaylang=en

We recommend all users to upgrade to this version.

We have some work now starting on new features including general performance improvements, UI improvements and rules maintenance. We expect these to be complete by summer after which time we then expect to undertake some core engine updates to significantly improve the performance, scalability and vulnerability coverage.

Note: The MSDN download page says 1.0 but it is 1.1.1.8. well fix that ;-)

Getting Help for CAT.NET and Anti-XSS

cisg — Mon, 23 Feb 2009 17:42:23 GMT

We now have a discussion forum for users of CAT.NET. There is no official support for these tools but you can ask questions and we will try to help wherever we can!

CAT.NET -

http://social.msdn.microsoft.com/Forums/en-US/catnet/threads/

Anti-XSS -

http://www.codeplex.com/AntiXSS/Thread/List.aspx

MSDN Webcast: Software Security with Static Code Analysis Using CAT.NET (Level 200)

cisg — Tue, 17 Feb 2009 02:32:04 GMT

Event Overview

In this webcast, we provide an overview of what static code analysis is and typical coding errors that static analysis can and cannot detect. We also look at the recently released CAT.NET tool and how it helps with the detection of security flaws.

Presenter: Andreas Fuchsberger, Senior Software Design Engineer, Microsoft Corporation

AntiXSS Library V3.0 - Test Harness

cisg — Mon, 19 Jan 2009 13:55:15 GMT

Hi, Anil Chintala here…

In this post I wanted to talk about the new Test Harness application which was released as part of the AntiXSS V3.0 Beta and is available as a free download on MSDN with source code available for download on CodePlex. Test Harness application is created to help the users to quickly get started and validate the successful blocking of XSS issues by the Library and also to measure the enhanced performance claims of the AntiXSS V 3.0 against Microsoft .NET encoding library.

AntiXSS Test Harness is a windows console application that automates the following two categories of tests - XSS validation and performance tests. When executed, AntiXSS Test Harness displays this console menu:

Performance Test Bench uses HtmlEncode() method as a benchmark for measuring performance of the AntiXSS library - AntiXss.HtmlEncoding(…) method against the .NET - HttpUtility.HtmlEncode(…) encoding method. Input strings with a combination of safe and un-safe characters are used as payload to run the automated performance tests.

Choosing Option#1, Performance Test Bench executes performance tests that analyze such metrics as:

Input string lengths
Encoded output strings
and the total time taken for its execution.

During its run, Performance Test Bench compares the execution times of .NET's HttpUtility.HtmlEncode and AntiXss.HtmlEncode and stores in an output file containing results as displayed in this illustration:

XSS Validation Test Bench demonstrates the successful blocking of cross-site scripts. These tests use a list of XSS exploits as payload for running the automated tests. XSS exploit list are read from a text file, each payload is run through HTMLEncode() method of the library and the encoded output is stored in an output file.

When Option 2 is selected from the above console screen, Test Harness application executes the XSS validation tests and produces the following output file:

Test Harness Application provides a framework for automating the XSS validation and performance evaluation. Primary objective is to help developers and testers to quickly get started and test AntiXSS library for XSS validation and performance. With the availability of source code on CodePlex it also allows advanced users to extend the automated testing capabilities as per your specific requirements.

Thanks and more later…

Current Memory Limitations of CAT.NET

cisg — Mon, 12 Jan 2009 15:19:39 GMT

Hi, Andreas Fuchsberger here.....

It is important to understand what happens CAT.NET builds its Call Flow Super Graphs. We use a CCI object called CciControlGraph to build a Control Flow Graph for each method and each method call we find in the Common Intermediate Language (CIL) of the modules being analysed. These individual control flow graphs are collected together in a .NET List object.

Unfortunately this is where we start to encounter a shortcoming in the implementation. Even with virtual memory there are limits to how much memory a single .NET application can allocate. As reported in recent blog post a 32-bit process, such as the CAT.NET Visual Studio plug-in version can only allocate about 1200 MB, even on a 4GB RAM (32-bit) system. Moreover another shortcoming of the current implementation is that when CAT.NET runs out of memory is it exits with an unhandled OutOfMemory (OOM) exception, unfortunately this does not get reported by the Visual Studio plug-in and the plug-in just seems to hang.

There is a solution, on the same 4 GB RAM system you can more than double the amount of memory available to CAT.NET by using a 64-bit version of Vista or Windows Server and the 64-bit command line version of CAT.NET. This is why we supply the 64-bit command line version of the CAT.NET binaries: (http://www.microsoft.com/downloads/details.aspx?FamilyID=e0052bba-2d50-4214-b65b-37e5ef44f146).

For those without the option of running on a 64-bit system, one manual method for analysing larger applications that the 32-bit version of CAT.NET fails to do is to restrict the number of modules that are passed to CAT.NET. For a developer analysing their own code it is relatively easy to make sensible choices which modules should be analysed together. Typically they would choose all the their own as code that receives user input and any dependant modules, e.g. third party libraries, that process that input to produce an output, leaving all other business logic modules aside. However it must be pointed out that this method lead to some vulnerabilities being missed.

We are working on scalable long term solutions to these sorts of problems which require some relatively heavy lifting on our part. For today hopefully the above advice will at least help understand why the issue happens.

Free MSDN Webcast: Managing Cross-Site Scripting Using CAT.NET and AntiXSS (Level 200)

cisg — Sun, 04 Jan 2009 12:36:46 GMT

Language(s):
English.

Product(s):
Security.

Audience(s):
Developer.

Duration:
60 Minutes

Start Date:

Friday, January 09, 2009 12:00 PM Pacific Time (US & Canada)

Merlin: Better Specifications for CAT.NET

cisg — Fri, 02 Jan 2009 22:05:44 GMT

Guest post by Ben Livshits of Microsoft Research here....

In the last several years we have seen a proliferation of static (and sometimes runtime) analysis tools for finding web application vulnerabilities. Companies such as Fortify, Ouncelabs, Klockwork, and others have been selling tools for finding security flaws for a while now. Most focus of the OWASP top 10, a list being dominated by XSS, SQL injection, CSRF, etc.

CAT.NET is a state-of-the-art static analysis tool for .NET that we have built at Microsoft and released for free to all of our customers.

The effectiveness of these tools is generally seen as a function of false positives and false negatives. Ideally, of course, you want to find all real vulnerabilities and eliminate all false alarms. In practice, most tools have to cut corners to avoid erring too much in either direction. While much has been said about the approaches to static analysis and improving result quality, an Achilles heel of any analysis tool is the quality of the specification that comes with. Simply, the analysis engine needs to be told what to look for. If the tool doesn’t know what methods are used for sending queries to a database and are therefore crucial to SQL injection finding or if some taint sources are omitted for XSS, some potential vulnerabilities will go missing. The following is but a short list of taint sources in typical .NET APIs:

Request.Params
Request.QueryString
Request.Form
Request.Headers

Request.ServerVariables
Request.Cookies
TextBox.Text
HiddenField.Value

However, as a recent blog post discusses, this list is woefully incomplete. Even in the case of taint-style vulnerabilities, coming up with a complete specification is really hard for several reasons. First, it often requires pouring over tons of potentially relevant APIs. There are about 30 methods in .NET base class libraries alone that CAT.NET considers to be taint sources. Second, in many cases, the specification is application- or library-specific. For a large-scale app, it’s not uncommon to have a custom encoder or a sanitizer. Unless the tool knows about it, false positives will likely result.

Enter Merlin, an add-on for CAT.NET that aims to produce a better, more complete and accurate specification for finding security bugs. Merlin uses the intuition embedded within the application itself to infer a better specification.

Code Example

Consider a simple example below. Suppose we are trying to classify functions ReadData1, ReadData2, WriteData, and Cleanse as either sources, sanitizers, or sinks. Unless we know something else about these example, this is hard to do.

                1: void ProcessRequest()

               2: {

               3:    string s1 = ReadData1("name");

               4:    string s2 = ReadData2("encoding");

               5:  

               6:    string s3 = Cleanse(s1);

               7:  

               8:    WriteData("Parameter " + s1);

               9:    WriteData("Header " + s2);

              10: }

However, if you are told that ReadData1 and ReadData2 are sources and Cleanse is a sanitizer, then WriteData is likely to be is a sink. Why? Because why else would the developer sanitize tainted input on not one, but two paths. This is most obvious if you look at the propagation graph on the right.

In other words, the program itself contains valuable clues that tell us what the developer thought these functions were with respect to tainting or untaining values. Of course, the developer could still be wrong, there would be no vulnerabilities otherwise, so Merlin generally looks for preponderance of evidence before drawing any conclusions. In this case, Merlin will be able to classify WriteData as a sink with a pretty high probability. The technique that Merlin uses called statistical inference is a generalization of the intuition above.

What does Merlin give us: some results

Before we talk about the gory technical details, which are also described in great detail in our technical report, I’ll give you a glimpse of what our approach can do by citing some experimental results. What is utterly surprising is that, without requiring any initial specification at all, Merlin is able to derive the following specification shown on the right from the little program below.

       1: protected void TextChanged(object sender, EventArgs e) {

       2:     string str = Request.QueryString["name"];

       3:     string str2 = HttpUtility.HtmlEncode(str);

       4:     Response.Write(str2);

       5: }

       6: protected void ButtonClicked(object sender, EventArgs e) {

       7:     string str = Request.UrlReferrer.AbsolutePath;

       8:     string str2 = HttpUtility.UrlEncode(str);

       9:     Response.Redirect(str2);

      10: }

Here is what Merlin infers for this example program:

Sources (1):
string System.Web.HttpUtility+UrlDecoder.Getstring()
Sanitizers (8):
string System.Web.HttpUtility.HtmlEncode(string)
string System.Web.HttpUtility.UrlEncodeSpaces(string)
string System.Web.HttpServerUtility.UrlDecode(string)
string System.Web.HttpUtility.UrlEncode(string, Encoding)
string System.Web.HttpUtility.UrlEncode(string)
string System.Web.HttpServerUtility.UrlEncode(string)
string System.Web.HttpUtility.UrlDecodestringFromstringInternal...
string System.Web.HttpUtility.UrlDecode(string, Encoding)
Sinks (4):
void System.Web.HttpResponse.WriteFile(string)
void System.Web.HttpRequest.set_QuerystringText(string)
void System.IO.TextWriter.Write(string)
void System.Web.HttpResponse.Redirect(string)

This is actually a pretty good start! I highlighted a few of the methods so that you can look up their definition at MSDN. The sanitizers are in fact standard URL and HTML encoders provided by .NET. Note that even some of these are missing from the default .NET specification. You will recognize some other methods like HttpResponse.Redirect as sinks for the reflective XSS vulnerability. Similarly, HttpResponse.WriteFile exposes a command injection vulnerability.

Of course, the better your initial specification, the more Merlin can help. The second part of this blog will talk about the technical aspects of Merlin inference and also show some more results.

Technorati Tags: CAT.NET,static analysis

Security Code Review Using CAT.NET - Part 2

cisg — Mon, 22 Dec 2008 12:24:55 GMT

Hi Andreas Fuchsberger here again......

How does CAT.NET work?

As I mentioned in Part 1 here, CAT.NET is an information-flow type static analysis tool using an implementation of tainted-variable analysis.

Tainted-variable analysis is an integrity problem in which that tries to identify whether less-trusted data obtained from the user might influence other data that the system trusts. Clearly, to do this analysis, sources and sinks of possibly tainted data need to be identified. For managed code, this amounts to identifying methods that originate a tainted value and methods that use a possibly tainted value. For CAT.NET a number of XML of user editable configuration files is used to define sources and sinks. Then CAT.NET needs to find how information is stored in a variable and where it is used later in any other module of the application.

CAT.NET uses the Common Compiler Infrastructure (CCI) which is used extensively within Microsoft for building compiler-like tools.CCI is an integrated set of components that encapsulate the logic that compilers and related development tools typically have in common. CCI has many features but firstly for CAT.NET it has the ability to read the Common Intermediate Language (CIL) used to store binary code in a .NET Framework assembly directly.

Further to perform its analysis CAT.NET needs to build of a specific heap analysis called flow-insensitive points-to analysis. This analysis computes a “may point to” relation over a loaded assembly or assemblies, we’ll call this relation pointsTo, where pointsTo(o₁.f, o₂) means that the field f of the object named o₁ might refer to the object named o₂ in some execution of the program. A may-point-to relation is also computed for local variables: pointsTo(υ, o) means that the local variable υ might refer to the object named o. The relation pointsTo(υ.f, o) holds if there exists an o’ such that pointsTo(υ, o’) and pointsTo(o’.f, o).

CAT.NET uses a combination of Control Flow and Data Flow Graphs and to build the relation for every object in every module supplied to CAT.NET.

Control Flow Graphs

A control flow graph (CFG) is a representation of a program where contiguous regions of code without branches, known as basic blocks, are represented as nodes in a graph and edges between nodes indicate the possible flow of the program. A CFG shows the sequence of events as a program executes.

Data Flow Graphs

A data-flow graph (DFG) is a graph which represents operations and data dependencies and the order the operations are performed. As such any algorithm consists of a number of ordered operations. However simple DFGs are not able to represent loops or sub routine branching. Data Flow Graphs are therefore are often augmented with control-flow information and are then known as Control Data Flow Graphs (CDFG). A DFG consists of nodes and arcs, where the each node represented has an input or an output port and an arc represents a connection between and input and output port.

Data Flow Super Graphs

Defined by CAT.NET a data flow super graph is a special type of data flow graph that contains data flow information at both an intra-procedural and inter-procedural level.

CCI provides functions for building the Data Flow and Control Flow Graphs on an intra-procedural level and CAT.NET uses these to build a Data Flow Super Graph. The Data Flow Super Graph that CAT.NET builds covers all objects across methods in all modules on an inter-procedural level.

Once the Data Flow Super Graph is built, CAT.NET iterates for each of the XML that makes up the CAT.NET rules across Data Flow Super Graph to find all data flow paths between the sources and the sinks. It does this by traversing each path in the Data Flow Super Graph and colouring (i.e. assigning a constant to a traversed path) the graph according to the variables use.

Before reporting a source is linked to a sink, CAT.NET checks how the variable is transformed and filters out valid transformations. Variables that remain tainted once a complete source to sink path has been traversed are reported as a possible vulnerability in the original code including file name and line numbers.

In the next post I will explain the semantics of the XML rules and how to modify the supplied rule set.

Security Code Review Using CAT.NET - Part 1

cisg — Mon, 22 Dec 2008 12:20:19 GMT

Hi Andreas Fuchsberger here …

To coincide with the CTP release of CAT.NET and Anti-XSS, within the CSIG we have been taking a long hard look at static analysis tools for developers and Information Security professionals. Over the next series of blog posts I will explain the fundamentals of the techniques used for a code review in general and static code analysis in particular.

Today we start with an introduction into the review process and as well having a look at the techniques for automating some of the code review burden; and don't worry we will build up to the details fast.

In general we differentiate between a code review (source code) and an architectural review (software architecture). Although CAT.NET actually reads binary, actually Microsoft Intermediate Language code, it falls into the class of source code review tools.

What is a code review?

We say a code review is the process of systematically examining the source code written by one developer by someone other than the original developer, often called a reviewer. The reviewer could be a colleague or fellow developer or someone with similar developer background and skill set then we refer to this as a peer-review. Although most developers see the purpose of a code review to find coding errors the true value really lies really in the reviewer questioning assumptions by the original developer. It is often these unconsciously made assumptions that are the cause of business logic errors but also simple security errors (“Oh the user would never try to enter more than 10 digit telephone number”) .

Formal roots of the code review go as far back as 1983 when it was first mentioned in a standard, IEEE 729, although it is probably true to say that code reviews took place before using corporate or in-house rules.

According to the IEEE standard 729 “Glossary of Software Engineering Terminology”, which has since been republished as IEEE 610.12, a review is formally planned and structured analysis and evaluation process, during which the project results are presented to a team of consultant reviewers and commentated or approved by them.

The reviewer could be a fellow software developer. For inexperienced developers a code review offers a good opportunity to learn, for an experienced developer it offers the opportunity for training themselves in fast and hands-on manner.

And this unfortunately this is why the review process is so expensive both in cost of time and money. Reviewers are highly skilled people and performing a review takes time. So for some time now the Information Security research community has proposed automatic analysis techniques for identifying security vulnerabilities in code. Such techniques may employ dynamic analysis, static analysis, or both.

Dynamic analysis entails executing the program and inferring properties from its observed behaviour. Although dynamic analysis may expose bugs, it cannot ensure complete coverage of the target program as not all program paths may be actually run.

Instead, developers have adopted an approach based on sound analysis, which can provably identify all possible violations of specific security guidelines.

In contrast Static analysis does not execute the code but analyses the code itself. Simple static analysis tools analyses the actual source code, however increasingly modern static analysis tools use also or only look at the binary output of the compiler. For intermediate code output, such as Microsoft’s .NET Framework, this is in fact often preferable as the intermediate output still contains type information and

Static analysis techniques

There exist a number of static analysis techniques that can be used to automatically detect security errors in source code. These techniques cover three areas that have been associated with sources of security vulnerabilities:

Access control
Information flow
- Integrity violations
- Confidentiality violations
API conformance

Access control: Mechanisms for access control restrict access to security-sensitive resources based on a user's identity and/or membership in predefined groups. Ensuring that an access control policy enforces the required level of security can be difficult, especially for systems with many components of different trust levels with access to a multitude of restricted resources. If an access control policy does not grant sufficient permissions to users, runtime authorization failures will occur. On the other hand, if an access control policy grants users unnecessary permissions, this will result in exposing the exposing the system to security attacks.

Information flow: A secure information flow ensures that information propagates throughout the execution environment without violating two security integrity properties:

Integrity violations arise when untrusted information flows into a trusted execution environment without having been properly validated. A malicious user could compromise a system by exploiting an integrity violation.

Confidentiality violations arise when confidential information flows from a restricted execution environment to a public one without having been properly declassified. For example, a confidentiality violation arises if trusted code exposes a cryptographic private key to untrusted code.

API conformance: Applications often rely on libraries and third-party APIs to provide security-sensitive services. As an example, many applications rely heavily on cryptography libraries to protect confidentiality, prevent integrity violations, and distinguish between trusted and untrusted entities. Incorrect usage of cryptographic functions may lead to insecure storage of security-sensitive information and cause violations of integrity and confidentiality policies.

Our CAT.NET tool is based on finding integrity violations by performing a tainted data flow analysis. Future posting will take a closer look at the algorithms we used for performing our analysis.

CAT.NET CTP Links Are Live Again!

cisg — Thu, 18 Dec 2008 03:37:50 GMT

Download CAT.NET CTP (32 bit here and 64 bit here)

Anti-XSS was not affected but for completeness

Download Anti-XSS 3.0 Beta (here and source code here)

Our sincere apologies.

CAT.NET Status Update

cisg — Wed, 17 Dec 2008 23:05:19 GMT

12 pm PST 17th, December.

We continue to face issues with the download links. We are doing everything we can to resolve this and expect it to be resolved within a few hours.

We will update this blog with any further news.

Our sincere apologies.

Secure String in .Net - Part II

cisg — Wed, 17 Dec 2008 15:59:18 GMT

Hi Gaurav Sharma here with more information about SecureStrings. This time I'll cover following topics:

SecureString internals
Performance

Let us start with our first topic,

SECURE STRING INTERNALS
- BASICS
  - Class Name: SecureString
  - Assembly: mscorlib.dll
  - Latest Version: 2.0.0.0
  - Namespace: System.Security
  - Implements: IDisposable
  - Inherits: CriticalFinalizerObject
  - Access Specifier: Public
  - Can be inherited: No, it is a sealed class
- INTERNALS
  - Constructors - SecureString type contains four constructor implementations out of which one is a type constructor and other three are instance constructors.
    - static SecureString()
      - As this is a static constructor, this is called before any member of SecureString type is accessed. Internally, only thing it does is, it sets a flag supportedOnCurrentPlatform to true or false.
      - To set this boolean value a call is made to Win32 native RtlDecryptMemory method. This method is available as a resource named SystemFunction041 in Advapi32.dll. This method call is made to check wether current operating system supports encryption and decryption.
      - If this method entry is not found then supportedOnCurrentPlatform is set to false otherwise it is set to true.
      - All other constructors first check for this boolean value and if it is set to false then a NotSupportedException is thrown.
    - public SecureString()
      - Checks supportedOnCurrentPlatform variable and throws NotSupportedException exception if it is false.
      - If supportedOnCurrentPlatform is true then buffer of 8 bytes is allocated. Methods used to allocate space are decorated with [ReliabilityContract(Consistency.WillNotCorruptState)] attribute. This means that in the face of exceptional conditions, the method/s is guaranteed not to corrupt state.
      - In case of invalid buffer state or invalid memory allocation request, OutOfMemoryException() will be thrown.
    - internal SecureString(SecureString str)
      - This constructor takes an existing SecureString object as a parameter and creates a new SecureString object with length and data of existing object.
      - This time there is no check for supportedOnCurrentPlatform as already there is an active secure string object (passed as parameter) which indirectly means that SecureStrings are supported on this platform.
    - public unsafe SecureString(char* value, int length)
      - This is non CLS compliant as it uses pointers.
      - Contents of memory area specified by char* are copied to a new byte* .
      - Data content is then encrypted by making a call to Win32 native RtlEncryptMemory method. This method is available as a resource named SystemFunction040 in Advapi32.dll. This process is called Protecting Memory and is implemented in the ProtectMemory() method explained in next section.
      - In case of error while protecting memory a CryptographicException is thrown.
  - Encryption and Decryption - SecureString class implements encryption and decryption using ProtectMemory() and UnProtectMemory() methods respectively
    - ProtectMemory()
      - private method
      - Some of the SecureString methods that use ProtectMemory() are,
        
        Constructor - public unsafe SecureString(char* value, int length)
        
        AppendChar(Char)
        
        InsertAt(Int32, Char)
        
        RemoveAt(Int32)
        
        SetAt(Int32,Char)
      - This method is decorated with [ReliabilityContract(Consistency.MayCorruptInstance, Cer.MayFail)] attribute. Here Consistency.MayCorruptInstance means that in the face of exceptional conditions, the method is guaranteed to limit state corruption to the current instance. Whereas, Cer.MayFail means that in the face of exceptional conditions, the method might fail. In this case, the method will report back to the calling method whether it succeeded or failed.
      - Pseudocode
        
        [ReliabilityContract(Consistency.MayCorruptInstance, Cer.MayFail)]
        
        ProtectMemory()
        
        {
        
        IF ((Length OF SecureStringObj IS NOT 0) AND (SecureStringObj IS NOT Encrypted))
        
        {
        
        BEGIN Constrained Execution Region
        
        {
        
        CALL Win32Native.RtlEncryptMemory method AND Store Result IN @RES
        
        IF (@RES Shows Error)
        
        THROW CRYPTOGRAPHIC_EXCEPTION
        
        ELSE
        
        SET SecureStringObj.IsEncrypted to TRUE;
        
        }
        
        }
        
        }
    - UnProtectMemory()
      - private method
      - Some of the SecureString methods that use UnProtectMemory() are,
        
        Constructor - public unsafe SecureString(char* value, int length)
        
        AppendChar(Char)
        
        InsertAt(Int32, Char)
        
        RemoveAt(Int32)
        
        SetAt(Int32,Char)
      - This method is decorated with [ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success)] attribute. Here Consistency.WillNotCorruptState means that in the face of exceptional conditions, the method is guaranteed not to corrupt state. Whereas, Cer.Success means that in the face of exceptional conditions, the method is guaranteed to succeed.
      - Pseudo
        
        [ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success)]
        
        UnProtectMemory()
        
        {
        
        IF ((Length OF SecureStringObj IS NOT 0) AND (SecureStringObj IS Encrypted))
        
        {
        
        BEGIN Constrained Execution Region
        
        {
        
        CALL Win32Native.RtlDecryptMemory method AND Store Result IN @RES
        
        IF (@RES Shows Error)
        
        THROW CRYPTOGRAPHIC_EXCEPTION
        
        ELSE
        
        SET SecureStringObj.IsEncrypted to FALSE;
        
        }
        
        }
        
        }
    - Both these methods are so implemented that in no case they can create instability in an application.
    - You can get more details about constraint execution region from MSDN
PERFORMANCE

I think, comparing String and SecureString is not completely justified. SecureString was created taking in mind the shortcomings of String class. The way in which SecureString works like managing pointers, creating constrained execution regions, encryption and decryption, it is bound to be on the slower side of performance. In this section I'll try to show you exactly how much slower SecureString is as compared to tradition String class.

STRING CREATION

Code Snippet

   1:  Int32 loopCounter = 0;

   2:  Int32 loopMaxCounter = 100000;

   3:  List<SecureString> secStrList = new List<SecureString>();

   4:  Stopwatch sw = new Stopwatch();

   5:  sw.Start();

6:

   7:  sw.Reset();

   8:  List<String> StrList = new List<String>();

   9:  sw.Start();

  10:  Console.WriteLine("-----------------------------------------------------------");

  11:  Console.WriteLine("Creating 100000 instances of strings");

  12:  for (loopCounter = 0; loopCounter < loopMaxCounter; loopCounter++)

  13:  {

  14:      String str = new string(new Char[] { 'a' });

  15:      StrList.Add(str);

  16:  }

  17:  Console.WriteLine("Created 100000 instances of string. Elapsed time (in milliseconds) " +

  18:  sw.Elapsed.Milliseconds.ToString());

  19:  Console.WriteLine("-----------------------------------------------------------");

  20:  sw.Stop();

  21:  sw.Reset();

  22:  sw.Start();

  23:  Console.WriteLine("-----------------------------------------------------------");

  24:  Console.WriteLine("Creating 100000 instances of secure strings");

  25:  for (loopCounter = 0; loopCounter < loopMaxCounter; loopCounter++)

  26:  {

  27:      SecureString obj = new SecureString();

  28:      obj.AppendChar('a');

  29:      secStrList.Add(obj);

  30:  }

  31:  Console.WriteLine("Created 100000 instances of secure string. Elapsed time (in milliseconds)" +

  32:      sw.Elapsed.Milliseconds.ToString());

  33:  sw.Stop();

  34:  Console.WriteLine("-----------------------------------------------------------");

Result

STRING MANIPULATION - Appending characters using AppendChar() method

Code Snippet

   1:  SecureString secString = new SecureString();

2:

   3:  String str=String.Empty;

   4:  Stopwatch sw = new Stopwatch();

5:

   6:  Int32 loopCounter = 0;

   7:  Int32 loopMaxCounter = 10000;

   8:  Console.WriteLine("---------------------------------------------------------");

   9:  Console.WriteLine("Loop will run {0} times",loopMaxCounter);

  10:  Console.WriteLine("Current String Length  is {0}", str.Length.ToString());

  11:  sw.Start();

  12:  for (loopCounter = 0; loopCounter < loopMaxCounter; loopCounter++)

  13:  {

  14:      str = str + "a";

  15:  }

  16:  Console.WriteLine("String insertion completed in {0} milliseconds",sw.Elapsed.Milliseconds.ToString());

  17:  Console.WriteLine("Current length of String is {0}.", str.Length.ToString());

  18:  Console.WriteLine("----------------------------------------------------------");

  19:  sw.Stop();

  20:  sw.Reset();

  21:  sw.Start();

  22:  Console.WriteLine("----------------------------------------------------------");

  23:  Console.WriteLine("Loop will run {0} times", loopMaxCounter);

  24:  Console.WriteLine("Current Secure String Length  is {0}", str.Length.ToString());

  25:  for (loopCounter = 0; loopCounter < loopMaxCounter; loopCounter++)

  26:  {

  27:      try

  28:      {

  29:          secString.AppendChar('a');

  30:      }

  31:      catch (Exception ex)

  32:      {

  33:          Console.WriteLine(ex.ToString());

  34:      }

  35:  }

  36:  Console.WriteLine("Secure String insertion completed in {0} milliseconds", sw.Elapsed.Milliseconds.ToString());

  37:  Console.WriteLine("Current length of Secure String is {0}.", secString.Length.ToString());

  38:  Console.WriteLine("-----------------------------------------------------------");

  39:  sw.Stop();

  40:  Console.Read();

Result

If we search for SecureString on web we can find a lot of questions going around related to pros and cons of SecureString usage. I'll compile a list of all of such type of questions in my next post.

Below are some reference sources that I used to get information related to secure string internals.

REFERENCES

Subject	Link
ReliabilityContract	http://msdn.microsoft.com/en-us/library/system.runtime.constrainedexecution.reliabilitycontractattribute.aspx
Consistency Enum	http://msdn.microsoft.com/en-us/library/system.runtime.constrainedexecution.consistency.aspx
Cer	http://msdn.microsoft.com/en-us/library/system.runtime.constrainedexecution.cer.aspx
Constrained Execution Region	http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.runtimehelpers.prepareconstrainedregions.aspx
Win32Native.RtlDecryptMemory	http://msdn.microsoft.com/en-us/library/aa387692(VS.85).aspx
Win32Native.RtlEncryptMemory	http://msdn.microsoft.com/en-us/library/aa387693(VS.85).aspx

Download Problem for CAT.NET - Status Update

cisg — Wed, 17 Dec 2008 02:34:57 GMT

We are continuing to experience problems with the 32 bit download link for CAT.NET. We now estimate a fix by mid-day PST tomorrow (17th December).

The 64 bit download link is active again here.

I will post here as soon as it is resolved.

Our continued apologies.

Download Problem for CAT.NET - Status Update

cisg — Tue, 16 Dec 2008 17:53:04 GMT

We are continuing to experience problem with the links to download CAT.NET. We estimate a fix by 5pm today (16th December).

I will post here as soon as it is resolved.

Our continued apologies.

How the Anti-XSS 3.0 SRE Works

cisg — Tue, 16 Dec 2008 14:41:26 GMT

RV again...

Last time around we looked at SRE from a conceptual perspective, this time lets look at from a code perspective. Lets trace the program flow and understand in depth what SRE code does.

SRE is a HttpModule, the main class file is AntiXssModule.cs which inherits from IHttpModule. In the Init() event of HttpModule we hook on to HttpApplication.PostMapRequestHandler() event which gets raised when an ASP.NET handler is processing the current user request. In this case we are trying to find out when the ASP.NET Page handler is processing the page. As System.Web.UI.Page is both a HttpHandler and Page class that an ASP.NET page represents, we can use it to hook on to the PreRender event. Additional checks are performed to determine whether the page is excluded or whether the class is marked with SupressAntiXssEncodingAttribute.

   1: public void Init(HttpApplication context)

   2: {

   3:     this.LoadConfig(context, AppDomain.CurrentDomain.BaseDirectory +

   4:                                             "antixssmodule.config");

   5:     if (objConfig != null)

   6:     {

   7:         objApp = context;

   8:         objApp.PostMapRequestHandler += new

   9:                             EventHandler(objApp_PostMapRequestHandler);

  10:     }

  11: }

LoadConfig uses the Configuration/ModuleConfiguration.cs class to load and parse the XML to create an object of ModuleConfiguration class and stores it in Application state variable for which can be reused through out the lifetime of the application. There is a drawback with using this approach whenever you make a change to antixssmodule.config file, the application needs to be restarted for those changes to be applied.

   1: void objApp_PostMapRequestHandler(object sender, EventArgs e)

   2: {

   3:     //...validations & exclusion checks

   4:     if (objConfig != null)

   5:     {

   6:         string strVirPath = objApp.Context.Request.FilePath;

   7:         if (objConfig.IsPageExcluded(strVirPath.ToLower()))

   8:         {

   9:             return;

  10:         }

  11:     }

12:

  13:     //attribute checks

  14:     object[] attributes = ((Page)pageHandler).GetType().GetCustomAttributes
                                     (typeof(SupressAntiXssEncodingAttribute), true);

  15:     if (attributes.Length > 0)

  16:         return;

  17:     Page page = (Page)pageHandler;

18:

  19:     //Calling the static class to do the rest of the job

  20:     XssProtection.Protect(page, objConfig);

21:

  22: }

In the PostMapRequestHandler after the checks we call the XssProtection.Protect method which hooks on to the Page.PreRender event. This way we wait till page gets processed, all properties and controls are built by ASP.NET. During prerender we iterate through the control collection of the page and find controls which need to be encoded. Specified properties in the configuration file are then encoded based on the encoding type using the AntiXss library. As the properties are dynamically defined in the XML configuration file, property values are set using reflection. In essence XssProtection class is the main class responsible for encoding the page controls properties.

The following is a screenshot of Visio sequence diagram of the above things.

For more information and insight into code please check http://www.codeplex.com/antixss.

Thanks
RV

Anti-XSS 3.0 Beta and CAT.NET Community Technology Preview now Live!

cisg — Mon, 15 Dec 2008 12:01:52 GMT

Mark Curphey here.....

I am delighted to say that we have released two new free tools.

Download CAT.NET CTP (32 bit here and 64 bit here)
Download Anti-XSS 3.0 Beta (here and source code here)

CAT.NET - Community Technology Preview

CAT.NET is a managed code static analysis tool for finding security vulnerabilities. It's exactly the same tool we use internally to scan all of our Line of Business (LOB) applications; it runs as a Visual Studio plug-in or as a stand-alone application. It was engineered by this group (CISG) and has been designed in partnership with the ACE Team and Microsoft Research. The ACE Team do thousands of code reviews for the internal line of business applications and for our external customers and have provided a wealth of real world knowledge and experience to the tool over the years. We will be posting several deep dive blogs this week on the inner workings of call graph and flow graph analysis and the algorithms behind CAT.NET from MSR. It is a technology preview; we appreciate that there are some performance and functionality limitations that we will be working on over time but we are already deep in discussion about the future design of CAT.NET and it's looking potentially very compelling!

You can download the current CTP builds from MSDN (32 bit here and 64 bit here) submit bugs and feedback to our Connect site (see post later this week for details).

Anti-XSS 3.0 - Beta

Cross Site Scripting (XSS) continues to plague web sites and among others things has become known as a common attack vector for Phishing attacks to distribute payloads to unsuspecting users.

With this release we have taken a fresh look at how to provide protection to ASP.NET applications. As well as significantly better coverage for internationalisation in the core library and significantly improved performance, we are now are now shipping with the Security Runtime Engine (SRE), a .NET CLR plug-in that overrides default encoding's to render sites safe from XSS with zero code changes. While the SRE can not be used in every circumstance and cannot prevent every type of XSS, we believe it will provide great coverage in a wide variety of situations and forms another important layer in a defence in depth strategy. In testing on our own applications in Microsoft IT we have typically seen the ability to fix between 50% and 90% of XSS issues in an application out of the box with no code changes needed. We are experimenting with preventing other attacks beyond XSS and expect to extend coverage in future releases.

With this release we are also shipping with a performance test harness so you can test your own applications in pre-production and a copy of our own performance results conducted by the ACE Team as well as a sample application that you can use to demonstrate the attack and how to fix it to your development teams. Another significant change is that Anti-XSS 3.0 is now being released as an open source tool using the MS-PL license at Codeplex.

You can download the current beta binaries from MSDN here and source code from CodePlex here. For Anti-XSS you can submit bugs and feedback directly to our CodePlex site here.

Look for detailed posts about both Anti-XSS and CAT.NET on this blog this week and updates about these and related technologies on this blog.

Subscribe via RSS here.

Happy Holidays!

Mark

An Update on Some Upcoming Free Tools

cisg — Thu, 13 Nov 2008 21:41:12 GMT

Mark Curphey here.....

If the economy is getting you down here is some good news. We may have been quiet for the last few weeks but that's because we've been busy!

Anti-XSS 3.0 is being released as an internal beta today. We are aiming for a public beta on codeplex within a few weeks. That's right, Anti-XSS 3.0 will be coming out as an open source project under the MS-PL license on codeplex. The project includes a completely re-written library with increased functionality and now running and near native speed and the new Security Runtime Engine (hooks the CLR and protects apps with no code changes). It includes a test harness, performance reports and all sorts of goodness. Watch this blog for the announcement.

And now for the double whammy of good news. There will be a free public release of CAT.NET within the next few weeks. CAT.NET is our managed code review tool that plugs into Visual Studio. The initial release will be an alpha but we are working on significant updates to it over the next few months and plan to release several incremental updates. This tool contains DNA from Microsoft Research, the ACE Team and a host of great brain cells. It's very cool and the changes we are currently working on (well blogs about them in due course) just rock!

Well publish release announcement and download URL's when they are ready.

OK, back to changing diapers for me ;-)

Using Role Based Access Control in the .NET Framework - Part 2

cisg — Wed, 29 Oct 2008 11:05:00 GMT

Vineet Batta here again..

In my last blog I discussed how to use role based access control (RBAC) and described how we can restrict access to the method based on the declarative method. In today's blog I will explain how to use Imperative role based demands. The end effect is the same, but using an imperative demand we can restrict access to a portion of code on a much more granular basis. Essentially, imperative roles based access control allows you to restrict portions of the method, where as declarative demands allow you to restrict the entire method.

To implement Imperative RBAC demands, do the following four steps:

Add System.AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal) in the code.
A Try/Catch block to catch underprivileged access attempts and to report errors.
Create PrinicpalPermission object, with properties set which reflect the restrictions you want to impose.
A call to PrinicpalPermission.Demand() method.

The first two steps are exactly same as the declarative style, explained in my previous blog but the use of PrinicpalPermission class is very different here. First you create new PrincipalPermission object. There are three overloaded constructors listed below.

PrincipalPermission(Name, Role)
PrinicpalPermission(PermissionState)
PrincipalPermission(Name, Role, Authenticated)

Lets see all this in action in the example below (relate this to steps defined above);

   1: void main()

   2: {

   3: //Step 1

   4: System.AppDomain.CuurentDomain.SetPrincipalPolicy(PrinicpalPolicy.WindowsPrincipal);

5:

   6: //Step2

   7: try

   8: {

   9: MyApplication app = new MyApplication();

  10: app.UpdateUserProfile(334353);

  11: }

  12: catch(Exception error)

  13: {

  14: // Have your own robust error handling.

  15: MessageBox.Show("You do not have access to execute this method");

  16: }

  17: }

18:

  19: public class MyApplication

  20: {

  21: public MyApplication(){};

22:

  23: public void UpdateUserProfile(int empId)

  24: {

  25: //Step 3

  26: PrincipalPermission myperm = new PrincipalPermission(null,@"domain\SuperUsers");

  27: //Step 4

  28: myperm.Demand();

29:

  30: // Code to implement the feature here.

  31: MessageBox.Show("You have access");

  32: }

  33: }

Let me explain step 3 and step 4 from the above code.

Step3 - The first argument to PrincipalPermission constructor is null, which indicates that no particular name is required. The second parameter specifies the role to which the users should be part of, so that the runtime can execute the code. In this example the user should belong to "domain\SuperUsers".

Step 4 - The call to Demand() method will check for permissions as set in PrincipalPermission constructor. If the user does not have permission, the runtime will throw security exception. It's that simple to use Imperative RBAC to restrict access to code.

Another scenario..

What if you want to branch execution of code based on the user's group membership? In this case you should use System.Security.WindowsPrincipal class. The code snippet below demonstrates its use.

   1: //Create a WindowsIdentity object representing current user.

   2: WindowsIdentity currentIdentity =  WindowsIdentity.GetCurrent();

3:

   4: //Create a WindowsPrincipal object representing current user.

   5: WindowsPrincipal currentprincipal = new WindowsPrincipal(currentIdentity ;

6:

   7: if(currentPrincipal.IsInRole(@"domain\SuperUser"))

   8: {

   9: // If the user belongs to "domain\SuperUser" group then execute this code.

  10: }

  11: else

  12: {

  13: // else execute this code.

  14: }

When Would You Use the Different RBAC Techniques?

Each technique ultimately accomplishes the same goal but each should be used in different circumstances.

Condition	Preferred Technique
Restrict access to an entire method.	Declarative RBAC
Restrict access to all or portion of the code.	Imperative RBAC
Branching code based users group membership.	WindowsPrincipal.IsInRole

Back in a few days with more on securing the applications. Stay tuned.....

Using Role Based Access Control in the .NET Framework - Part 1

cisg — Tue, 28 Oct 2008 21:31:00 GMT

Hi Vineet Batta here..

Consider a scenario where you want to write an assembly which contains methods that only certain type of users can call (domain\Administrators or a specific custom users account). So how can we control this within code and let the runtime enforce these security checks?

Example scenario:

   1: public Class MyApplication

   2: {

   3: // You want that this method should only be called by users who are in domain\SuperUser account.

   4: // You want to restrict the access by runtime.

   5: public void UpdateUserProfile(int empId)

   6: {

   7: -- code to implement feature.

   8: }

   9: }

This is where Role Based Access Control (aka RBAC) can be effectively implemented. There are generally two ways to implement RBAC using either an imperative or declarative method. When we use declarative demands, we can require the user meet certain criteria before the runtime will execute the method. If the user lacks the permission, the runtime will throw the error which we can react to. Today, I will focus on declarative style and show case how easy it is achieve this and in part 2 well cover the imperative method.

First lets discuss about few classes.

System.Security.Permission.PrinicpalPermission class and the related System.Security.Permission.PrinicpalPermissionAttribute class will enable you to check active principal (aka USER account information) under which the runtime will execute the code. PrinicpalPermission can be used to demand that the identity of the active principal match this information.

PrinicpalPermission has three core properties :

Authentication : A boolean value. if this is set to true, the permission requires the user to be authenticated.
Name : The string that matches the identity of the user.
Role : The string that must match one of the principal's role.

One of the most used methods is PrinicpalPermission.Demand(). It does the heavy lifting for us and you will see it in action in a sec...

To use declarative RBAC demands, we must complete the following three steps:

Add the following code to specify principal security policy.

Example:

   1: System.AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);

2. A Try/Catch block to catch underprivileged access attempts and to report errors.

3. Annotate the method with PrinicpalPermission attribute to declare method's access requirements.

Complete Example:

1:

   2: void main()

   3: {

4:

   5: // Step 1.

   6: System.AppDomain.CurrentDomain.SetPrincipalPoilicy(PrincipalPoilicy.WindowsPrincipal);

7:

   8: //Step 2.

   9: try

  10: {

11:

  12: myApplication app = new myApplication();

13:

  14: // call the method for which RBS has be declared.

  15: app.UpdateUserProfile(1234);

16:

  17: }

  18: catch(exception error)

  19: {

  20: // Catch and display message. This is just an example. You

  21: // should implement you own robust error handling.

  22: MessageBox.Show(" You do not have access to run this function")

  23: }

24:

  25: }

26:

27:

  28: public class myApplication

  29: {

30:

  31: public myApplication();

32:

33:

  34: //Step 3.

  35: [PrincipalPermission(SecurityAction.Demand, Role = @"domain\SuperUsers")]

  36: public void updateUserProfile(int empid)

  37: {

  38: --- write code here that should only be executed by specific users.

  39: }

40:

  41: }

42:

43:

In step3 you see that that the users in the role ="domain\SuperUsers'' only can only execute this method. If any one who is not part of this group tries to execute, the runtime will throw appropriate exception. Of course we always need to fail closed!!

In the next blog I will show how the Imperative approach can be used and then compare the advantages and disadvantages of the two schemes.

ISO/IEC JTC 1/SC 27 - Working Group - Trip Report

cisg — Fri, 24 Oct 2008 16:31:10 GMT

Hi Andreas Fuchsberger here again....

Introduction

The most recent ISO/IEC JTC1/SC 27 (Subcommittee) Working Group (WG) meetings took place from 6^th – 10^th October 2008 in Limassol, Cyprus. As is set out by SC27’s charter all 5 Working Group meetings took place in parallel, allowing National Body (NB) experts to participate in more than WG during the week. The 5 Working Groups are:

· · Working Group 1: Information Security Management Systems (ISMS)

· · Working Group 2: Cryptography and Security Mechanisms

· · Working Group 3: Security Evaluation Criteria

· · Working Group 4: Security Controls and Services

· · Working Group 5: Privacy and Identity Management

As it physically not possible to attend all meetings simultaneously, this reports details results for the WG 2, 4 and 5, that were obtained either through attendance by the author or trusted reports available to the author.

Access currently to the various stages of the Working Drafts (WD) used to produce International Standards (IS) are usually restricted to active participants in the standards process. However it is usually easy to gain access by contacting your National Body of ISO/IEC JTC 1/SC 27.

Report from WG 2: Cryptography and Security Mechanisms

WG2 had a busy meeting and a large number of standards and documents were edited during the working group sessions and new versions will be available by the editors and distributed to National Bodies (NBs) for review at the next meeting (Note: NBs are not required to distribute Working Drafts (WDs), however it is common practice):

The WG 2 meeting was well attended with 41 participants in total, representing 12 National Bodies; as the Japanese NB had the strongest attendance with 17 participants.

Noteworthy is the update of Standing Document SD 12 Cryptographic algorithms and key lengths, to be used as guidance which cryptographic algorithms should be used in production systems with their appropriate recommended key lengths. Also noteworthy is the new Study Period on Secret Sharing Mechanisms prompted by the presentation to WG 5 on Privacy Enhancing Technologies by the Japanese expert, Kazue Sako.

WG 2 initiated one New Work Item on Lightweight Cryptography and the following new Study Periods:

· · Lightweight cryptographic mechanisms

· · Key establishment mechanisms for multiple entities and German NB proposal on Group key management

· · Secret sharing mechanisms

· · Parsing ambiguity attacks

Report from WG4: Security Controls and Services

WG4 had a busy meeting and number of standards and documents were edited during the working group sessions and new versions will be available by the editors and distributed to National Bodies (NBs) for review at the next meeting (Note: NBs are not required to distribute Working Drafts (WDs), however it is common practice):

The WG 4 meeting was well attended with 62 participants in total, representing 16 National Bodies, the Japanese NB had the strongest attendance with 11 participants.

WG 5 is a relatively new WG as such this was only the 6^th meeting. This is reflected through by the relevant immaturity of the documents so far, the majority being WDs, with exception of Network Security Part 1, which was inherited from WG 1 when WG 4 was created.

Of particular interest to is the progress that has been made in Application security: part 1.

WG 4 imitated 2 new Work Items:

· · Guidelines for Identification, Collection and/or Acquisition and Preservation of Digital Evidence

· · Guidelines for Security of Outsourcing

Report from WG5: Privacy and Identity Management

WG5 had a busy meeting and number of standards and documents were edited during the working group sessions and new versions will be available by the editors and distributed to National Bodies (NBs) for review at the next meeting (Note: NBs are not required to distribute Working Drafts (WDs), however it is common practice):

The WG 5 meeting was well attended with over 40 participants in total. The terms of reference of WG 5 covers both Privacy and Identity Management, and experts were present from both areas.

WG 5 is a relatively new WG as such this was only the 6^th meeting. This is reflected through by the relevant immaturity of the documents so far, the majority being WDs.

Noteworthy is the progression of 2900 Privacy Framework to CD stage. The Study Period (SP) on Access Control Mechanisms prompted by the Chinese NB contribution during the 4^th WG 5 meeting, for which the author was Rappateur was concluded with recommendation to SC 27 Plenary to start on new SC 27 wide Study Period on Access Control. The author was volunteered as Rappateur for the new Study Period and also volunteered for the WG 5 drafting committee, that met after the closing the WG meeting throughout the week.

WG 5 imitated 2 new Work Items:

· · Privacy Capability Maturity Model and

· · Requirements for Relative Anonymity with Identity Escrow

Next Meetings

The next SC 27 WG meetings were agreed as:

· 2009-05-04 - 2009-05-08 Beijing, China

· 2009-11-02 - 2009-11-06 Redmond, WA, USA

TCG Fast track

The regular WG meetings were followed by a one day meeting to agree to fast track the adoption of the Trusted Computing Group (TCG) standards.

ISO SC27 Introduction and History

cisg — Fri, 24 Oct 2008 16:29:40 GMT

Hi Andreas Fuchsberger here.....

In order to better understand a report I am about to post next on a recent ISO security meeting I thought I would include some additional information about the language used in SC 27 and how SC 27 standards are created.

SC 27 is a sub-committee of the Joint Technical Committee (JTC1) of the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). The International Organization for Standardization (Organisation internationale de normalisation) usually known as ISO is an international-standard-setting body composed of representatives from various national standards organizations. Created in 1947, the organization creates worldwide proprietary industrial and commercial standards. It is headquartered in Geneva, Switzerland. The International Electrotechnical Commission (IEC) is a not-for-profit, non-governmental international standards organization that prepares and publishes International Standards for all electrical, electronic and related technologies. Currently there exists only one joint technical committee (JTC1). JTC1 standards use the prefix ISO/IEC.

The correct abbreviation used to indicate SC 27 output is ISO/IEC JTC1/SC 27. All output produced in SC 27 is given a project number. A definitive list of current projects is published in SC 27 Standing Document (SD)

SC 27 started worked in the early 1990s originally split into three working groups: (1) Security Management, (2) Cryptographic Mechanisms and (3) Security Evaluation Criteria. Much of the attention and success was derived from the WG 1 adoption of British Standard BS7799 and transformation and publication of originally ISO/IEC 17799 Parts 1 and 2 for Information Security Management and accompanying standards. The ISO/IEC 17799 series was later renamed to become the ISO/IEC 27000 Information Security Management series. Due to its success WG 1 was split into 3 Working Groups:

· · Working Group 1: Information Security Management Systems (ISMS)

· · Working Group 4: Security Controls and Services

· · Working Group 5: Privacy and Identity Management

A definitive list of projects including all published standards and work in progress is made available through Standing Document (SD) 7 Catalogue of SC 27 Projects and Standards.

Progression of Standards

Although the editing work of creating a new standard is performed by National Body experts during the Working Group meetings, it is SC 27 that delegates the authority to start a new standard. A national body may propose a New Work Item (NWI) by providing input to a WG meeting, or WG may initiate a new Study Period on a particular topic, usually also prompted by a NB or a subject matter expert. Both NWIP and SP are circulated by the SC 27 Secretariat for distribution through National Bodies. NB then vote on starting the process for creating new International Standard.

Once an editor is found, either through a volunteer or by a call for contributions to the NBs, the process for a new International Standard, the editor produces a series of Working Drafts. NBs are not required to distribute Working Drafts (WDs), however it is common practice. NBs consult their own experts for contributions to WDs. Editors then collect the international contributions and during the editing sessions of the WG meetings either accept, reject or otherwise find a compromise to the comments made by the National Body experts. SC 27 relies usually on finding a consensus by taking the NB comments into account, rarely does it come to a vote on accepting or rejecting a comment. Depending on the NB it may be more appropriate to let the NB withdraw a comment than reject it outright. After a WD draft has gone through multiple iterations and during the editing session it is agreed that the document has reached an acceptable level of maturity the WG can request SC 27 for a delegation of authority to move the document to Committee Draft (CD) stage. CDs are distributed to the NBs for study and comment. Once the CD has reached a further level of maturity, the WG can request to move to Final CD stage. FCDs are distributed by NBs for comment and are subject to a NB postal vote. For a FCD to pass it needs a three quarters majority SC 27 P-member NBs. Thereafter SC 27 takes over the progression of the standard to Daft International Standard (DIS) and then to publication by JTC1 to International Standard (IS).

The whole process takes now on average 2 – 2.5 years. This is a significant improvement since the mid 1990s when the process has taken up to 7 years. This used to be one of the major criticisms of the ISO Standards process. This and the fact that most ISO/IEC standards are chargeable, which is in contrast to the Internet standards RFCs and other industry standards.

A Sneak Peak at the Security Runtime Engine

cisg — Fri, 24 Oct 2008 11:14:54 GMT

RV here again...

Traditionally security fixes are applied to specific pieces of code where a vulnerability exists which usually involves some development and testing effort. Imagine a system where an application is instantly secured by simple configuration. I am specifically talking about ASP.NET applications where Cross site scripting and SQL injection are some of the most common vulnerabilities found. This is exactly what the Security Runtime Engine (SRE) does, allows you to instantly turn on and protect applications which are already developed and deployed. This is very important for legacy applications which are already developed and usually don't have resources for any new development.

We have been working on a runtime engine specially for ASP.NET applications which could provide blanket protection to some of the common web application vulnerabilities. When I say blanket protection I mean single point of deployment and protection for the entire application. Thus we designed the SRE as an HTTP module which works at the IIS/ASP.NET layer providing protection against certain attacks. This is different from a web application firewall, it hooks the CLR and so doesn't operate on network protocol stream as it passes the network. As such it's tightly coupled to the application; an important and significant difference. Currently it provides protection against Cross Site Scripting by automatically encoding the controls.

It does this by walking the controls in the requested page and automatically encoding data in specific properties for example Label.Text. It can be customized to walk and encode (override) only specific controls such as Label, HyperLink, CheckBox etc. and additionally the type of encoding used can also specified for each individual property of a control. This customization enabled using a configuration file in the web root. SRE leverages the upcoming Anti-XSS library to ensure ultimate XSS protection.

Apart from simple encoding, SRE also contains some advanced features for better usability and adoption. Notably the following 3 features standout;

Double Encoding Protection
Encode Derived Controls
Suppressions

The double encoding protection feature ensures that there is no double encoding possibility. Double encoding problem occurs if you encode data twice. SRE would make sure that it's encoding does not double encode the data. The encoding derived controls feature allows the derived controls to be automatically encoded if the base controls are already configured, for example if you create your own label control using the System.Web.UI.WebControls.Label then you control will automatically be secured without any additional configuration. The suppressions feature allows you to suppress encoding for specific pages or controls. If you want to encode programmatically or your page does not use any input, you could suppress encoding in that page. Ultimate flexibility! This can be done by adding the specific page path to the configuration file. Note that SRE encoding performance is similar to Anti-XSS library. We have had the ACE Performance testing team do an analysis and it runs at near native speed. We will be shipping both tools wit a performance test and a test harness. So enabling SRE is similar to implementing AntiXSS library but with added bonus of not having to implement any code changes and yet get protection across the entire application. You can think of it as the ability to have secure encoding out of the box. Of course this will break many existing applications which is one reason why the .NET framework couldn't implement this by default.

SRE also includes a configuration utility which reflects on the compiled ASP.NET application binary and creates a custom configuration file based on the controls in the binary. The configuration utility includes a master file which contains the list of all the controls, their properties and encoding type needed. This custom configuration file is very useful in making sure the proper configuration is applied to the web application.

In future SRE could be able to provide protection against certain other classes of web application attacks (in fact we already have work happening on that). SRE is code complete and in the final stages of testing. We will have an internal beta soon and a public one within the next few months.

Check our blog for the beta announcement!

Thanks

Anil RV

Introducing SecurityNow

cisg — Fri, 17 Oct 2008 13:52:22 GMT

Mark Curphey here.....

A few months back I challenged some of my team to build a "Proof of Concept" (POC) that would;

demonstrate how we could apply some of the ideas and concept we had been talking about such as BPM and BI
show how Microsoft's technology stack can be applied to the security management space

With just a few weeks of work (we really do have an incredibly talented team) we produced "SecurityNow". The POC took it's name from the excellent connected systems demo called DinnerNow. We wanted to take a specific scenario and in this case chose to look at line of business application security assessments in a corporate environment. We could have easily chosen incident management, risk assessment, network vulnerability management etc. but the information security team here has the ACE Team who are responsible for security assessment of our Line of Business (LOB) applications and it was what Tom Cruise would call a "target rich" scenario. The scenario we chose was actually made up of a set of smaller scenarios and in my experience is typical of how many corporations would like to do their line of business application security assessments.

Scenario 1 - The systems owner schedules an assessment

Scenario 2- We automated the execution of security assessment tools

Scenario 3 - The system hands off to a trained analysts to do the manual assessment

Scenario 4 - Automated the tracking of the assessment status

The POC specifically looked at applying Windows Workflow Foundation (WWF) and PerformancePoint server (we have some stuff in the brew looking at WPF, Oslo and WCF now so watch the blog in the future).

The engineers will be blogging about the specifics in detail in the coming weeks so I will just provide a high-level overview by way of introduction with some teaser screen shots.

When you first go the POC you get the coverage below to navigate to the various scenarios.

It's worth jumping straight to the business process designer. Behind the POC is a state machine workflow (what's shown below is actually one of the states) which then executes on the business process engine and is monitoring by business activity monitoring (or BAM). We re-hosted the .NET workflow designer and built a state machine and set of activities to automatically pull code from Team Foundation Server, compile it (check) and run our manage code review tool CAT.NET (you'll be hearing lots more about that on the blog in the coming weeks).

We believe visual modelling and simulation of security processes will be huge. You can literally drag and drop activities onto the design surface and build an application in minutes. I posted about the Tenets of BPM for Security on my personal blog a while back.

We built a simple UI (not shown here) that allows the user to come along and schedule an assessment by providing the location of the code in his / her Team Foundation Server. We capture his / her project details from the GAL (Active Directory) and capture some additional project related information. It takes less than 60 seconds to request and schedule an assessment!! When submitted we automatically pull the code from the project teams team Foundation Server, compile it and run our automated tools over it. We then (and this is where it gets good) automatically enter any defects back to the team as TFS work items. If they have any Sev 1 bugs we put the work flow on hold until they have closed off those bugs. When they interact with the workflow we of course verify that they have indeed closed them out before handing off the assessment to the analyst who picks up his review of the things automated tools can't (or do a bad job of) finding. The screen shot below is a status report which basically queries the workflow in operation. You can see this particular case is on hold as there were Sev1 bugs found (this is all dummy data of course).

The analyst or the system owner can query the status of the process and any results in real time. Below is the current status of the security defects that were found. The reports below are build using PerformancePoint, our Business Intelligence suite. Our development team in India has vast experience in building huge high performance data warehouses and you should expect to hear a lot from us about data warehouses for security in the coming months.

I'll leave it there for now. It was just an introduction. The engineers will follow-up with a series of posts about the nuts and bolts and I expect to follow-up in a few weeks with some news and more details about our plans for security management tools.

Secure Strings in .NET - Part I

cisg — Wed, 08 Oct 2008 18:25:10 GMT

Hi Gaurav Sharma here.......

I am a developer on the CISG India team based in Hyderabad and I joined Microsoft four months ago. I love playing computer games and recently finished Call of duty 4. For the last three years I've been working with .NET and have worked on different kinds of applications that include ERP solutions, utilities and web portals. Apart from computer games I like watching soccer; there was a time (long back) when I used to watch each and every match of English premier league. I've a blog that I last updated when I joined MS. This looks like enough information about me, let us start with our secure string story.

A few months back I was looking into improvements that Microsoft made to it's .NET base class library since its inception and I stumbled upon a class named Secure String. I found that exiting and made a small blog entry related to this new class.

In this write up I'll try to focus on the need for secure string class as well as its internal working and usage. I'll also try to do a feature comparison between String and SecureString class. You will find code examples and IL code with theoretical explanations. There are a few tools that I will use for creating code and IL samples. These are:

Visual Studio 2008
I'll use Visual studio for creating code samples. If you do not have Visual studio installed on your system you can download and install the free express version of our beloved IDE.
.NET class viewer
I will use .NET Reflector but you can use any tool of your choice.
ILDASM.EXE
Another great tool and will be used to look at IL code, manifest information and assembly metadata
Memory Profiler
I'll try to use this tool to show how object creation of string class differs from secure string

The structure of this two part write up (this is part one) is as follows;

Part I
- Introduction
- SecureString Class
- Members
- Usage
Part 2
- Internals
- SecureString vs. String class
  - Performance
  - Usability
- Misc.

Let's start our journey to explore SecureString,

INTRODUCTION

Since the inception of .NET programming, I doubt whether there is any other class used more frequently than the String class. We can use string to represent any textual and literal data like name, location, occupation etc. There are four ways in which we can represent individual character and their collections:

System.Char
System.String
System.Text.StringBuilder, and
System.Security.SecureString

System.String is an ordered set of characters that is immutable. String is a reference type so every string object that we create lives on the heap rather than on the thread stack. Because strings are immutable, once they are created we can not change them. We can not add or remove or manipulate existing string objects. Whenever we try to manipulate string objects we discard old objects (they are still there on heap) and create new ones. Let's see a code snippet,

   1:  using System;

2:

   3:  namespace Gaurav.Samples.SecureString

   4:  {

   5:      class Program

   6:      {

   7:          static void Main(string[] args)

   8:          {

   9:              string name = "Gaurav";

  10:              name = name + "Sharma";

  11:              name = name + "Mr.";

  12:              Console.WriteLine(name);

  13:              Console.Read();

  14:          }

  15:      }

  16:  }

This will create three string objects. When we add "Sharma" to the already existing string name, a new string object is created and the name variable now refers to this new object. The old string object is marked for garbage collection. Same thing happens again when we try to append "Mr." to name. A new object is created and we have two old objects marked for garbage collection. The next garbage collection run will clear out these two objects.

Now suppose you have a application that stores username, password and credit card number in string objects. These string objects are basically in memory character arrays and if there is any unsafe or unmanaged code is allowed to execute, that code can snoop around the process's address space, locate the string with sensitive data and can use this data in a bad way.

Strings are not pinned objects. Pinned objects are those whose memory can not be compacted by garbage collection. As strings are not pinned objects, our garbage collector is free to move strings in memory. When string objects are moved several garbage copies of string data are created whose memory will be reclaimed by the garbage collector during later runs. Having so many copies of data (especially if sensitive) can create issues.

String keeps a plain text copy i.e. not encrypted, so our data is under continuous danger of being read by some one who can read our process's memory. If our string object is used for a small time span and then garbage collected, it's possible that the common language runtime (CLR) will not reuse the object's memory immediately (this depends on the generation of the object). This can be a potentially compromising situation with our strings data left in memory. Moreover as strings are immutable you can not overwrite them with blank data, the code below for example will not clear out any data.

   1:  using System;

2:

   3:  namespace Gaurav.Samples.SecureString

   4:  {

   5:      class Program

   6:      {

   7:          static void Main(string[] args)

   8:          {

   9:              string name = "Gaurav";

  10:              //this will create new object and will not clear out old object's data

  11:              name = "";

  12:              Console.WriteLine(name);

  13:              Console.Read();

  14:          }

  15:      }

  16:  }

If at any time you run out of memory, string memory contents can get into SWAP files, where they can be a lot easier to access by the bad guys (hackers). Due to these issues Microsoft introduced added another secure string class in FCL,

Class Name: SecureString
Namespace: System.Security
Assembly: mscorlib.dll

SECURE STRING CLASS

Some facts about secure string class are:

When a new object of secure string class is constructed, the CLR allocates a block of "unmanaged" memory that contains an array of characters. The garbage collector is not aware of this memory block because this is unmanaged.
Data is encrypted using Data Protection API or DPAPI.
Methods available in Secure String class like AppendChar, InsertAt...first decrypts the data then performs the action and then again re-encrypts the data.
This class implements the IDisposable interface which means that you can clean out your object deterministically. Dispose method zeroes out the content of the memory buffer.
This class is also derived from CriticalFinalizerObject. This guarantees that object's finalizer method is called , which means characters will be zeroed out and memory will be freed.
Unlike string, objects are mutable. This means that if we pass this object to different functions, only one copy of object will be there.
This is non CLS compliant (use of pointers).
This is a sealed class (like all data types).

MEMBERS

MSDN provides a good information about members of the SecureString class. http://msdn.microsoft.com/en-us/library/system.security.securestring_members.aspx page will give you enough information that will equip you for SecureString usage. For your convenience I'll add member summary here, but for latest information you should always check MSDN.

USAGE

There are not many examples that uses SecureString class so I'll try to show you where this class is used in the framework class library by developing a small application that uses secure string. To avoid complications our sample application will be a small (micro) console application that stores passwords in secure string and renders it to console. Let's start with knowing about FCL usage of SecureString class,

Framework Class Library usage
- System.Diagnostics
  - System.Diagnostics.Eventing.Reader.EventLogSession..ctor(String, String, String, SecureString, SessionAuthentication) [.ctor=constructor in IL]
  - System.Diagnostics.Process.Start(String, String, SecureString, String) : Process
  - System.Diagnostics.Process.Start(String, String, String, SecureString, String) : Process
  - System.Diagnostics.ProcessStartInfo.Password : SecureString
- System.Runtime.InteropServices
  - System.Runtime.InteropServices.Marshal.SecureStringToBSTR(SecureString) : IntPtr
  - System.Runtime.InteropServices.Marshal.SecureStringToCoTaskMemAnsi(SecureString) : IntPtr
  - System.Runtime.InteropServices.Marshal.SecureStringToCoTaskMemUnicode(SecureString) : IntPtr
  - System.Runtime.InteropServices.Marshal.SecureStringToGlobalAllocAnsi(SecureString) : IntPtr
  - System.Runtime.InteropServices.Marshal.SecureStringToGlobalAllocUnicode(SecureString) : IntPtr
- System.Security.Cryptography
  - System.Security.Cryptography.CspParameters..ctor(Int32, String, String, CryptoKeySecurity, SecureString) [CSP = Crypto Service Providers]
  - System.Security.Cryptography.CspParameters.KeyPassword : SecureString
  - System.Security.Cryptography.X509Certificates.X509Certificate..ctor(Byte[], SecureString)
  - System.Security.Cryptography.X509Certificates.X509Certificate..ctor(Byte[], SecureString, X509KeyStorageFlags)
  - System.Security.Cryptography.X509Certificates.X509Certificate..ctor(String, SecureString)
  - System.Security.Cryptography.X509Certificates.X509Certificate..ctor(String, SecureString, X509KeyStorageFlags)
  - System.Security.Cryptography.X509Certificates.X509Certificate.Export(X509ContentType, SecureString) : Byte[]
  - System.Security.Cryptography.X509Certificates.X509Certificate.Import(Byte[], SecureString, X509KeyStorageFlags) : Void
  - System.Security.Cryptography.X509Certificates.X509Certificate.Import(String, SecureString, X509KeyStorageFlags) : Void
  - System.Security.Cryptography.X509Certificates.X509Certificate2..ctor(Byte[], SecureString)
  - System.Security.Cryptography.X509Certificates.X509Certificate2..ctor(Byte[], SecureString, X509KeyStorageFlags)
  - System.Security.Cryptography.X509Certificates.X509Certificate2..ctor(String, SecureString)
  - System.Security.Cryptography.X509Certificates.X509Certificate2..ctor(String, SecureString, X509KeyStorageFlags)
  - System.Security.Cryptography.X509Certificates.X509Certificate2.Import(Byte[], SecureString, X509KeyStorageFlags) : Void
  - System.Security.Cryptography.X509Certificates.X509Certificate2.Import(String, SecureString, X509KeyStorageFlags) : Void
- System.Windows.Controls
  - System.Windows.Controls.PasswordBox.SecurePassword : SecureString
  - System.Windows.Controls.PasswordBox.SetSecurePassword(SecureString) : Void
  - System.Windows.Controls.PasswordTextContainer..ctor(PasswordBox)
  - System.Windows.Controls.PasswordTextContainer.SetPassword(SecureString) : Void

Below I've added what's probably the most exhaustive list of SecureString usage you will ever find on web. Some of these uses secure string internally and some of them are not public. You will find a list of places where SecureString is used, places where SecureString objects are exposed, where SecureString objects are initialised and assemblies on which SecureString depends.

Now let's move to our sample application.

Sample application

Create a C# console application. You can name it as you like. Our application is very simple. It takes a password string from user and renders it back to the console.
Our sample application will have two methods, one Main [entry point] and other to render secure string on standard output stream [console in our case]
Make sure you check unsafe usage from project build properties window. This will add '/unsafe' switch during compilation. '/unsafe' compilation switch is required to compile any unsafe code. Important thing is that we don't need '/unsafe' switch to create secure string objects, this check is required to access secure string's unmanaged memory location using pointers. If you use CSC.EXE [C # compiler] from console you can use '/unsafe' switch to compile unsafe code.

Our class looks like this

   1:  using System;

   2:  using System.Security; //required for SecureString

   3:  using System.Runtime.InteropServices; //required for SecureString

4:

   5:  namespace Gaurav.SecureStringSamples.ConsoleLoginSample

   6:  {

   7:      class Program

   8:      {

   9:          static void Main(string[] args)

  10:          {

  11:              using (SecureString password = new SecureString())

  12:              {

  13:                  ConsoleKeyInfo consoleKeyInfo; //used to read console keys

  14:                  Console.Write("Please enter password: ");

  15:                  while (true)

  16:                  {

  17:                      consoleKeyInfo = Console.ReadKey(true);

  18:                      if (consoleKeyInfo.Key == ConsoleKey.Enter) break;

  19:                      password.AppendChar(consoleKeyInfo.KeyChar);

  20:                      Console.WriteLine("*");

  21:                  }

  22:                  Console.WriteLine();

  23:                  RenderSecureString(password);

  24:                  Console.Read();

  25:              }

  26:              Console.WriteLine("done");

  27:              Console.Read();

  28:          }

  29:          private unsafe static void RenderSecureString(SecureString toBeDisplayedSecureStr)

  30:          {

  31:              Char* charPtr = null;

  32:              try

  33:              {

  34:                  //cast int ptr to char ptr

  35:                  //copy content from secure string to block of unmanaged memory

  36:                  charPtr = (Char*)Marshal.SecureStringToCoTaskMemUnicode(toBeDisplayedSecureStr);

  37:                  for (Int32 count = 0; count < toBeDisplayedSecureStr.Length; count++) Console.Write(charPtr[count]);

  38:              }

  39:              finally

  40:              {

  41:                  //frees unmanaged string pointer allocated by Marshal.SecureStringToCoTaskMemUnicode

  42:                  if (charPtr != null) Marshal.ZeroFreeCoTaskMemUnicode((IntPtr)charPtr);

  43:              }

  44:          }

  45:      }

  46:  }

Output window will look something like this

Cool, we have now created our very first secure string example. Next time I'll add some performance tests to this example and compare them with the standard string class.

Stay tuned!