Hi Kevin
Well there is some byte coding verification. For example if you manipulate MSIL so that you create calls to private members (something that you can't compile with VS.NET) you will get a runtime error saying that you tried to access a private member. So in this case there is some verification.Indeed this is somewhat surprising that there is no byte-code verification in place, especially for strong typing, since when you think about it, this is not too different than the "unmanaged" code case. What I found surprising was how little verification was done by the CLR when verification is disabled, see for example these issues:
Apart from a basic problem which is "You cannot trust Full Trust code EVEN if it doesn't make ANY direct unmanaged call or reflection" there is a much bigger one. When (not if) Applications start to be developed so that they run in secure Partially Trusted environments,I think that the developers will find that they code will suffer from an immediate performance hit due to the fact that Verification is now being done on their code (again for the Microsofties that are reading this (if any), can you post some data related to the performance impact of the current CLR Verification process? thanks) yes, although I still think that we should fight for the words "Managed Code" to include verificationApparently the whole "managed" versus "unmanaged" code only has to do with whether or not garbage collection is attempted. I am not a Java expert, but I think that the Java Verifier is NOT used on Apps that are executed with the Security Manager disabled (which I believe is the default setting) or are loaded from a local disk (see "... applets loaded via the file system are not passed through the byte code verifier" in http://java.sun.com/sfaq/)However, the real question is "is this true for ALL managed code or only managed code in the .NET Framework"? Yes, and note that I strongly defend that: "All local code must NOT be given Full Trust by default" (at the moment it is)Of course if software quality improvement does not take place in these companies, their signing would be somewhat vacuous. Butit would be better than nothing, since at least all such code would not be fully trusted by default. Dinis PS: For the Microsofties that are reading this (if any) .... sorry for the irony and I hope I am not offending anyone, but.... WHEN are you going to join this conversion? (i.e. reply to this posts) I can only see 4 reasons for your silence: a) you are not reading these emails, b) you don't care about these issues, c) you don't want to talk about them or d) you don't know what to say. Can you please engage and publicly participate in this conversation ... Thanks |
_______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
