Forgot your password?
Programming Books Media Book Reviews IT Technology

Hijacking .NET 561

Posted by timothy
from the undocumented dept.
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
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 or through the author's web site.

This discussion has been archived. No new comments can be posted.

Hijacking .NET

Comments Filter:
  • Use a memory hex editor!
  • Conclusion (Score:4, Funny)

    by borgdows (599861) on Wednesday May 21, 2003 @12:04PM (#6007831)
    If you code in a Microsoft programming language, you can't even trust your own code!
  • by Dominic_Mazzoni (125164) * on Wednesday May 21, 2003 @12:04PM (#6007835) Homepage
    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...
    • by Anonymous Coward on Wednesday May 21, 2003 @12:19PM (#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.
      • by Anonymous Coward on Wednesday May 21, 2003 @12:30PM (#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.
        • by MORTAR_COMBAT! (589963) on Wednesday May 21, 2003 @01:29PM (#6008622)
          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.
      • by 1000StonedMonkeys (593519) on Wednesday May 21, 2003 @12:30PM (#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.
    • by Erv Walter (474) on Wednesday May 21, 2003 @12:28PM (#6008050) Homepage
      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.

    • by MickLinux (579158) on Wednesday May 21, 2003 @01:02PM (#6008379) Journal
      How could this ever be a problem?

      This implies that Microsoft, in switching to the .net development model, is going open source!

      Unofficially, of course. And people who implement it without being registered members of the Department of Homeland Security *could* be branded terrorist hijackers. But not to worry: only the evil ones will be. The others will accept automatic induction into the DHL framework.

    • by Anonymous Coward on Wednesday May 21, 2003 @02:09PM (#6009010)
      Sounds more like FUD from the *nix crowd.

      "The C++ access control mechanisms provide against accident - not against fraud. Any programming language that supports access to raw memory will leave data open to deliberate tampering..." The Annotated C++ Reference Manual, p 239.

      Encapsulation has NOTHING to do with security.
  • Posted on BugTraq (Score:3, Insightful)

    by oliverthered (187439) <oliverthered@hotm a i l . c om> on Wednesday May 21, 2003 @12:04PM (#6007838) Journal
    Isn't this a security bug, you think that you've hidden some code, but infact it isn't.

    • Re:Posted on BugTraq (Score:5, Informative)

      by Zeinfeld (263942) on Wednesday May 21, 2003 @12:40PM (#6008168) Homepage
      Isn't this a security bug, you think that you've hidden some code, but infact it isn't.

      No, not really, the private keyword is not meant to be a security mechanism. If you want to secure the data from program access you have to do it at the Kernel level.

      You can view this info in the debugger if you have the source for the class.

      The reason for making a method private is that the programmer does not undertake to preserve the API contract in future releases. So basically what this guy is doing is no different from those early MSDOS programs that bypassed the BIOS calling interface to call code directly. It was fast, you avoided the overhead of the context switch. However it also meant that the code was likely to fail on the next release of the PC.

  • By design? (Score:4, Insightful)

    by DrTentacle (469268) on Wednesday May 21, 2003 @12:05PM (#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...
  • So .Net is like C++? (Score:5, Interesting)

    by Ed Avis (5917) <> on Wednesday May 21, 2003 @12:06PM (#6007854) Homepage
    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?
    • by Erv Walter (474) on Wednesday May 21, 2003 @12:25PM (#6008026) Homepage
      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).
    • by patniemeyer (444913) * <> on Wednesday May 21, 2003 @12:27PM (#6008042) Homepage
      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.
    • In Java, the bytecode interpreter makes sure you can't access private class members.

      Unless you use one that doesn't :D

    • every presentation I've seen on .NET, C#, etc, have all had curious parallels to Java. What MS calls the CLR, Sun calls the JVM. What MS calls IDL, Sun calls bytecode. What MS calls Just-In-Time compiling, Sun calls HotSpot. All three pairings are the same basic ideas, and there are more of them.

      It's mostly a set of renamed technologies and concepts and MS is trying to push it as being totally new and previously unheard of. This is why Sun is pissed at MS for the whole Microsoft & Java issue, as .
  • by playtime222 (673645) on Wednesday May 21, 2003 @12:06PM (#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 :-/
  • C++ (Score:5, Informative)

    by Anonymous Coward on Wednesday May 21, 2003 @12:06PM (#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?
  • by dk.r*nger (460754) on Wednesday May 21, 2003 @12:07PM (#6007865)
    .. now we can just bypass this part of all Microsofts APIs:

    public method doStuff ( &task ) {

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

    private method actuallyDoStuff ( &task ) {


    • LOL! (Score:2, Insightful)

      by gazbo (517111)
      I get it! You're making reference to the fact that Windows blue-screens all the times, and implying it is coded that way deliberately - and using random number no less!


  • Unsure... (Score:4, Funny)

    by cruppel (603595) on Wednesday May 21, 2003 @12:08PM (#6007874) Homepage
    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.
  • by julesh (229690) on Wednesday May 21, 2003 @12:09PM (#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.
    • You beat me to the post I wanted to make. Now the most I can do is say "Mod this up!"
    • by Jerf (17166) on Wednesday May 21, 2003 @12:46PM (#6008227) Journal
      If the alternative to writing a quick ACL changer is multiple days of intense hacking, vs. a couple hours with the right pokes at private members, it will take a lot of internal interface changes before the amount of time spent tracking the internal API exceeds the time it would have taken to do it right the first time. Since the capability doesn't officially exist, your (a) point is meaningless (even this platform doesn't officially support it) if you can assert that everybody will use the same platform, and given we're talking .Net the odds that a an awful lot of .Net programs will run only on Microsoft's implementation anyhow is pretty high, and odds are (b) doesn't bother you because it may never happen (changing the internals like that also implies work for that developer, so it's not a bad bet they won't be in a hurry to change the internals for their own sake), and even if it doesn your probably still ahead.

      Encapsulation is not an absolute law, it's a risk that must be analysed like any other risk, and treating it like an absolute law will sometimes cause you to do sub-optimal things. I can't be 100% certain with the given information, but odds are that the choice to use internal private methods and data to do ACL manipulation are a good bet. Yes, you may lose, but implementing ACL manipulations yourself may lose too: If the ACL system changes, you have to track it yourself, while the odds are decent that the internal private members will automatically track the changes!

      Violating encapsulation is almost always bad, but that's a long way from "always bad".
  • by Asmodeus (10868) on Wednesday May 21, 2003 @12:09PM (#6007876)
    ..and is a very old technique.
    Java, Modula2, Lisp and smalltalk all allow

    • 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.
      • by 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.
      • Actually, Java does let you access private members through reflection. See java.lang.reflect.AccessibleObject [].

        Access can be controlled by a security manager; but the default for a java application is to allow access.

      • by egomaniac (105476) on Wednesday May 21, 2003 @12:53PM (#6008296) Homepage
        I love it when a flat-out wrong post gets modded to 5. You most fucking certainly can access private methods and fields from within Java.

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

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

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

        Go try it and see what happens.
  • Harumph (Score:5, Funny)

    by renehollan (138013) <rhollan&clearwire,net> on Wednesday May 21, 2003 @12:09PM (#6007877) Homepage Journal
    ...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.
  • by plcurechax (247883) on Wednesday May 21, 2003 @12:10PM (#6007887) Homepage
    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.

    • 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?
  • Private methods and (Score:5, Interesting)

    by yatest5 (455123) on Wednesday May 21, 2003 @12:10PM (#6007891) Homepage
    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.

    • by Ageless (10680) *
      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.
    • 'Standard users'? Does that include black hats? If you can't see that this is going to result in security holes then

      If you write your own compiler, as you say, then you need the source code. The fact that reflection gives you private member access at /runtime/ is clearly a problem.

    • How about this:

      // Javaish Pseudocode
      Movie mv=new Movie("myStolenMovie.avi");
      Runnable r={; };
      Method m=Introspection.getMethod(


  • by rossz (67331) <> on Wednesday May 21, 2003 @12:12PM (#6007912) Homepage Journal
    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.
  • by ptaff (165113) on Wednesday May 21, 2003 @12:14PM (#6007927) Homepage
    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.
  • by rc5-ray (224544) on Wednesday May 21, 2003 @12:14PM (#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 (Score:5, Informative)

    by Jabes (238775) on Wednesday May 21, 2003 @12:16PM (#6007952) Homepage
    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.
  • 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 featu
    • 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.


  • Security (Score:5, Informative)

    by cooldev (204270) on Wednesday May 21, 2003 @12:19PM (#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.

  • Sweet! (Score:3, Funny)

    by mschoolbus (627182) <> on Wednesday May 21, 2003 @12:22PM (#6007996)
    I can finally call the BSOD member! uh.. nevermind...
  • by fzammett (255288) on Wednesday May 21, 2003 @12:24PM (#6008015) Homepage
    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 (Score:4, Informative)

    by Jeffrey Baker (6191) on Wednesday May 21, 2003 @12:28PM (#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 (Score:5, Interesting)

    by kahei (466208) on Wednesday May 21, 2003 @12:29PM (#6008063) Homepage
    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?

  • by sethamin (533611) on Wednesday May 21, 2003 @12:31PM (#6008086)
    Oh for god's sakes people, this is just dumb. There's no real reason to take the performance hit and enforce this at run-time, because the protection of private member variables are there for your benefit. If you want to access undocumented variables that were never meant to be exposed, you're just asking for bugs and future incompatibility.

    Oh, and BTW, this has nothing to do with actual security. Relying on access level specifiers to protect sensitive data in memory is lunacy. The standard coding technique for dealing with things like passwords is to keep them around for as short a period of time as possible and then overwrite that memory afterwards with random bits. If you're storing them long term cleartext in memory then you've got bigger problems.

  • You'll be arrested for breaking the DMCA!! After all what is a private method? Code that has access protection!

    Besides, it's impolite to access stranger's privates if you weren't supposed to. If you're a 'friend', on the other hand, you presumably have access to all the privates of interest.
  • by CrazyJ020 (219799) on Wednesday May 21, 2003 @12:45PM (#6008216) Homepage
    Access modifiers (public, private, protected, internal, etc) are not designed for security! Code access security is intended for this purpose. With that said, you can still use code access security to prevent access to private members. Access to these members can be only done with reflection classes. The ReflectionPermission [] can be utilized to prevent code from accessing private members. From the document:
    CAUTION Because ReflectionPermission can provide access to private class members and metadata, it is recommended that ReflectionPermission not be granted to Internet code.
  • I'll use this to develop an application that launches any application, but has some UI hooks to bring up my application, which allows the user to walk through the private values of any application, etc. of classes.

    Oh wait........ That's already been done before.

    This is one of the main ways a debugger is written, right?

  • ...that just yesterday, we had a story with lots of comments on why computers still crash, in which one of the big culprits identified was using C and other HLLs that don't prevent the programmer from writing dangerous, unstable code.
  • I Love Short Books (Score:3, Insightful)

    by jetkust (596906) on Wednesday May 21, 2003 @12:50PM (#6008262)
    The whole text weighs in at just under 50 pages

    Good. I always hate books that are 1000 pages long just so the author can meet some type of quota. When in reality, the book is just full of extra fluff,and is much less useful as a learning tool because of it. To me, the best programming books are short. You can read them,learn, flip through them with your thumb, and each page has a lot of information. Once it gets too long it looses focus. And at this point, searching the internet and reading online help files starts seeming like a way better idea.
  • by kmahan (80459)
    Today Microsoft announced a major new feature in their .NET c# language. They have introduced a new keyword "really". To be used with the "private" keyword. By declaring something "really private" you can make sure that it will not be exported in a "blatantly obvious" manner.

    For added security you can use the "really" keyword multiple times to define your level of security. So "really private" is less secure then "really really private".

    Use of this keyword with other keywords such as "public" can have
  • by blair1q (305137) on Wednesday May 21, 2003 @12:59PM (#6008353) Journal
    OO coders have known this for a couple of decades, I think. (I forget; when was the "private member" invented?)

    Private members are a reliability measure, preventing subclasses from accessing members in dangerous ways, but certainly are not a security feature, because it's always possible to troll the object code.

    Oh, and BTW: The Internet is not secure, either. "Internet Security" is a security blanket, not a security door.
  • Security (Score:3, Interesting)

    by Get Behind the Mule (61986) on Wednesday May 21, 2003 @01:06PM (#6008431)
    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, 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, 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.
  • private != secure (Score:4, Insightful)

    by Vicegrip (82853) on Wednesday May 21, 2003 @01:14PM (#6008494) Journal
    The point of private declarations was never to provide security. It was to get users of said code to access an object through a defined interface.

    A program, as far as the OS is concerned, has legal access to its entire process address space. So, whilst it's true that the virtual machine might be able to control access to private members by code written to run on top the vm, that data is still in memory and can be accessed by anything that can bypass the memory manager in the virtual machine. A linked library written in your favorite natively-compiled language of choice fills this bill nicely.

    In this case, the .NET manager does not completely protect private members. This is, at most, only ugly from a language purity sense. Probably it's a function of running natively through a jit compiler instead of on-top a VM.

    Summary: these new virtual machines do a decent job of protecting private members, but nobody in their right mind should rely on the mechanism for security.
  • Flamebait alert (Score:5, Informative)

    by The Bungi (221687) <> on Wednesday May 21, 2003 @01:31PM (#6008653) Homepage
    OK, so let's review this "review":
    • Appleman's claim to fame are his efforts to bring advanced techniques to Visual Basic developers.
    • His approach was basically this: OK, this is how you dereference a pointer in VB. Get it? But wait - that's unsafe!. So click on this link to buy my SuperDuper Pointer Dereferencing Library for VB, priced to go at $99.
    • Appleman's "samples" were always flawed and biased, designed specifically to sell his ActiveX libraries and controls. He lost all credibility right after he published an essay on how to do multithreading from VB5, an essay that was also flawed in its premises and was also designed to sell his multithreading library. This "essay" was immediately slammed by the very people who wrote VB, including folks like Matt Curland.
    • So now this guy (who used to work for Desaware - surprised?) does a "review" of Appleman's essay on how to "hijack" .NET.
    • What Mr. Dan "The Wiz" Appleman is doing here is nothing more insecure than calling class members directly using a vtable in a C++ application. Member visibility in C# (and in any other language) is a OO feature, not a security one. I'm not going into a discussion of .NET app domain security - I'm sure anyone who is interested can head on over to MSDN and look by themselves. Suffice it to say that where it matters, you can't do this. And quite a few other things.
    • This "evil technique" can also be applied to C++ and it can also be applied to Java. Wow!
    • The only reason Slashdot posted this article is to reinforce the perception that .NET sucks and is "insecure".
    Witness the numerous clueless post on how "oh, I'm not surprised .NET is insecure" and "M$ is teh sux" and a few insightful ones debunking the very premise of this flamebait "story". A good number of "Hah! Java doesn't allow that" posts were duly bitchslapped below. But that doesn't matter in the end, because the premise itself is flawed. "Oh, look, I can access private members, I'm so 1337". I expected nothing more from Appleman, and I expected nothing more from the Slashdot "editors", who'll post anything that remotely looks like a problem with a Microsoft product. XML in Office anyone?

    Coming soon - a story entitled "m$ .nyet 'sploid", by "h^xx0r". Read more (40 characters in body).

  • by gburgyan (28359) on Wednesday May 21, 2003 @03:16PM (#6009676) Homepage

    Check the documentation on the ReflectionPermissionFlag Enumeration [] to see what's going on. By default, for code that you're running on your own machine, you can do anything that you want. You can modify the settings with the framework configuration applet, or with some command line programs.

    The end result is, you can turn this feature off.

    I'm tired of /. being used to sell sh!t in posts.

  • subtitled... (Score:3, Insightful)

    by Royster (16042) on Wednesday May 21, 2003 @04:51PM (#6010580) Homepage
    ...How to Write Code Guaranteed to Work Only with Microsoft's Implementatyion of .NET and Not Mono.
  • El Stupido... (Score:4, Insightful)

    by Lodragandraoidh (639696) on Wednesday May 21, 2003 @04:56PM (#6010620) Journal
    Seems like a bad thing [] to implement an interface to a non-documented API for mission essential code.

    The problem with this is that Microsloth can easily change their non-public interface without telling anyone and your code will break. Other than the lack of security implied by accessing things that are supposed to be secure, this interoperability issue will come back to haunt anyone who implements these 'tricks' IMHO.

    Don't put this in mission essential code, or you will recieve a phone call late one night by your operations staff for unknown have been warned.

Say "twenty-three-skiddoo" to logout.