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.

Is this a C# or a .NET problem?

[Dominic_Mazzoni]

Is this a limitation of C# or of .NET?

What does this mean for the security of .NET programs? I thought it was supposed to be possible to run .NET programs in a sandbox, protecting you from malicious code. It seems that being able to access private members in the .NET framework opens up a whole new world of possibilities for security holes...

So .Net is like C++?

[Ed Avis]

In Java, the bytecode interpreter makes sure you can't access private class members. This is needed for security - creating the 'sandbox' which is most well-known from applets, and IMHO isn't used enough elsewhere.

OTOH in C++ the public/protected/private distinction is enforced solely by the compiler, and code has full access to the machine.

Obviously in .NET you don't have the same raw hardware access, but it looks like for speed Microsoft omitted to check access qualifiers at run time. But I wonder, is this part of the .NET specifications, or is it just an implementation oversight? Does the same trick work on Mono for example?

Dan 'Obvious' Appleman

[playtime222]

Anyone who's looking into reflection at any depth knows that private members can be found and used without too much trouble. The only thing he's done here is actively tried to use the private functions of code he didn't right. What a genuis :-/

Private methods and

[yatest5]

members are set as such not as some security method but to protect users of a class from using them. The fact this can be *programmed around* is irrelevant.

Standard users, using standard techniques are only allowed to use public members and this is correct.

I think you'll find that if you're willing to write your own compiler, you can access provate methods in any language you care to name.

As such, this artile is irrelevant, an really just another pathetic excuse for a load of whingers to make cheap attacks on MS when they could *actually be contributing some effort* to the OS movement.

Carry on guys, good work.

Re:C++

[VAXGeek]

I'm probably going to get modded down but anyway: the big deal is that Microsoft champions C#, while Open Source champions C++. Therefore, nothing can POSSIBLY be wrong with C++. At least C# doesn't have some awful templating system. (Watch me get replies from people claiming to enjoy templates).

Re:Duh. Its called reflection

[Anonymous Coward]

It does *if* you have the correct permissions. Just like .Net.

If you're running a .Net app off a webpage, it won't have private reflection permission either.

Re:Microsoft Security

[p3d0]

No, security obviously doesn't rely on the inaccessibility of private members. Just like C++: if you use "private" for security, you're in for a surprise when someone adds "#define private public" before including your header file.

Sigh

[kahei]

typically, a language ensures that a member marked as private is hidden from anyone who doesn't have your source code,

No, typically the process of compilation does that for a compiled language that is naturally hard to read, and an obfuscator is used to do it for interpreted languages that keep type information or are otherwise easy to read.

If you use a language that stores lots of rich metadata in the executable (like .NET), and that has a clear and readable bytecode (like .NET or Java), then you should use an obfuscator if you don't want anyone to be able to see your code.

This being slashdot, though, naturally it's all Microsoft's fault. But there's still an element of fun in deciding *why* it's all their fault! Is it:

1 -- MS's fault for not obfuscating code by default?
2 -- MS's fault for including metadata?
3 -- MS's fault for not having .NET compile to x86 assembly language?
4 -- MS's fault for not simply holding all compiled .NET assemblies in escrow on behalf of their authors, releasing them only to trusted parties?
5 -- MS's fault for not changing the nature of information itself to make this particular information hard to interpret?

Re:By design?

[Sique]

I completely fail to see what's nasty about it. If it's not documented, you just plain should not rely on it. Isn't hat the way all code works?

The problem is the same like the old one which let you disassemble VisualBasic programs back to the sourcecode about some years ago.

If you put a trade secret inside your code, it is now much easier to access by an outsider because she doesn't have to rely on the binary code alone, but can spy on the structure of the program. This gives her a pretty good clue which algorithm was used and which data structures were used.

Basicly it makes everything you do in .NET a "half open source" program.

Re:C++

[crazyphilman]

I don't think you should be modded down. It's an interesting point. Open source types do sometimes tend to "overlook" the shortcomings of C++ (and their other favorite languages like Perl, Python, Ruby, etc) because it's a political thing for them, and you end up getting into these big propaganda wars. You could say they're "drinking the kool-aid", just like all the frothing, rabid managers back in the dot-com days used to.

But I think most open-sourcers are a little more sedate than that; they like C++ because C++ is completely free and nonproprietary (gcc is GPL, and C++ has been an ANSI standard for way over a decade, hasn't it?). So, in a sense, it's a language that no one can ever take away from you, and which has been more or less frozen in its current state (new functionality is generally handled with additional libraries) for years. C# and Java, on the other hand, are proprietary languages, so it is theoretically possible for the companies that own those technologies to change them on a whim, or even kill them off. I sympathize with this view somewhat, but I don't fully agree with it.

Is the "freeness" of a tool enough to support its use? Should we choose our tools based on how free they are, or on how useful they are to us? How do you pick a compiler, really? It's interesting.

I like Java, personally. It has pretty nice features and a rich API. I lust after C# somewhat, but my boss won't let me use it (he likes VB.Net -- pity me).

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

[Anonymous Coward]

Check this post [slashdot.org] for a suitable reply.

Re:.Net is Java!

[Zebra_X]

.NET is not Java.

If Web Forms were servlets they would take longer to load, database accesses would take longer, server side processing would be slower, and high demand would crash your server.

If Web Forms were Servlets it would take several days to setup, configure and tune a new servlet environment a.k.a Web Form environment.

If C# were Java, you wouldn't have delagates and a fully event driven programming model. If C# were Java then you would have to sacrifice properply built objects and methods in order to make your application run with reasonable speed.

If the CLR were the JVM then you would need a gig of ram to run a full scale web application not 512. If the CLR were the JVM, it wouldn't restart if it crashes.

Sure, .NET and C# took things from java. They also took things from Cold Fusion, Web Objects, C++, Objective C, C and every other technology that had something good to offer.

The C Programmer's Handbook

[kmahan]

The best "C" book out there is (was) "The C Programmer's Handbook" by Bolsky (AT&T Bell Laboratories). 84 pages. Small. Designed as a reference. C Syntax, precedence rules, a few funtions, ascii table, etc.

They used to include the book with each 3B (and other) unix box.

It was written to be useful, not to be big.

Security

[Get Behind the Mule]

Good heavens! I'm a little startled at the thread so far -- all of these people stoutly declaring that violation of private class member access is not a security issue. I frankly thought that the Slashdot crowd understands these things a little better. If this matter is really so poorly understood, then the state of software security is in pretty bad shape.

Enforcement of access levels is an important feature of the security inherent in a programming language. Yes, you can trick your way around private in C++, and that is a security weakness of C++. Access to private members means that you have access to the internal implementation of a class, which the programmer specifically did not mean to let you have. To be sure, the fields you can manipulate may not do anything very interesting, and a hacker might not find a way to use them to compromise a whole system; but then again, may he can. You just can't know for sure any more. Generally, any code that can be made to execute instructions that the programmer did not intend is a potential security weakness. C programmers who write sprintf without bounds checking may be exposing their machine to a buffer overflow exploit; you just don't know.

Here's an example from Scott Oaks in Java Security: Suppose I'm using a shopping cart application that I downloaded from www.goodguys.com, and I trust it with my credit card number. Suppose they implement it by storing a CreditCard object as a member field. Suppose I'm also playing a game downloaded from www.badguys.com, and it's running in the same virtual machine; so it could conceivably access classes of the other application. I certainly hope that the first application prevents access to the CreditCard object, and I certainly hope that the virtual machine enforces that restriction very strictly.

Isn't this a security issue?

[Dominic_Mazzoni]

People seem to be saying that this isn't a security issue, but I still think it is.

Of course, if you're running .NET without any protections, and give it full access to your computer, then it doesn't matter.

But .NET is supposed to be able to run in a sandbox if you want it to. Now, in Java, acecss to private class members is strictly forbidden by the JVM, so as long as there are no bugs in the API of the class, the code is secure.

But with .NET, there are many possible exploits. By messing with a class's private variables, it's easy to get the class into a state that would never happen if you just used the public API - and thus it's not hard to imagine getting the class to do something it shouldn't be allowed to do. Since a number of these .NET classes must make Win32 system calls, there's probably a way to trick one of the classes into calling something that it normally shouldn't be able to.

Remember, the virtual machine prevents your actual C# code from accessing the system directly. But a lot of the .NET classes that Microsoft provides are written in C/C++ and have to access the system - and by messing up the private variables in these classes, there's no end to what you could possibly do.

People keep saying that this is no different than C++. I agree - except that C#/.NET is supposed to be able to run in a sandbox, and I think that this means that the sandbox is not all that secure.

finding them? sure. calling them? no.

[MORTAR_COMBAT!]

Naturally even with rudimentary decompilers (and even the Java reflection API) you can find out what private fields and methods are defined for a given Java class.

However if they are private, you can't actually find out the values of those fields for a given object, or call those methods. You get an IllegalAccessException.

This .NET exploit advertises itself to be much different. Sure, you can still find out what private stuff you want.

But under .NET, it appears you can actually _invoke_ those methods, methods which are probably meant to be hidden under a separate security API layer, etc.

Re:Duh. Its called reflection

[mnmoore]

This is not necessarily true.

If a SecurityManager is installed (as one would be in the applet environment or any other environment running less-than-completely-trusted code) Class.getDeclaredField() for a non-public member may throw a SecurityException (depending upon the policy enforced by the particular SecurityManager).

Re:Conclusion

[dash2]

Not entirely true. The default way to build objects in Perl exposes private functions and members, and just trusts the API user to be sensible. But there are well-documented ways to create truly private functions and members - like using file-scoped variables or anonymous file-scoped subroutines. Damian Conway's book (Object-Oriented Perl) describes this in detail.
Perhaps there are still ways to get round this security by something more lowlevel, like peeking directly into RAM, but they certainly aren't at all easy.

You are WRONG

[grungeman]

It is not possible in Java. Otherwise you could access parts of java.lang.SecurityManager, which itself is written in Java. Not sure about .Net, but in Java you could do a lot of really nasty stuff if this was possible.

If this was possible in Java, Micrsosoft would have published at least three big reports on how insecure Java is (of course through some "independant" third party consulting companies)

Re:Duh. Its called reflection

[gh]

Here's a juicier example for Java...

"hi there".equals("cheers !") == true [artima.com]

Not only does Heinz Kabutz demonstrate accessing private members, he shows how one can alter the behavior of interned Java strings!

Re:Conclusion

[Ralph Wiggam]

So what is the target demographic, mechanics? Albino carpet cleaners? Of course it's Perl and C programmers.

-B

Another poor API from MS

[solprovider]

If the alternative to writing tons of code is accessing private functions of the internal API, then the API was designed very poorly.

Everybody seems to agree that a quick ACL changer is useful. The code already exists in private functions. If the private functions should not be public because they bypass data reliability checks, the API designers should provide a public function that provides a safe method to call the private function.

Encapsulation should be an absolute law. The maintenance headaches of ignoring encapsulation should be too great to encourage bypassing it.

Providing useful functionality in private functions without allowing the functionality through public functions is security through obscurity. It either enourages programmers to write poor code, or forces the programmers to do extra work. The whole point of "platforms" is that they greatly reduce the amount of code needed to implement an application while providing basic functionality such as security and networking.

Imagine if Apache did not exist and every application needed to implement a web server. Every web project would require much more code. Now imagine if the only method to get Apache to display a web page was to use tricks to access private functions. Everybody would do it. Now imagine MS wrote the API. Oops, that is what we have here. Really basic and useful functionality is hidden from the programmer. "Luckily" the platform security is so poor that everybody knows how to access the functions anyway.

Apparently these tricks are posted on Microsoft's web site (based on from other posts since I am not going to check.) Apparently MS knows the functions are useful. Apparently MS knows the language is broken.

Will MS fix the API?
Will MS fix the language?
Will MS encourage these tricks?
Will MS break the code that uses these tricks?
Will MS reduce the amount of work necessary to write apps on their platform?
Will MS divide programmers between the
- experienced ones who know the illegal tricks,
- newbies who thought documentation was complete, and
- good programmers who expect MS to fix the code someday and are not willing to risk using these tricks?

I am happy I am not one of those programmers who is faced with the choice to write good code or write MS code.

This is NOT a problem!

[spitzak]

I'm going to agree with the intelligent majority here. This is not a security feature and is not any kind of failure of Microsoft. Private members are designed to encourage properly-written code, but they don't enforce it.

The author is promoting bad programming practice, if his code becomes in common use he will force Microsoft to lock the internal implementation of the objects, which will make them inefficient and may lock in bugs. If his code is not popular than Microsoft will probably change it under him and break all his code, and this is perfectly within their rights, as the whole point of "private" is that this portion is not part of the API and it may change!

Re:finding them? sure. calling them? no.

[asills]

.NET has the exact same thing. If you run your .NET code in a "sandbox" you can disable reflection permissions, thus making it impossible for a running application to reflect over your assemblies.

Just like java, however, get it out of a sandbox and you can do whatever you want to it.

Re:Conclusion

[ProfKyne]

• Perl.Net -- not a Microsoft product, therefore not related to the discussion ("target demographic of .NET initiative").
• Managed Extensions for C++ -- not C, therefore not related to the discussion (I said "C programmers" and in another branch of this thread [slashdot.org] I make it clear that I used C and not C/C++ for an explicit reason).