Hijacking .NET 561
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? (Score:4, Interesting)
What does this mean for the security of
So .Net is like C++? (Score:5, Interesting)
OTOH in C++ the public/protected/private distinction is enforced solely by the compiler, and code has full access to the machine.
Obviously in
Dan 'Obvious' Appleman (Score:5, Interesting)
Private methods and (Score:5, Interesting)
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++ (Score:1, Interesting)
Re:Duh. Its called reflection (Score:2, Interesting)
If you're running a
Re:Microsoft Security (Score:5, Interesting)
Sigh (Score:5, Interesting)
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?
Re:By design? (Score:4, Interesting)
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
Re:C++ (Score:4, Interesting)
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? (Score:1, Interesting)
Re:.Net is Java! (Score:2, Interesting)
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,
The C Programmer's Handbook (Score:2, Interesting)
They used to include the book with each 3B (and other) unix box.
It was written to be useful, not to be big.
Security (Score:3, Interesting)
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? (Score:1, Interesting)
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.
finding them? sure. calling them? no. (Score:5, Interesting)
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
Re:Duh. Its called reflection (Score:2, Interesting)
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 (Score:4, Interesting)
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 (Score:2, Interesting)
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 (Score:2, Interesting)
"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 (Score:4, Interesting)
-B
Another poor API from MS (Score:2, Interesting)
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! (Score:3, Interesting)
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. (Score:2, Interesting)
Just like java, however, get it out of a sandbox and you can do whatever you want to it.
Re:Conclusion (Score:3, Interesting)