jorgediz / xmlrpcnet

Automatically exported from code.google.com/p/xmlrpcnet
0 stars 0 forks source link

Prevent “Operation could destabilize the runtime" #18

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Email from Dan Terry:

Re: http://www.cookcomputing.com/blog/archives/000548.html

And: http://tech.groups.yahoo.com/group/XMLRPCNET/message/698 

I ran into the nasty “Operation could destabilize the runtime” issue this
evening when playing around with your library (client functionality only)
for the first time.  The issue is not related to the .NET 1.x version of
the library being loaded with into the .NET 2.0 runtime as earlier mentioned.

To reproduce the error, you simply need to make sure you are running with a
set of permissions that do not allow the library to SkipVerification.  To
do this and still be able to run the library, compile with the following
assembly attributes.

[assembly: FileIOPermission(SecurityAction.RequestMinimum,
AllLocalFiles=FileIOPermissionAccess.PathDiscovery)]

[assembly: ReflectionPermission(SecurityAction.RequestMinimum,
Unrestricted=true)]

[assembly: WebPermission(SecurityAction.RequestMinimum,
Connect=@"http://someurl")]

[assembly: PermissionSet(SecurityAction.RequestOptional, Unrestricted = false)]

I am new to CAS (using Open Source is actually the reason I am trying to
learn it – no offense J), so this is a pretty crude set at the moment. 
These are pretty close to the minimum your library requires to run
(client).  Restricting Urls is probably overkill.  Anyways, I arrived at
this set of attributes from incrementally debugging and adding required
permissions to your library.  See article
http://msdn2.microsoft.com/en-us/library/d17fa5e4(vs.71).aspx.

Now, create a proxy using XmlRpcProxyGen.Create<T> and try to invoke a
method (no use of async begin/end/etc) on the proxy.  At this point, the
runtime will attempt to verify the MSIL in the assembly you have
dynamically created.  You will get the “Operation could destabilize the
runtime” VerificationException.

To prove that this is the case compile with:

[assembly: SecurityPermission(SecurityAction.RequestMinimum,
SkipVerification=true)]

With this attribute, no verification = no exception.

An article that helped along the way
http://blogs.msdn.com/haibo_luo/archive/2006/10/31/always-peverify-il-code-of-yo
ur-dynamic-method.aspx.

So next, I used the XmlRpcProxyGen.CreateAssembly method to save a dynamic
assembly to disk.  Peverify reveals the following error:

[IL]: Error: [c:\someassembly.dll : someinterface::somemethod][offset
0x00000012][found ref 'System.Reflection.MethodBase'][expected ref
'System.Reflection.MethodInfo'] Unexpected type on the stack.

1 Error Verifying c:\someassembly.dll

Looking at XmlRpcProxyGen.cs you can see that lines 184-189 are suspect.

// call Invoke on base class

Type[] invokeTypes = new Type[] { typeof(MethodInfo), typeof(object[]) };

MethodInfo invokeMethod

  = typeof(XmlRpcClientProtocol).GetMethod("Invoke", invokeTypes);

ilgen.Emit(OpCodes.Ldarg_0);

ilgen.Emit(OpCodes.Call, typeof(MethodBase).GetMethod("GetCurrentMethod"));

I am a Reflection super newb so I may be completely off base; however, it
appears that the result of MethodBase.GetCurrentMethod (which returns a
MethodBase) is being later passed (not shown) as a MethodInfo without an
explicit cast in the MSIL (I took a brief look at the MSIL using ILDASM,
and I have also Reflected the class - Reflector shows an explicit cast that
the MSIL does not have).

Anyways… that is a lot for now.  Sorry for the poor grammar and style – its
very late here.  Hopefully this is plenty of information to make a fix.  I
believe that changing line 185 of XmlRpcProxyGen to have typeof(MethodBase)
instead of typeof(MethodInfo) will fix the problem (of course you would
have to change for all of the Async BuildMethods also).  I am wondering how
you can make the assumption that MethodBase returned from
MethodBase.GetCurrentMethod() can be cast to MethodInfo?  That is my final
question.

Original issue reported on code.google.com by ChasC...@gmail.com on 27 Mar 2008 at 10:22

GoogleCodeExporter commented 8 years ago
Fixed in revision 34.

Original comment by ChasC...@gmail.com on 2 Apr 2008 at 7:52

GoogleCodeExporter commented 8 years ago

Original comment by ChasC...@gmail.com on 2 Apr 2008 at 9:57