Slashdot Mirror
Hijacking .NET
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 limitation of C# or of .NET?
.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...
What does this mean for the security of
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.
.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?
OTOH in C++ the public/protected/private distinction is enforced solely by the compiler, and code has full access to the machine.
Obviously in
-- Ed Avis ed@membled.com
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 :-/
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.
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).
this sig limit is too small to put anything good h
It does *if* you have the correct permissions. Just like .Net.
.Net app off a webpage, it won't have private reflection permission either.
If you're running a
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.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
typically, a language ensures that a member marked as private is hidden from anyone who doesn't have your source code,
.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.
.NET compile to x86 assembly language? .NET assemblies in escrow on behalf of their authors, releasing them only to trusted parties?
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
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
4 -- MS's fault for not simply holding all compiled
5 -- MS's fault for not changing the nature of information itself to make this particular information hard to interpret?
Whence? Hence. Whither? Thither.
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?
.NET a "half open source" program.
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
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).
Farewell! It's been a fine buncha years!
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.
Invalid Checksum. Retrying.
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.
Always keep a sapphire in your mind
People seem to be saying that this isn't a security issue, but I still think it is.
.NET without any protections, and give it full access to your computer, then it doesn't matter.
.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.
.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.
.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.
Of course, if you're running
But
But with
Remember, the virtual machine prevents your actual C# code from accessing the system directly. But a lot of the
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.
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.
.NET exploit advertises itself to be much different. Sure, you can still find out what private stuff you want.
.NET, it appears you can actually _invoke_ those methods, methods which are probably meant to be hidden under a separate security API layer, etc.
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
But under
MORTAR COMBAT!
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).
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.
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)
Signature deleted by lameness filter.
Here's a juicier example for Java...
"hi there".equals("cheers !") == true
Not only does Heinz Kabutz demonstrate accessing private members, he shows how one can alter the behavior of interned Java strings!
So what is the target demographic, mechanics? Albino carpet cleaners? Of course it's Perl and C programmers.
-B
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.
I spend my life entertaining my brain.
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!
"First you gotta do the truffle shuffle."