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.

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:

‘
(
)
*
-
.
_
!

When performing a standard p/invoke method call in which a .NET string must be converted to an unmanaged LPSTR (char*), the .NET runtime performs a "bestfit" conversion.  This means some Unicode characters will be converted down to ASCII characters based on some mapping information.  This "bestfit" conversion can allow an attacker to bypass input validation filters.  For example, a filename might be checked to make sure it does not contain a backslash ("\") character, or two periods ("..").  By using Unicode characters an attacker could by pass those checks by providing a Unicode character that will be converted to the required ASCII character during the marshaling of the string.

Full article with character map.

Found myself reviewing some WMI stuff and needing to set values and see properties and all that good stuff.  WMI Explorer got me partway there, but I still needed to set values.  Sooo… 15min later there is a small .net tool for this.  Enjoy.

WMI Tool

Found myself writing a simple brute forcer yesterday for windows integrated web authentication (NTLM and Kerberose) that worked over SSL.  An easy task with .NET, but was surprised when asked for a tool to do this.  Seems most of the tools out there don’t have SSL integrated (easy to fix), poor domain support, and limited Kerberos support.  Anyway’s, since others may find this simple tool of some value I figured I’d post it up on ye old blog.

Source or Installer