This new beta includes a lot of changes and makes Peach feature complete for the 2.1 release coming in the next month or so.  Many of the changes were internal clean ups.  The internal DOM is now much cleaner and easier to use, as is the API to the engine and parser.  Additionally, this release include a new GUI application called Peach Validation.  This application allows testing of your data model and also mutators.  A screen shot has been included.

Additional features include Hints, Fixups, new “calc” length types, ability to specify a file to Data elements, etc.  To much to talk about in this post.  However, keep an eye on this blog for additional articles over the next few days exploring the new features of Peach 2.1 BETA3.

Peach

Peach Release Notes

Peach Downloads

The Microsoft .NET Framework provides the developer with a number of advanced features such as P/Invoke and unsafe code blocks.  This article will take a look at unsafe code blocks and some of the security issues that should be looked for when reviewing or writing such code.

First off, what is the unsafe keyword and how can it be used?  Glad you asked, unsafe allows for the use of pointers in .NET code.  This includes pointers to managed objects such as arrays and strings.  To use the unsafe keyword the assembly or executable must be compiled with a special flag allowing for unsafe code blocks.  The resulting assembly/executable will not be verifiable by the CLR.

Modification of Immutable Types

With power comes the temptation to modify immutable types such as strings.  Resist this urge as the CLR does a number of internal optimizations for known immutable types like strings.  Modification of these immutable types can and will cause instability in the CLR, and have interesting ramifications.  For example, some versions of the CLR keep only a single copy of strings.  So if I created three strings, all with the value "Hello World", I would really only have three references to the same string.  This is okay since the string object is immutable.  However, if I take a pointer to the string and change its contents I will end up changing the contents of all three strings!!

Managed Pointers and Pinning

The .NET memory manager can move values and object instances around in memory as needed.  So, if we are going to get a pointer to such a memory region we need to tell the memory manager not to move that memory on us.  Enter object pinning.  Pinning tells the CLR not to move something until it is unpinned.  A typical bug in unsafe code is when a managed pointer is held on to and used after it’s reference has been unpinned.  This is a hard bug to detect as the program may run fine most of time and the crashes that occur may not be obviously linked to the unsafe code.

In the C# managed language, pinning typically occurs using the "fixed" block.  This makes it easier to spot issues.  I recommend avoiding other methods of pinning variables as they can be harder to review.

The managed extensions to C++ also provide what feels like "lower level" control over variable pinning.  This is typically harder to review, but then if you are writing in MC++ you should already know what your about :)

Buffer Overflows and other Pointer Issues

With the unsafe keyword and pointer math come all the standard security issues those C/C++ developers need to worry about.  There is a real possibility of causing buffer overflows that result in exploitable conditions in .NET applications.  Buffer manipulation should be reviewed just like C/C++ for possible overflows.

And so ends part 1 of this article.  Please feel free to comment on this post with questions and comments.

I’m currently running around Europe dropping in on a few security conferences.  Wednesday and Thursday have me in Ghent, Belgium at the OWASP AppSec 08 conference.  I’ll be jumping onstage Thursday morning to talk about two of my OWASP projects (see below).

First time in Belgium, and I must say the Cherry Lambic is nice and it feels like a slower pace then the Netherlands with similar architecture.

OWASP AppSec 08 Belgium

OWASP Encoding Project (Reform)

OWASP .NET WebService Validation

Encoding output to prevent cross site scripting (XSS) is old news to most in the web security community, but it’s still an area that is done incorrectly, or with out thought to future issues that might arise.  Additionally, with the explosion of AJAX based applications there is a lack of encoding tools that target JavaScript or provide an implementation for JavaScript.

Standard framework utilities for encoding output (Server.HtmlEncode, etc) only encode the most basic set of characters needed, &, <, >, and ".  In a perfect world this would be enough, but in the day and age of browser bugs, broken Unicode libraries, and lenient HTML interpretation that can lead to occasional sloppy coding more is needed to protect our applications.  Enter the Reform encoding library.

Of specific mention is correct context aware output encoding.  The context could be "html body", "html attribute", "css", "javascript", etc.  It’s important to understand how your data will get treated to know how it needs to be encoded.  It’s because of context issues that one must encode on output of data instead of input.  Unfortunately there are no shortcuts :)

The Refrom encoding library, also known as the OWASP Encoding Project, provides conservative functions for performing different types of encoding’s that are needed in today’s web applications in a large variety of languages.  Currently there is support for: Java, C, Python, Perl, PHP, Ruby, JavaScript, ASP.NET, and Classic ASP.  All of the Reform functions are internationalization safe, are easy to use, and prevent all known types of XSS issues when used correctly.

What is encoded?

• Everything but: A-Z, a-z, 0-9, space [ ], comma [,], and period [.]
• Unicode is always encoded

The following functions are provided:

• HtmlEncode — Encode data for display in a block of HTML or HTML attribute.
• JsEncode — Encode data into a JavaScript literal
• VbsEncode — Encode data into a VBScript string literal

Microsoft’s AntiXss Library

An alternative to Reform is the Microsoft AntiXss Library.  Both libraries are functionally equivalent and in fact were designed by the same people.

Reform can be downloaded from here.

Since the early days of ASP.NET there has been a heavy reliance on the request validation performed to mitigate cross-site scripting issues as many of the WebControls do not perform any encoding.  In ASP.NET v1.1 the request validation performed was fairly restrictive.  It looked for tags, expressions, on strings (onClick, etc), javascript:, and "&#".  After reviewing an ASP.NET 2.0 site I found these protections have been simplified to just look for tags and "&#".

This has a number of interesting security impacts as any 1.1 site which relies on these protections as mitigation’s to security issues will find themselves vulnerable once they upgrade.  It would be interesting to know Microsoft’s reasons for removing these checks.  I would assume it caused to many customer issues, perhaps interfered with AJAX in some way.

To recap, asp.net v1.1 performed the following checks:

1. Look for "&#"
2. Look for ‘<’ then alphas or ! or / (tags)
3. Look for "script:"
4. Look for on handlers (onXXX=)
5. Look for “expression(“
6. Skip elements named "__VIEWSTATE"

While asp.net v2.0 and higher performs the following:

1. Look for &#
2. Look for ‘<’ then alphas or ! or / (tags)
3. Skip elements with names prefixed with double underscore (__)

As you can see the 2.0 version is much weaker than 1.1.

Enjoy!

Today I was breaking a web app that build up some JS using querystring values that had been run through HttpUtility.UrlEncode.  Since I was not 100% sure what leverage that got me I decided to dig deep and look through the disassembly of the function.  Turns out you get a allot of characters to play with including….single quote (’)!! Yay for me :)

Characters not encoded by UrlEncode:

‘
(
)
*
-
.
_
!