Re:Another poor API from MS
on
Hijacking .NET
·
· Score: 1
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.
They are not "tricks". It's a class called reflection that does and is doing exactly what it was designed to do. There is nothing broken except quite a few people who seem to be equating OOP encaps with security. Glad I am not one of those people.
Microsoft has always used undocumented little tricks like this.
Except that it's not undocumented. The fact that someone is charging 10 bucks for a tutorial on System.Reflection when all the docs are sitting on msdn.microsoft.com as plain as day strikes me as amusing.
Any class that has a private data member representing a file (file name, descriptor, whatever) can never be sure that that value hasn't changed out from under it. Therefore, if the sandbox wants to restrict file access, it can't trust the member data it contains to tell it what files are accessible.
The CLR "sandbox" doesn't control access to files. The operating system does based on the privelege of the user running the.NET application.
Ditto for network connections.
Oh, and there is no private data in java, either. It's a little harder to inspect, but it surely isn't private:)
So I am writing code that is calling a DLL that has some.NET code in and I find the magic isAuthenticated private variable and use my code to jiggle it to true and viola I have just violated some (shitty) security that some developer implemented (poorly) and this is somehow the frameworks fault?
Sure, it may be possible to break user written security schemes via reflection. But then I could have also just dumped the exe/dll out to IL and made modifications to the code and re-assembled it. So if the user is using this sort of (crap) security it's going to get broken with or without.
Try harder. Try to show me how this lets someone "root" a box, or write to a file in a directory that the user doesn't have access to. Something.
The simple fact is that the CLR does not use ecapsulation as a security mechanism. It's a coding construct and that's all it is and all it was meant to be.
Sorry, but no. This is true for C++, but it's not supposed to be true here. As others have already pointed out,.NET and the CLI are supposed to act like the JVM, allowing "sandboxing" of untrusted code.
And how does this break 'sandboxing', exactly? Can you show me an example of how using this *documented feature of the common runtime library* allows a program to break out of it's sandbox and perform something (for which these is security) that would have not have been allowed by the security system otherwise?
And don't try to use "access a private member" as you answer, either. That's not something the runtime secures. It's simply an OOP construct.
The reason getting access to privates in C# is a big deal is that it is a language that is supposed to be protected by a runtime
Not really. The language is not supposed to be protected. But other processes are. And they are. What this feature (and it IS a feature, more on that later) does is lets you break OOP encapsulation. It certainly gives you the power to access fields and members that the original author did not mean for you to access. It lets you write code that depends on those items not changing. And when they do you're certainly going buy yourself an exception. But this exception is not going to bring down your system. Is using this facility willy nilly bound to make your code less stable? Of course. But under the CLR unstable does not equate to insecure like it does in a language like C++. Because the CLR is still protecting memory and Reflection is not going to let you get around that.
This runtime should protect the integrity of the code at all times, thus eliminating a certain amount of security issues.
And it does. When it reaches code that is doing things that the user does not have the security to do exceptions are thrown. Breaking encapsualtion does not break that.
Not doing this is a huge issue, and something that those programming for.NET should be aware of.
We are aware of it. At least any of us who are doing things above and beyond "Hello World". Reflection is explained in most books that are above a "For Dummies" level. Most of us never use those features of reflection, but most of us at least know they exist.
I'd seriously suggest that you get a bit more educated about the CLR before you do a whole lot more bashing.
Sorry, but no. It's a documented feature. The reflection classes are documented to specifically allow you to access private fields and members of a class. There is no security breach here, sorry:/
And if you DO consider it a security issue, then nearly every other programming language suffers from it. See other articles in this thread for examples on accessing private members in C++.
Apparently, the decision to make the Resident Evil series a GameCube exclusive isn't working out as well as they'd hoped, and they're moving that series back to cross-platform status, for instance.
I think the reason they didn't sell well is that they are remakes. Older games already had them on the PS1 and newer gamers seem to rise up in open revolt at the crap control scheme.
So Microsoft comes out with "Managed C++", an uglier version of many of the same ideas, and rams it down people's throats.
Maybe we have a different idea of "rammed down people's throats". Microsoft came out with "Managed C++". At the same time they updated their "Unmanaged" C++ compiler. The Unmanaged C++ compiler has certainly not been given step-child status. So where is the ramming?
Future worm writers are being given a homogenous, enormous and vulnerable target.
How will the target be any larger than it is now? As it stand there are lots of users spread out along lots of different windows versions with lots of different patch levels. And this is going to continue. Do you think microsoft will quit introducing new versions of the OS? If anything they'll be able to introduce them faster (see below for reasons).
Legacy stuff sucks. It sucks to support, and it sucks to write drivers for. What MS is proposing isn't going to fix any of that. It's just going to make it cheaper for MS, more attractive to virus writers, and worse for consumers.
Um, when you control the hardware and the software you can do crazy things like get rid of serial ports, PS/2 ports, etc. You can shed lots of baggage on a whim. And this makes it easier to code. Makes your code less prone to failure. Makes it easier to meet/beat schedules.
Plus, with the tape recorder I could play back the whole lecture in 30mins with the speed-dial turned all the way up.
This reminds me of an article I read ages ago that said that listening to sped up audio actually helped comprehension and retention of the subejct matter. Can't find a thing about it via google, though.
I'm quite sure there is life besides our own somewhere out in the universe. I have no proof, but the mind bogglingly large number of stars convince me that it must be so. *shrug*
Pride in doing something novel. *shrug*. I won't disagree and say that their support isn't worthless (going by the transcriptions of your conversations), but damn man have a little common sense.
I can see doing this on a desktop where pulling the case cover off and inspecting a chipset is a simple thing, but on a laptop that you KNOW is going to have hardware that's going to be oddball. Sheesh.
You should have considered swallowing your little pride, booting into windows, grabbing a pencil and pad and letting bill gates tell you what sort of hardware was running. BEFORE you wiped the harddrive and tried to put linux on the thing.
Haven't you heard? Microsoft is bad. Mono is based on a Microsoft product. Therefore Mono must be a waiting devil that will eat your children and impregnate your pets.
Yeah yeah, mod it down baby.
Slashdot Mirror
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.
They are not "tricks". It's a class called reflection that does and is doing exactly what it was designed to do. There is nothing broken except quite a few people who seem to be equating OOP encaps with security. Glad I am not one of those people.
Microsoft has always used undocumented little tricks like this.
Except that it's not undocumented. The fact that someone is charging 10 bucks for a tutorial on System.Reflection when all the docs are sitting on msdn.microsoft.com as plain as day strikes me as amusing.
Any class that has a private data member representing a file (file name, descriptor, whatever) can never be sure that that value hasn't changed out from under it. Therefore, if the sandbox wants to restrict file access, it can't trust the member data it contains to tell it what files are accessible.
.NET application.
:)
The CLR "sandbox" doesn't control access to files. The operating system does based on the privelege of the user running the
Ditto for network connections.
Oh, and there is no private data in java, either. It's a little harder to inspect, but it surely isn't private
So I am writing code that is calling a DLL that has some .NET code in and I find the magic isAuthenticated private variable and use my code to jiggle it to true and viola I have just violated some (shitty) security that some developer implemented (poorly) and this is somehow the frameworks fault?
Sure, it may be possible to break user written security schemes via reflection. But then I could have also just dumped the exe/dll out to IL and made modifications to the code and re-assembled it. So if the user is using this sort of (crap) security it's going to get broken with or without.
Try harder. Try to show me how this lets someone "root" a box, or write to a file in a directory that the user doesn't have access to. Something.
The simple fact is that the CLR does not use ecapsulation as a security mechanism. It's a coding construct and that's all it is and all it was meant to be.
Sorry, but no. This is true for C++, but it's not supposed to be true here. As others have already pointed out, .NET and the CLI are supposed to act like the JVM, allowing "sandboxing" of untrusted code.
And how does this break 'sandboxing', exactly? Can you show me an example of how using this *documented feature of the common runtime library* allows a program to break out of it's sandbox and perform something (for which these is security) that would have not have been allowed by the security system otherwise?
And don't try to use "access a private member" as you answer, either. That's not something the runtime secures. It's simply an OOP construct.
The reason getting access to privates in C# is a big deal is that it is a language that is supposed to be protected by a runtime
.NET should be aware of.
Not really. The language is not supposed to be protected. But other processes are. And they are. What this feature (and it IS a feature, more on that later) does is lets you break OOP encapsulation. It certainly gives you the power to access fields and members that the original author did not mean for you to access. It lets you write code that depends on those items not changing. And when they do you're certainly going buy yourself an exception. But this exception is not going to bring down your system. Is using this facility willy nilly bound to make your code less stable? Of course. But under the CLR unstable does not equate to insecure like it does in a language like C++. Because the CLR is still protecting memory and Reflection is not going to let you get around that.
This runtime should protect the integrity of the code at all times, thus eliminating a certain amount of security issues.
And it does. When it reaches code that is doing things that the user does not have the security to do exceptions are thrown. Breaking encapsualtion does not break that. Not doing this is a huge issue, and something that those programming for
We are aware of it. At least any of us who are doing things above and beyond "Hello World". Reflection is explained in most books that are above a "For Dummies" level. Most of us never use those features of reflection, but most of us at least know they exist.
I'd seriously suggest that you get a bit more educated about the CLR before you do a whole lot more bashing.
Sorry, but no. It's a documented feature. The reflection classes are documented to specifically allow you to access private fields and members of a class. There is no security breach here, sorry :/
And if you DO consider it a security issue, then nearly every other programming language suffers from it. See other articles in this thread for examples on accessing private members in C++.
for example, I have perl script that continously goes to random web sites and pretends to browse web pages 24/7.
Paranoid much? Trust me, no one cares what you're doing.
Is this supposed to be some sort of a joke? :P
I called a limey broad a slag and you'd have thought I called her a cunt.
Shit's just different from place to place, ya know?
..Thought C# has some nice innovations, one of my big problems with it is that so many of its new 'features' are so much syntactic sugar.
A few examples, please?
That'd be great if .Not had an open specification. It doesn't.
What exactly do you mean by "open specification"?
there wasn't really recorded music at the time
Sure there was.
Apparently, the decision to make the Resident Evil series a GameCube exclusive isn't working out as well as they'd hoped, and they're moving that series back to cross-platform status, for instance.
I think the reason they didn't sell well is that they are remakes. Older games already had them on the PS1 and newer gamers seem to rise up in open revolt at the crap control scheme.
So Microsoft comes out with "Managed C++", an uglier version of many of the same ideas, and rams it down people's throats.
Maybe we have a different idea of "rammed down people's throats". Microsoft came out with "Managed C++". At the same time they updated their "Unmanaged" C++ compiler. The Unmanaged C++ compiler has certainly not been given step-child status. So where is the ramming?
Future worm writers are being given a homogenous, enormous and vulnerable target.
How will the target be any larger than it is now? As it stand there are lots of users spread out along lots of different windows versions with lots of different patch levels. And this is going to continue. Do you think microsoft will quit introducing new versions of the OS? If anything they'll be able to introduce them faster (see below for reasons).
Legacy stuff sucks. It sucks to support, and it sucks to write drivers for. What MS is proposing isn't going to fix any of that. It's just going to make it cheaper for MS, more attractive to virus writers, and worse for consumers.
Um, when you control the hardware and the software you can do crazy things like get rid of serial ports, PS/2 ports, etc. You can shed lots of baggage on a whim. And this makes it easier to code. Makes your code less prone to failure. Makes it easier to meet/beat schedules.
Heh, no.
:)
NR/2 Was pertty horrible, didn't support message threading and had a number of other problems
OS/2 Still has the best GUI newsreader.
Plus, with the tape recorder I could play back the whole lecture in 30mins with the speed-dial turned all the way up.
This reminds me of an article I read ages ago that said that listening to sped up audio actually helped comprehension and retention of the subejct matter. Can't find a thing about it via google, though.
I'm quite sure there is life besides our own somewhere out in the universe. I have no proof, but the mind bogglingly large number of stars convince me that it must be so. *shrug*
Actually, I just turned to my left and asked the russian lady who sits next to me about that. She seems to remeber these bread lines before AND after.
Pride in doing something novel. *shrug*. I won't disagree and say that their support isn't worthless (going by the transcriptions of your conversations), but damn man have a little common sense.
I can see doing this on a desktop where pulling the case cover off and inspecting a chipset is a simple thing, but on a laptop that you KNOW is going to have hardware that's going to be oddball. Sheesh.
You should have considered swallowing your little pride, booting into windows, grabbing a pencil and pad and letting bill gates tell you what sort of hardware was running. BEFORE you wiped the harddrive and tried to put linux on the thing.
Slander AND libel?
S-s-s-slander is Sp-sp-sp-spoken.
L-l-l-libel is L-l-literary.
Haven't you heard? Microsoft is bad. Mono is based on a Microsoft product. Therefore Mono must be a waiting devil that will eat your children and impregnate your pets. Yeah yeah, mod it down baby.