Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Hijacking .NET

timothy posted more than 11 years ago | from the undocumented dept.

Programming 561

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.

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.

cancel ×

561 comments

Respect me (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#6007804)

Come on... where's my props?

You must respect my duel first posts: here [slashdot.org] and here. [slashdot.org]

Am I part of the club yet? Come on... where's the IRC server? where's the chat room? Tell me... tell me...

AC

dual (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#6007923)

moron

Fr0st? (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#6007805)

Fr0st Pr1st!

Love Always,
News For Turds

Re:Fr0st? (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#6007839)

Of course, without suprise, you FAILED!

Reviewing your digestive health (-1, Troll)

colon cleaner (671937) | more than 11 years ago | (#6007806)

Let's talk stools.

The stool tells you a lot about your colon health. If it's dark brown in color, and it sinks, and it stinks, that's not good. And don't feel bad, that's the way most people are. What you want to see is light brown color, which means it's full of fresh bile from the liver, very mild odor, and a stool that floats. We're talking low-density here folks. The more compaction you have the darker the color and the faster it sinks. Compaction is not good. Also, moving bowels should be SIMPLE. If the veins are popping out of your neck and you feel like your doing the bench press, you NEED to cleanse your colon.

When you do the cleanse, for the first few days....things are a little weird. But you know you're cleansed when you see the above good stuff happening, and you are eliminating at least 2-3 times per day.

Cleansing your colon is a 30-day process. No need to change your current diet. Its also very economical at under $52. You may be very surprised at some of the benefits you will receive besides just losing 1-5 lbs of cr*p from your body and brightening your future health.

People have reported more energy, less allergies, clearing of acne, cessation of migraines, and many other results, not to mention restored regularity. When your body is void of old, poisonous toxins that are constantly being reabsorbed through the colon walls, it can begin to heal again. And when the colon walls are clean, the good nutrients from your food and supplements can be absorbed again. You will be thrilled with the results.

46 Pages? (-1, Flamebait)

VAXGeek (3443) | more than 11 years ago | (#6007814)

How long did it take to write this review? Isn't this book a little too narrow in scope for a book review? This is probably more of a leaflet. I've seen longer articles in phrack.

My thoughts: (0, Flamebait)

Anonymous Coward | more than 11 years ago | (#6007820)

you fucking faggot cumdumpster moderators - go ahead, use your mod points here. better here than modding down the opinions of people you don't agree with simply because they employ logic and aren't pansy faggots that worship all things linux and bash all things microsoft. by the way, you're commie scum you faggot moderators.

Re:My thoughts: (-1, Offtopic)

KrispyKringle (672903) | more than 11 years ago | (#6007870)

" you fucking faggot cumdumpster moderators...better here than modding down the opinions of people you don't agree with simply because they employ logic..."

They do? You don't. Who's "they"?

Make any private member acessible. (2, Insightful)

D4MO (78537) | more than 11 years ago | (#6007826)

Use a memory hex editor!

Conclusion (4, Funny)

borgdows (599861) | more than 11 years ago | (#6007831)

If you code in a Microsoft programming language, you can't even trust your own code!

Re:Conclusion (1)

VAXGeek (3443) | more than 11 years ago | (#6007879)

This isn't really any different from C/Perl. (At least until Palladium comes out.)

Re:Conclusion (5, Insightful)

JanneM (7445) | more than 11 years ago | (#6008049)

I thought so too at first, but I believe it's not really the same thing here. Neither Perl nor C stuff depends on this encapsulation for any security stuff. For instance, Perl has sandboxing through taint checking and the safe module, and they do not assume that the potentially malicious code cannot access private members. Indeed, the filosophy in Perl is quite different - you are free to access any member function you want, or even 'private' data; it is assumed, though, that you know what you're doing in that case and won't come crying if things break for you as a result.

If only... (-1, Offtopic)

archetypeone (599370) | more than 11 years ago | (#6007833)

I had a hammock.

Is this a C# or a .NET problem? (4, Interesting)

Dominic_Mazzoni (125164) | more than 11 years ago | (#6007835)

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...

Re:Is this a C# or a .NET problem? (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#6007867)

I think your concept of converting analog to digital is ridiculous.

Analog by definition is ALWAYS readable. It is the SINGLE format that is by definiton OPEN, can always be understood by anyone, and can stan the test of time. Aliens could discover an analog recording 50 billion years from now and decode it without knowing ANYTHING else about our culture. But right now, data encoded 25 years ago in an open digital format is often incredibally hard to translate to a usable form.

Digital requires people to understand the digital format. The ONLY advantage to it is quality via the suprression of unintended noises. But if we are copying something that started out as Analog, then the quality improvement is minimal at best.

DO not blindly use Digital for things that Analof is far better.

Re:Is this a C# or a .NET problem? (0, Troll)

TopShelf (92521) | more than 11 years ago | (#6007892)

It sounds like a .NET issue, which makes it more fundamental. So much for that Secure Computing initiative outta Redmond...

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

iceburn (137875) | more than 11 years ago | (#6007911)

Since the sample code is both C# and VB.NET, it sounds like this is a problem with the CLR.

Re:Is this a C# or a .NET problem? (5, Informative)

Anonymous Coward | more than 11 years ago | (#6007971)

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.

Re:Is this a C# or a .NET problem? (5, Insightful)

Anonymous Coward | more than 11 years ago | (#6008074)

This whole story is hilarious. All (decent) languages let you hide implementation details from the end user. Finding them isn't `hacking` - its `stupid` as it means that if a chunk of code is changed to use, say, a doubly linked list rather than an array, your code would break, whereas it wouldn't if you accessed only the public methods/variables.
This `exploit` is laughable, pointless and ultimately going to waste your time. The sort of coders who could use it would have the skill to figure it out in the first place anyway.

Re:Is this a C# or a .NET problem? (5, Informative)

1000StonedMonkeys (593519) | more than 11 years ago | (#6008077)

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.

Re:Is this a C# or a .NET problem? (5, Informative)

Erv Walter (474) | more than 11 years ago | (#6008050)

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.

Posted on BugTraq (3, Insightful)

oliverthered (187439) | more than 11 years ago | (#6007838)

Isn't this a security bug, you think that you've hidden some code, but infact it isn't.

Re:Posted on BugTraq (0)

Anonymous Coward | more than 11 years ago | (#6007868)

It's not a bug, it's a feature!

We have grown to expect these kinda things (0)

Anonymous Coward | more than 11 years ago | (#6007842)

From microsoft, right?

By design? (4, Insightful)

DrTentacle (469268) | more than 11 years ago | (#6007844)

Is this behaviour by design, or merely a side effect of the implementation? If it's a side effect, then don't rely on the support for this "feature" to continue in future releases of the .NET framework. MS has a nasty habit of changing undocumented features...

Re:By design? (1)

d_lesage (199542) | more than 11 years ago | (#6007948)

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?

Re:By design? (3, Interesting)

Sique (173459) | more than 11 years ago | (#6008064)

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.

Probably by design (0, Flamebait)

burgburgburg (574866) | more than 11 years ago | (#6008033)

Microsoft has always used undocumented little tricks like this. The fact that they are potentially opening major security holes throughout their systems is handled with the brilliant "Don't tell anyone. Shhhhh." technique.

Unfortunately for them, this has somehow slipped into the general public. They'll have to use the even more secure "Take it out right now and put it back when everyone is looking at some other security problem." technique.

Re:By design? (1)

Jellybob (597204) | more than 11 years ago | (#6008043)

Everybody has a habit of changing undocumented features.

If something is undocumented, that means that the author didn't think it was worth of documentation - possibly because it was a temporary hack they intend to clean up.

I've never used ebooks, but this sounds worth it (0, Informative)

onelin (116589) | more than 11 years ago | (#6007847)

The fact that private classes in .NET can be accessed sounds like pretty big flaw. The kind any of us would expect from Microsoft. Finally I have a reason to actually laugh at .NET.

Mod me ignorant if you like, but this sounds like one damned nifty book and something MS certainly can't be proud of.

.Net is Java! (0, Insightful)

Anonymous Coward | more than 11 years ago | (#6007848)

And nothing more.
Nothing new under the Sun, been there already for 4-5 years.

Web Forms - a fancy name for Java servlets.
C# - an alias for Java programming language.
CLR and .Net platform - a conspicuous name for the Java Virtual Machine
Web Services - nothing more that classes interacting using XML

After demonstrating to us for years why Microsoft technologies are superior to Java and why we should stick to them, here we go - we find out that the system registry sucks, that we have problems with the versioning (DLL Hell), that MS languages are propriatory to only a limited number of platforms out there (ONE!), that COM sucks and here we go - DA! DA! we reinvent the wheel.

After all, Java addressed all these issues 4 years ago, so if MS is to be acclaimed is that they finally realized there's a better technology and concepts out there and they adopted it in order to survive the massive shift of people towards their competitors.

"Where do you want to go today?" Would you want to go to a company whose "Next Generation Services" is something 4 years old and desperately tries to play a catch up game? What about all the other statements - "PC will never dissapear" whould you still believe in those?

But (2, Insightful)

Skim123 (3322) | more than 11 years ago | (#6008065)

.NET is a modernized version of Java (for example, C# supports properties, while Java you have to write the old setProperty() getProperty() methods). Furthermore, .NET is targetted for a specific platform, thereby being able to outperform Java.

Yes, you may say "Microsoft has just reinvented the wheel," but hopefully you'll agree that they've made a better version of the wheel in the process.

Don't you just hate it when.. (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#6007849)

You try and peel the label off something and it doesn't come clean off, leaving behind a sticky residue that gets all gunked up?

try rubbing alcohol (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#6007951)

or zippo fluid (naptha) if it's really tough.

be careful about using it on plastics, it may mar the finish. don't leave it on too long and rinse it well.

Re:try rubbing alcohol (-1, Troll)

Anonymous Coward | more than 11 years ago | (#6008070)

I use rubbing alcohol to clean and prep solder joints and various other uses and unless I am wearing latex gloves, I get stomache craps and the "runs" or shits about 5-10 hours later. And no, I am not drinking it or using large quantities. Just a napkin or lint free wipe slightly wetted for cleaning with over-the-counter strength rubbing alcohol. Odd but true.

Re:Don't you just hate it when.. (0)

Anonymous Coward | more than 11 years ago | (#6008030)

Yeah. They have that problem all the time [slashdot.org] at Microsoft!

So .Net is like C++? (5, Interesting)

Ed Avis (5917) | more than 11 years ago | (#6007854)

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?

Re:So .Net is like C++? (1, Informative)

Anonymous Coward | more than 11 years ago | (#6007976)

In Java the check is usually done only at compile time. Starting the VM with "-Xfuture" as an argument will force the checks to happen at runtime as well.

Re:So .Net is like C++? (1)

DanielDittmar (447579) | more than 11 years ago | (#6008011)

Java has the .setAccessible methods that allow access to private members via reflection. These methods are subject to the security context, so they probably won't work in applets. And of course information about private members can be extracted by tools that are freely available from well known cracker sites like java.sun.com.

Re:So .Net is like C++? (1)

Ed Avis (5917) | more than 11 years ago | (#6008051)

Of course you can disassemble a class and find what its private members are. You can do that in any language; relying on people not figuring things out from the object code is just trying to get security through obscurity.

Re:So .Net is like C++? (5, Informative)

Erv Walter (474) | more than 11 years ago | (#6008026)

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:So .Net is like C++? (1)

arabung (244309) | more than 11 years ago | (#6008036)

You can access private fields/methods in Java with reflection and a modified policy file. This is done by modifying your policy file (granting ReflectPermission or something), and calling setAccessible(true) on the Field and Method objects you want to invoke.

On a side note, this is the worst idea I've ever heard.

Re:So .Net is like C++? (5, Insightful)

patniemeyer (444913) | more than 11 years ago | (#6008042)

In the first chapter of my book, Learning Java I make this comparison and show an example of how trivial it is to forge a pointer in C++.

The thing that many people still just don't get about Java is that it was designed to supply this kind of safety *without* impacting performance. In Java byte code verification happens statically, before the code is executed using a kind of theorem prover.

With certain concessions from the byte code you can prove that various types of problems (stack overflows/underflows, incorrect casts, etc.) cannot happen and you don't have to check for them at runtime. Of course in OO languages let you do things that require runtime checks, but at the bottom level Java can be statically compiled and optimized amost as far as C/C++ (only runtime array bounds checks are required) and because Java contains so much more information at runtime the new generation of profiling runtimes can do further optimizations dynamically that cannot be done in C/C++ (e.g. optimistically inlining methods and profiling garbage collection routines).

Pat Niemeyer
Author of Learning Java, O'Reilly & Associates and the BeanShell Java scripting language.

Dan 'Obvious' Appleman (5, Interesting)

playtime222 (673645) | more than 11 years ago | (#6007857)

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 :-/

Re:Dan 'Obvious' Appleman (1)

pfharlock (538158) | more than 11 years ago | (#6007999)

You misspelled write.

Re:Dan 'Obvious' Appleman (1)

playtime222 (673645) | more than 11 years ago | (#6008037)

Bugger :( I'm ill. I only got out of bed to check email. That'll teach me.

You misspelled write. (1)

pfharlock (538158) | more than 11 years ago | (#6008066)

Ok, I'm trying to be original. By the way, to anyone actually reading this, this is so slashdot will post this message.

C++ (5, Informative)

Anonymous Coward | more than 11 years ago | (#6007858)

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?

Re:C++ (1, Interesting)

VAXGeek (3443) | more than 11 years ago | (#6007909)

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:C++ (0)

Anonymous Coward | more than 11 years ago | (#6007968)

No, I think you're quite right. While I havn't taken the time to learn C# I have no intentions of jumping on the "Its Microsoft so it must be crap" bandwagon. At the same time I do know enough C++ to be dangerous, and I also know it has holes and problems of its own.

Out of interest, how would you access a private method from outside of the class? I'm guessing you could overwrite the vtable or a pointer if you knew the exact entry point of the private method, but how could you determine this at runtime?

Re:C++ (0)

Anonymous Coward | more than 11 years ago | (#6008010)

Templates are OK as long as you don't try any of that whacky meta-programming stuff. That's just nuts.

Got root? (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#6007861)

I know that I do!

Trustworthy computing. Tomorrow's technology some other day.

Microsoft maybe in deeeeeep trouble now (4, Funny)

dk.r*nger (460754) | more than 11 years ago | (#6007865)

.. now we can just bypass this part of all Microsofts APIs:

public method doStuff ( &task ) {

if ( (int) (Math.rand() * 10) == 8) {
throwError(BSOD);
} else {
actuallyDoStuff ( &task );
}
}
}

private method actuallyDoStuff ( &task ) {

...

}

Re:Microsoft maybe in deeeeeep trouble now (1, Troll)

jalet (36114) | more than 11 years ago | (#6007955)

> if ( (int) (Math.rand() * 10) == 8) {
> throwError(BSOD);

I think you did a mistake, in the original MS code it's more probably something like :

if ( (int) (Math.rand() * 10) = 8) {
throwError(BSOD);

instead.

Re:Microsoft maybe in deeeeeep trouble now (1)

jalet (36114) | more than 11 years ago | (#6007986)

Funny : I tried to write <= but without using the html entity syntax for <.

I think my own mistake makes it even better !

Re:Microsoft maybe in deeeeeep trouble now (2, Funny)

kenthorvath (225950) | more than 11 years ago | (#6008041)

Shouldn't that mean that certain users could have a higher saving throw vs. evil, and actually get their OS to work properly most of the time? May paladins using paladium won't experience any errors!

Wow... (-1, Troll)

Anonymous Coward | more than 11 years ago | (#6007872)

Am I ever glad that I chose to wait before jumping on this seemingly too good to be true bandwagon....

Unsure... (4, Funny)

cruppel (603595) | more than 11 years ago | (#6007874)

I'm not sure I'd want people accessing my private parts :) Seriously though, isn't the goal of a class to disable another programmer, co-worker or not, from having access to potentially destructive options in a program? If you can use the private parts of a class then why use a class? I read this review twice just now, maybe I'm missing a key detail that would clarify.

Maybe the title should be changed (5, Insightful)

julesh (229690) | more than 11 years ago | (#6007875)

Maybe the title of this book should be changed to "1001 ways to write bad code". Relying on undocumented private members of classes violates encapsulation and pretty much guarantees that your code will not work with (a) compatible implementations on other platforms, and probably also (b) future versions on the same platform. Just Say No, is my advice.

Re:Maybe the title should be changed (1)

Jack William Bell (84469) | more than 11 years ago | (#6007910)

You beat me to the post I wanted to make. Now the most I can do is say "Mod this up!"

Re:Maybe the title should be changed (1)

elmegil (12001) | more than 11 years ago | (#6008054)

Of course if you're a cracker, you're more interested in doing things you ought not be able to do than writing good code.

Duh. Its called reflection (5, Informative)

Asmodeus (10868) | more than 11 years ago | (#6007876)

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

Re:Duh. Its called reflection (1)

Asmodeus (10868) | more than 11 years ago | (#6007907)

uuups. That should be Modula-3 not modula-2

Re:Duh. Its called reflection (1)

code_nerd (37853) | more than 11 years ago | (#6007953)

The issue is not that the private members of a class can be seen, it is that they can be directly accessed. While you can do this in, say, C++, C or Perl, none of those languages advertise a JVM-style secure-sandbox environment, which is how MS pitches the CLR. The big worry is of course that you can think you have hidden code from unauthorized access.

Re:Duh. Its called reflection (2, Informative)

Ageless (10680) | more than 11 years ago | (#6007954)

I can't speak for anything but Java, but in Java reflection does not allow you to access private members. That's part of the security of Java.

Re:Duh. Its called reflection (2, Interesting)

Anonymous Coward | more than 11 years ago | (#6007972)

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:Duh. Its called reflection (1, Insightful)

Ageless (10680) | more than 11 years ago | (#6008069)

No, it doesn't. With Java reflection you can access the exact same methods that you can access via compiled code. It's just done at runtime. The article/book points out a flaw in .Net that allows code to access private methods that it would not normally be able to access through normal access control. This flaw does not exist in Java.

Re:Duh. Its called reflection (1)

krumms (613921) | more than 11 years ago | (#6008025)

IIRC, although you can access member NAMES using reflection in Java, you can't actually access the values at runtime without crazy exceptions being thrown - IllegalAccessException or something like that.

Which is, y'know, nice.

To take my dig, I don't think being able to access private member variables is too much of a problem. Unless you're a fool, and have private member variables like 'private string rootPassword', 'private boolean allowHax0ring' or 'private int numSecurityFlaws', your code should generally be unaffected. So this just proves to be a neato trick I guess - with limited scope for malicious use.

Harumph (4, Funny)

renehollan (138013) | more than 11 years ago | (#6007877)

...and here I thought that
((<sneaky_private_type_I_wanna_access> *)<void_starish_opaque_handle>)-><ha_take_that_hid den_member> = 0; was bad style.

Re:Harumph (1, Funny)

Anonymous Coward | more than 11 years ago | (#6007985)

I once saw the following hack to access a private member in a thirdparty library on the IRIX platform :

#define private public

Worked like a charm. A hack of some type was needed since the class in question did not release resources properly.

moron tricking people (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#6007880)

that's nothing. you should see what happened to most of yOUR monIE. it's being used to finance sum sorte of southern baptist/freemason corepirate terrorist execrable.

More version incompatible program (3, Informative)

plcurechax (247883) | more than 11 years ago | (#6007887)

I suspect the most common use of this is not attempts at bypassing poorly thought out security. I hope MSFT programmers are not hiding passwords in .NET classes. The most common usage will be "tweaks" and such that will be dependent on a specific .NET framwork version/release.

By delving into the private classes, you might be able to get speedups on a specific (or common) platform, say MSFT's .NET framework version 1.0 for Windows 2000/XP, but come next release, these tweaks are likely to break. That's why private members of classes are private, because they are not part of the documented API.

Re:More version incompatible program (1)

pbur (88030) | more than 11 years ago | (#6007931)

Um, I think the point should be that private members shouldn't even be visible. That's why their private! At compile time, runtime or anytime, private or protected elements should remain that way. Otherwise, what's the point of marking them that way?

Re:More version incompatible program (1)

yatest5 (455123) | more than 11 years ago | (#6008045)

oh yeah, private STRING importantPassword="xxxxx"

because THATS HOW PASSWORDING WORKS!

Private methods and (5, Interesting)

yatest5 (455123) | more than 11 years ago | (#6007891)

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:Private methods and (2, Informative)

Ageless (10680) | more than 11 years ago | (#6007975)

This is not true in Java. No matter what the compiler spits out it is verified by the VM before it is executed and if the bytecode is trying to access something it is not allowed to the VM will cause that code to fail. This is part of the security that Sun touts about Java.

Re:Private methods and (2, Insightful)

yatest5 (455123) | more than 11 years ago | (#6007987)

Er, write your own VM then. Client-side security is no security at all i.e. you're free to fuck up your own computer any which way you want.

I don't care if anyone has a peek. (-1, Redundant)

Bowie J. Poag (16898) | more than 11 years ago | (#6007897)



I don't particularly care if anyone has a look at my private member. Looks the same as anyone else's, plus i'm towards the high end of average in size.

Please don't touch my private members... (-1, Troll)

Anonymous Coward | more than 11 years ago | (#6007900)

I have private variables I don't want you to touch, especially /dev/penis and /dev/asshole.

However, feel free to access them through public methods put_your_two_lips_on_my_wood_and_kiss() and ram_me_in_the_ass().

Thank you.

Umm.. and (1, Troll)

DaLiNKz (557579) | more than 11 years ago | (#6007904)

and you actually expected something from Microsoft secure...? ..cough..

Microsoft Security (4, Funny)

rossz (67331) | more than 11 years ago | (#6007912)

As a bonus, you get a great introduction to how Windows security works
How is that possible. By his own statements he proves that Microsoft security DOES NOT work.

Re:Microsoft Security (4, Interesting)

p3d0 (42270) | more than 11 years ago | (#6008024)

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.

Re:Microsoft Security (0)

Anonymous Coward | more than 11 years ago | (#6008048)

And by your own statement you are an idiot. This is not a security issue at all. All programming languages have the same "problem" including C++ and Java. "private" does not in any language mean "secure" or "invisible".

This entire article is flamebait.

He just violated the DMCA!!!!!!!!! (1, Funny)

DailyGrind (456659) | more than 11 years ago | (#6007915)

This is Microsofts secret attempt at putting all anti-MS developers in jail. They pick up the book, try to access private functions and data and presto --> just broke the law.

Soon the only developers that are not breaking the law will be those working for MS or using .NET

Unbiased?!? review (1, Informative)

Anonymous Coward | more than 11 years ago | (#6007925)

a quick google search turned up this link [emu.edu.tr] which contains the following quote:

You can find out more about the rest of the Desaware team on the help file on the CD-ROM: Stjepan Pejic, Roan Bear, Marian Kicklighter, Karyn Duncan, Josh Peck, Levy Ring, Edo Mor, Michael Dickman, and Matt Solnit-thank you all for your help.

Matt Solnit (the reviewer) ... are you still with Desaware? (you know, the org that publishes this book)

Why should they always bypass logic? (2, Funny)

ptaff (165113) | more than 11 years ago | (#6007927)

So, a private member is not private.

All this fighting for Intellectual Property, for information privacy, DRM, to discover that actually, behind the scenes, in the Microsoft world,

a private member is not private

Look, ma, we'll sell this slow API, and on our side we'll use undocumented features, make private members public, get a performance boost and say afterwards we've got a better product and that it was all fair play.

Innovation, would say Ballmer.

Washington Strikes Again (see prior story) (5, Funny)

rc5-ray (224544) | more than 11 years ago | (#6007932)

Read on for more of Matt's review of this guide to tricking private members to do your bidding.

In related news, Washington State has banned the sale of this book because of gratuitous discussion of "private members".

How it's done (5, Informative)

Jabes (238775) | more than 11 years ago | (#6007952)

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.

Must be a typo.. (1, Redundant)

Gibble (514795) | more than 11 years ago | (#6007957)

"As a bonus, you get a great introduction to how Windows security works"

Should read: "...how Windows security doesn't work."

Big deal - You can do this in Java with reflection (-1)

Anonymous Coward | more than 11 years ago | (#6007961)

What a joke. More anti-MS knee-kerk. You can do the same thing in Java using the Reflection API

Not unique to .NET (1)

joshtimmons (241649) | more than 11 years ago | (#6007973)

I'm not sure this would be unique to .NET. With all compiled languages (java is an interesting exception), the protected members are only protected by the compiler at compile time. There's nothing stopping you from hijacking the vtable in C++ or locating the function entry point in general and then executing directly in whatever manner you prefer. It's all machine code at that point and the CPU doesn't care who executed it or how they got there.

People who rely on protected/private to be a security feature are making a mistake. Its really just an organizational tool offered by the language.

Re:Not unique to .NET (1)

KrispyKringle (672903) | more than 11 years ago | (#6008055)

If my understanding is correct, though, C# and .NET is supposed to be using some sort of VM or other (I could be way off here, or at least, someone will say I'm way off), as I remember it is supposed to run in a "sandbox." This would be fairly similar to the reason Java isn't vulnerable to this, that is, Java is compiled into bytecode but run in a VM, making it semi-interpreted. The fact that this can happen in .NET, which should be able to do the same safety measures as Java, is somewhat discouraging.

On the other hand, someone posted above that this was only possible in local applications running with the highest security levels. I don't know enough about .NET (I know virtually nothing about it, in fact) to say if this is the case, but it seems reasonable and somewhat reassuring.

Security (5, Informative)

cooldev (204270) | more than 11 years ago | (#6007979)

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.

and the point being? (0)

Anonymous Coward | more than 11 years ago | (#6007989)

Jeez, we're suppose to do what now, run and scream in terror? Bitch Microsoft?

I would like to understand, because I just don't see what's the problem here. I understand the use for private class members, and how it's a Good Thing for overall code stability, but to claim that this is some kind of security issue is simply misleading. Its not like the idea is new: Python also have a system of "yea, they're private but you can always call them if you really really want to" class members, and I don't see anybody making a scene about it.

I mean, if the security of your application is assured by denying access to private members, you've got way more serious design problems, and the language you use should be the least of your worries.

Am I missing something here?

Re:and the point being? (1)

mydigitalself (472203) | more than 11 years ago | (#6008060)

i pretty much agree with your sentiment. VS.NET doesn't encourage one to do this; the fact that somebody had to write a 50 page ebook on how to do it shows that it is clearly not encouraged.

similarly, i think that if you are going through these steps you are well aware of what you are doing and would understand the pitfalls of utilising other private member functions.

of course the fact does remain that its possible to do at all which, at first glance, i thought was scary. but other, more hardcore coders in the /. community have pointed out that this is achievable in many other open source languages as well.

anyway, just another excuse to do some m$ bashing i guess...

Security by obscurity... (1)

vierja (632250) | more than 11 years ago | (#6007995)

How many times we'll have to see this again... security by obscurity is not the way to go. Doesn't seem strange of Microsoft though...

Sweet! (2, Funny)

mschoolbus (627182) | more than 11 years ago | (#6007996)

I can finally call the BSOD member! uh.. nevermind...

Stop the anti-MS BS all the damned time (4, Informative)

fzammett (255288) | more than 11 years ago | (#6008015)

This is NOT a security issue... A number of other languages allow this, most notably Java.

Making a member private is NOT a security mechanism. It is a DESIGN mechanism. The point is to enforce a public interface to a class, not absolutely securing internal data or functions from external callers. Yes, they are similar and in some cases pretty damn close to synonymous, but they are still different goals.

This isn't a flaw in .NET, unless MS says that in fact they want to doubly use the private mechanism as a security measure. No other language that I'm aware of does this, you could even argue that it would be a plus in .NET's favor.

If you want to say this design pattern is stupid, by all means do so. I would tend to agree. But if you want to use this as an opportunity to simply bash MS and .NET, your simply ignorant or just want to toss mud.

Not a security issue (3, Informative)

Jeffrey Baker (6191) | more than 11 years ago | (#6008056)

People seem to be making this into a big security issue, but I don't see it that way at all. Private declarations shouldn't be used to provide security. You can assume that if you put a piece of code or data into a computer, other programs may be able to access the storage thereof. No big surprise there. This is true of introspection techniques, self-modifying code, and related styles of programming.

The declaration of something as private, or not exported, or static, or the analog provided by your favorite programming language is a tool for the programmer, not the computer. It tells the programmer that this interface or piece of data is not be used by anyone but the author. It means that the interface or data could change at any time, and any use of it is a hack in the classic sense. It will probably work, in appearance or in actuality, but it will break unpredictably.

Private declarations may be enforced with varying vigor by compilers or runtimes, but usually there is a way around such enforcements. At the extreme, you can usually just directly access the memory in question, if the kernel allows that (or even if it doesn't, in the case of a super-user).

Sigh (4, Interesting)

kahei (466208) | more than 11 years ago | (#6008063)

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?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...