Hijacking .NET

Matt Solnit writes "What can I say - Dan Appleman never fails to please. In this e-book, he takes a look at 'hijacking' .NET by accessing private members in .NET classes. Private members are, in essence, pieces of code that you don't want other programmers to access. You use them to support your own code, and you make public the pieces that you want to make available to other developers. Typically, a language ensures that a member marked as private is hidden from anyone who doesn't have your source code, but Appleman shows how in .NET it's not so." Read on for more of Matt's review of this guide to tricking private members to do your bidding. Hijacking .NET - Volume 1 author Dan Appleman pages 46 publisher Dan Appleman rating 10 reviewer Matt Solnit ISBN (N/A) summary An eye-opening look at how you can use undocumented and private features from the .NET framework.

In the .NET Framework, it's possible to access a private member of any class -- your own, another developer's, or even the classes in the .NET Framework itself! Appleman demonstrates this with a great example that uses private members to get the list of groups that the current user is a member of -- in a single line of code -- by accessing a private member that is not exposed by the .NET Framework.

Appleman also explains the tradeoffs of using this technique. The code you're using is not documented, and it's not guaranteed to be present in future versions. He describes how to deal with these problems, and how to make the most of the technique while remaining relatively safe.

Once the basic technique is explained, Appleman takes you into how to find out what private members are available, and how to call them. He shows how to use the object browser available in Visual Studio .NET and the Microsoft IL Disassembler, freely available in the Framework SDK, to discover the private members in a class and determine how to call them correctly.

The example is great -- Dan shows you how he used "hijacking" with a collection of private members to develop a FileAccessControlList class that can be used to manipulate ACL's on Windows files. This is a piece of functionality that is not included with the .NET Framework, but developers have a need for all the time. To write the code from scratch would take days, including translating Windows API declarations to C# or another .NET language and poring over MSDN documentation. As it turns out, all the pieces are in the Framework -- they're just not public. Appleman accomplishes the task in under 200 lines of code, all of which is included with the e-book. As a bonus, you get a great introduction to how Windows security works, and how the example could be extended to other ACL-controlled things like Registry keys.

The fact that private in .NET isn't really private is something that isn't well known, and even if you're not interested in security, this e-book is worth a read just to get some insight into what you can do with the .NET framework, and what other people might someday try to do to your code.

As far as the author's writing style, I will say that Dan has a great knack for intuiting what needs to be explained and what doesn't. His laid-back approach makes everything seem fun -- this is a book you could read on a Saturday afternoon in a hammock.

This e-book is not for beginning .NET programmers, but should be easy for intermediate developers to understand. The whole text weighs in at just under 50 pages, and is well worth the cost of $9.95. Sample code is provided in both C# and VB .NET.

This e-book can be purchased and downloaded immediately from amazon.com or through the author's web site.

Comments

C++

[Anonymous Coward]

This is nothing new - you can do the same thing in C++. It's easy to access private variables or functions by manipulating a pointer.

So what's the big deal?

Duh. Its called reflection

[Asmodeus]

..and is a very old technique.
Java, Modula2, Lisp and smalltalk all allow
this.
RTFM

Re:Duh. Its called reflection

[egomaniac]

I love it when a flat-out wrong post gets modded to 5. You most fucking certainly can access private methods and fields from within Java.

For instance, to set the private field "x" on a Component:

import java.awt.*;
import java.lang.reflect.*;

public class YouAreWrong {
public static void main(String[] arg) throws Exception {
Button youAreWrong = new Button();
System.out.println("Button.getX() == " + youAreWrong.getX()); // youAreWrong.x = 5; would result in a compile error, as x is a private field
Field x = Component.class.getDeclaredField("x");
x.setAccessible(true);
x.set(youAreWrong, new Integer(5));
System.out.println("Button.getX() == " + youAreWrong.getX());
}
}

Go try it and see what happens.

How it's done

[Jabes]

This will be done using reflection. It's pretty easy to instantiate private objects, and call private members using the reflection functions in .net (System.Reflection) I'll post an example if anyone is that interested, but there are quite a few examples kicking around on the net.

However, the security model of .net only allows you to make these reflection calls if your application is running in "full trust". There is a very finely grained security model in .net, and applications can be trusted to make certain calls depending on the location they're running from (eg over the internet from an http:// address, on a network share, on the local disk); on whether the application is signed; by the vendor of the application; or even down to just a single program.

At the moment .net programmers mostly assume they're running in full trust mode (which if its on the local hard disk, they are). But this is a poor assumption which will fall by the wayside in the future as .net takes off.

To do other "unsafe" things (like use pointers, or interop into unmanaged code, generate dynamic code) you also need high permission levels.

Now let's compare this with the unmanaged world. I can load up a DLL and call what the hell I want. I can even jump right into the middle of a function if I want. I can over-run buffers and blow my stack. I can do what the hell I want within my virtual address space. I can send messages to other applications and make them do screwy things. And I'm probably running as a local administrator so I can do things to other processes too.

So is this a security concern? I don't think so.

I must admit, I haven't read the book - and I'm not going to shell out $10 to find out if I'm right.

Re:Is this a C# or a .NET problem?

[Anonymous Coward]

This is no security hole. If you're able to run code on the target machine then you can do pretty much anything you want (or can) already.

Just because you can find out some "inner state" of an object doesn't mean that you're God now.

Oh, and the same "exploit" can be done with C++ - does this have a negative affect on security? No.

Encapsulation was never meant to be a security feature.

Security

[cooldev]

Private members aren't for hiding code or data from other malicious programs; if they're being used in that way that's a flaw.

It's simply a compile-time verification that you're using the object through it's intended public interface instead of relying on the internal implementation. If you disregard it you just end up throwing away a lot of the benefits of OO and you build fragile apps.

That said, people should be aware of this so they don't mistakenly think that "private string m_password" is a secure way to store data.

BTW: A long time ago I did this in Java by programmatically altering the bytecode of a .class file from another app.

Re:So .Net is like C++?

[Erv Walter]

This .NET behavior is not a security hole.

The .NET CLR does runtime checks to verify that code is not doing things it's not allowed to do (aka, code can't leave the "sandbox"). Accessing private methods using this technique does not circumvent these checks--the CLR will detect and prevent *inappropriate* accesses.

The key point is that .NET applications can be running in many different security environments. Installed applications running off your hard drive essentially have no sandbox. Applications running from the network or within a browser have a much more restrictive sandbox and these "hacking .NET" techniques would be caught (assuming the private code being called is inapproriate for the sandbox).

Re:Is this a C# or a .NET problem?

[Erv Walter]

Keep in mind that there is not always a sandbox for .NET applications. The security policys being enforced are configurable, but by default, installed applications running off your hard drive essentially have no sandbox. On the other hand, applications running from the network or within a browser have a much more restrictive sandbox and these "hacking .NET" techniques would be caught (assuming the private code being called is inapproriate for the sandbox).

The .NET CLR does runtime checks to verify that code is not doing things it's not allowed to do (aka, code can't leave the "sandbox"). Accessing private methods using this technique does not circumvent these checks--the CLR will detect and prevent *inappropriate* accesses.

Re:Is this a C# or a .NET problem?

[1000StonedMonkeys]

Not quite true. .NET has a fine-grained security mechanism that allows code to execute with specific priviledges. It can do that because .NET, like Java, is run by a VM. What the original poster is getting at is that you might be able to bypass these access controls if you're able to access the private data members of .NET system classes.

C++ will let you do anything!

[BaldBass]

"In C++ the compiler will not let you access private methods or variables."

No and no. Example:

producer.h:

class ThoughtToBeSecure {
private:
void highlyGuardedMethod();
int highlyGuardedVariable;
};

hacked_producer.h:

class ThoughtToBeSecure {
public:
inline void protectionBypass() {
highlyGuardedMethod();
}
inline void hackTheVariableToo(int value) {
highlyGuardedVariable= value;
}

private:
void highlyGuardedMethod();
int highlyGuardedVariable;
};

malicous_user.cpp:

#include "hacked_producer.h"

void sandboxHaHa(ThoughtToBeSecure x) {
x.protectionBypass();
x.hackTheVariableToo(0);
}

Looks like you need to brush up your C++ knowlege.