Is there real pointer semanics in .NET? I thought, that it's converted to references.
Hm... reading:
Yours, VB.
Is it possible to verify code which contains pointers?
Yours, VB.
Why should I assume something about people I don't know? I'm just interested in facts.
No, why should I?
Look, I know Sebastian from de.comp.security.* for some years now. He usually has some good points, while he sometimes tends to overwind and unfortunately, his postings often are offensive. Obviously, he hit you with his offending :-/
Other people don't like my way to discuss - I like it clear and well-defined. And I cannot refrain from being sarcastic from time to time. Some people feel my way to discuss being caustic.
Yours, VB.
You should differ between 'safe' and 'unsafe' code. And there's the problem: Some 'safe' code uses pointers as well (at most for byte arrays and String conversions), in a unverifiable way. Just add 3 additional bytes and you don't know whether is still points into the byte array, or the FilePermission object that is part of the object as well.
Microsoft could have got this absolutely right if none of the 'safe' code operations would have pointer semantics, and changed the verification process accordingly. Then every verifiable code would be free of pointer semantics and the verification process would be exact (even though, we know, they additionally relaxed it a bit).
Maybe you want to rethink it? If no 'safe' code contained any pointer semantics (like in Java), then any code passing the verification process would be correct.
There's also a chance that in conjunction with stack tracing/verification one can get some pointer semantics verifiable.
It does.
The better question is, what kind of problems the security model is supposed to address. Obviously both .NET and Java address collaborative security, which means that trusted code could drop its privileges to defend against being tricked (f.e. remote requests on file access), and they won't be able to reaqquire the privileges. Java also gives a sandbox, which means that even malicious code with no privileges should be able to aqquire privileges without any explicit consent. I'm not sure whether .NET is really marketed as such a sandbox, there are only many implicit claims (f.e. security zones and origin policies). But well, MSIE is marketed as a secure webbrowser. :-)
As far as we know, .NET is not a sandbox and will never be until totally overthrowing the IL and a big part of the CLR. Too bad that it's already standardized.
If you've got some limitations at the language level: partitially!
I guess the article that Mr. Arnold referenced pointed that out how it's done on .NET, or better said, how it should be done, if the language would be limited enough.
I assume that the OP has taken a little time to browse through previous threads in this group already. Therefore, the OP will know that the topic itself has been repeatedly discussed and the OP will also have a very good idea about what kind of answers to expect. That's normally a good basis for deciding whether you want to make a post asking for suggestions.
And what forums would you suggest being better for comprehensible advice, BTW? - The vendors own forums? - or personal firewall user forums?
As long as it normally comes with arguments that you are free to accept or dismiss, I don't really see the problem.
BTW, on usenet you will always get a lot of different opinions. And "ZoneAlarm works great" is'nt really a better argument than "Stay with the windows firewall", is it?
I think you should leave that to the OP to decide.
When I have asked questions on usenet myself, the best advice has not always nescessarily been advice specificly addressing my question.
require such as a
How do you determine if something requires a "respectful" answer? (whatever that means in the first place) - The OP's own comment about "Norton is out. You can't pay me to use Norton" - even though I agree whole-heartedly - is not exactly "respectful" either, is it?
This is the internet. Learn to deal with it.
require such as a
Ask Liam.I have no intention ,or inclination to waste my time with you. "This is the internet. Learn to deal with it"?....your having a laugh ;) me
Talking about lunatics...whatever happened to Tracker?....did she make a million selling her "security hardback" (or was it softback) i wanted to make her csf mascot once....Yes this newsgroup always seem to bring out the best in folks ;) me
She did just disappear off the Internet all of a sudden didn't she.
Well, there is another lunatic troll after me out of 24hours that's showed itself here recently with her same old tacts.
Nothing changes with that *clown* as she is loose and out of the asylum again, as a matter of fact, she never went. She kind of reminds me of old Walter. Do you remember him? :)
Her appearance here is due to me trashing her butt a little bit. ;-)
She likes to run incognito the non-slippery varmint. I can spot her a mile away. She can't change her spots. She is obsessed with me.
Nothing changes on the Internet. It's the same old thing. It's just different players.
You have a good day Bass.
Duane :)
helping folks here.You take care. me
No. We're talking about a VM, where byte code already must be safe.
I'm missing a PoC for an attack. Maybe, next time I've time, I will hack one, if you couldn't offer one.
No. I never will trust into "this is safe code" "verifying".
Yours, VB.
No.
Yes and no. Of course, no pointers means no security problem with memory. With the exception of byte code manipulation. This must not be possible then. Say: the chose of compilers must be enforced. How should this ever work?
OMN!
No. There is no process model in the VMs. So we need memory protection in other ways. Pointers require another memory protection implementation. If there is none, and there only is some "this is harmless code" or "we're verifying conservative" nonsense, then .NET security is b0rken by design.
I really cannot believe, that Microsoft make such a mistake. I will get into it ASAP. If you're right here, .NET is the next generation of security desaster.
Yours, VB.
Huh? It's the bytecode that is verified.
And that's exactly the problem: The .NET CLR contains some pointer semantics, even for 'safe' code. Java doesn't.
However, it's a known problem with Java to prove that the Java bytecode isn't any more powerful than the language itself. Alternatives like Abstract Syntax Tables have been suggested.
Microsoft's compiler won't allow you to create such unsafe code that could possibly bypass verification, and it will flag the assembly accordingly.
That's why the security model works if it's about legitimate code trying to protect itself against being unintentially misused.
What about ActiveX and VBScript? Those were their first "alternatives" to Java.
Well, you can usually only use as an applet only from within IE, so it already is a desaster. :-)
Yes, of course. And it's impossible already in theory to get a working verification.
Yes. This is what I'm talking about.
An attacker is not forced to use such a compiler.
No.
ActiveX is an accident. .NET would be intentionally.
No.
Yours, VB.
Well, not even close. I think the methods of verification for the CLR bytecode (validity, type conformance, memory boundaries, stack frames, simulation and verification of critical stack manipulation) are pretty typical for a class of verifiable languages with particular usage of pointer semantics, but it seems like they didn't think it to the end - f.e. that the bytecode semantics need some well-defined restrictions as well. It's really just a bit further than being verifiable.
Of course, many of these verification restrictions haven't been implemented until .NET FX 2.0, and Java shows that you can get along quite well without any hassles with pointers at all.
And the security model isn't supposed to adress the scenario of you running the code of the attacker and working as a sandbox. At least Microsoft never claimed that, though they're making a lot of indirect hints.
What it is supposed to adress, and does so correctly, is to allow trusted code to protect itself against being tricked into misusing its own privileges. Just like a Webservice on a J2EE Application Server.
I guess that's why they included it in MSIE. :-)
Once again: I haven't seen any claims that remotely loadable applications with .NET would be any more secure than ActiveX, and that it would even be a sandbox like Java.
Actually the similarity to ActiveX is quite obvious: There's only a decision "run it or don't" supported by a certificate scheme, heavy usage of COM+, it's the code's choice to obey the rules and restrictions imposed by the object model...
MS doesn't own or control NET. The only proprietary element MS owns is VB.NET. The ECMA and ISO own and control .NET, which MS, Novel, Sun Micro Systems, Intel, HP, IBM and many other such entities sit on those boards and control what happens to .NET.
Apparently, you and Blab are the only ones seeing some kind of problem here with .NET, while the rest of the companies and their technical representatives on the committees are off in left field I guess. ;-)
Duane :)
Sebastian Gottschalk wrote: [.NET]
That does not matter. There are no processes. If there is no other memory protection, then this VM never will be secure.
How is memory protection done in IL VMs of .NET? I can find something like the b0rken concept of chosing which code will run:
Does anybody here know the answer to this question? Duane?
I hope you're wrong. Really.
Yes. Everything I'm reading in MSDN seems to approve this. OMN! Please give me back my hope, dear group, that this will not be the next security desaster!
Yours, VB.
Microsoft invented .NET. Or should we discuss this really?! *wonder*
Can you support, please? Can you tell me, how to have something like memory protection in .NET? How can we ensure, that code, which already is running, _cannot_ access memory which it must not access in the same VM?
Yours, VB.
Yes, I think it's relevant, because .NET is not proprietary to MS and others are looking at .NET and what's happerning with it.
I don't know man you make your own determinations.
Long
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.