[Pnet-developers] Security auditing and 0.6.0

[Rhys Weatherley]

Following up on my previous e-mail on version 0.6.0, another area that people 
can help with is security auditing.  This is a multi-faceted problem, but 
easy for people to help with if they have reasonable code reading skills.

The engine currently has two operating modes: "load from local disk" and "load 
from untrusted source".  The former mode should be able to do anything that 
the system is capable of, including pointer operations, unmanaged 
instructions, file access, etc.  The latter mode, for applet-style "download 
and run", should only be able to perform "verifiable" IL instructions, and is 
limited in what it can access within the environment.

At present, everything runs in the former mode, but we need to tighten this up 
as time goes on, especially for DGEE.

To help you out, here are some things to look out for:

1. Range checking of all buffers, ILString's, etc.

This is vitally important, as buffer overruns are the most common security 
flaw that crackers exploit.  Hunt through "lib_string.c" and "lib_array.c" in 
particular.

2. Internalcalls.

Every internalcall is potentionally a security risk because it is exiting the 
managed context to perform raw C operations.  Two forms of compromise are 
possible: heap corruption due to invalid pointers or parameters, and 
environmental compromise (e.g. being able to open a file in a mode that 
should disallow it).  You may want to add some functions like 
"_ILFileAccessAllowed", "_ILSocketAccessAllowed", etc, as place-holders for 
enforcing environmental security.

3. Verification rules that don't match the ECMA spec requirements.

See the IL instruction set specifications for descriptions of the verification 
conditions.  And also the metadata specificiations for constraints on 
classes, methods, fields, etc.  Ideally, it would be nice to have a test case 
for every rule in Partitions II and III of ECMA 335.

4. Race conditions with respect to threads.

Race conditions can be especially prevalent with internalcalls.  e.g. a C# 
class might be wrapping up an internal data structure, accessed through 
internalcalls.

"System.IO.FileStream" currently has a few of these.  If one thread calls 
"Close" while at the same time another thread calls "Read", then it is 
possible that the "Read" thread may get the handle just before the "Close" 
and then try to read just after the close.  Memory corruption, security 
violations, or worse, may result.

The solution for race conditions is usually to wrap up all internalcall 
invocations with a "lock" statement (using the same object in every lock of 
course), and to make sure that fields like "handle" are properly cleared 
before the lock is released during "Close".

It is possible for such "do something after closing" race conditions to happen 
in pure C# code also, but they are less of a security risk as long as the 
code doesn't use any internalcalls.  Still fix them if you find them though.

5. Reflection.

In general, methods within "mscorlib.dll" can do anything they like, including 
accessing private members of other classes.  But this behaviour must not 
escape to other assemblies or the user's application.  "_ILClrCheckAccess" 
can be used to determine if a program item can be accessed from the caller.

Happy hunting!

Cheers,

Rhys.