Security Exception After Upgrading to 2.6.2

[Andy Sipe]

We recently upgraded to 2.6.2 from 2.6.1 and now a few of our top level integration tests are experiencing remoting security exceptions.

In particular we are having this exception thrown when attempting a request:

System.Runtime.Serialization.SerializationException : Because of security restrictions, the type System.Runtime.Remoting.ObjRef cannot be accessed.

2.6.1 no problem, 2.6.2 this exception -- no other chnages in the source.

Note that this is occurring in our tests not in the nunit framework directly.  

I suspect that something changed in the nunit executable configuration or build that changed the security setup. 

Does anyone have any suggestions as to what may have changed in nunit and if its configurable ?

Thanks -andy

[Simone Busoli]

Hi Andy, the only thing that I recall might have to do with security and serialization is a different handling of the test context, which now goes into the logical call context and therefore is allowed to cross thread and I assume other boundaries as well.

Do you have any additional details about the exception, like a stack trace?

--
You received this message because you are subscribed to the Google Groups "NUnit-Discuss" group.
To post to this group, send email to nunit-...@googlegroups.com.
To unsubscribe from this group, send email to nunit-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nunit-discuss?hl=en.

[Andy Sipe]

Simone,

I've included a full stack trace at the end of this message.  I'm not sure its going to help a whole lot as it occurs in our test code not in the nunit code.  Note that in every case the exception is raised when the response is deserialized and that the actual request works as expected (server gets hit and executes).   To me it looks like there is some new security restriction being applied at a somewhat high level that is overriding the defaults. 

I was able to work around the issue by setting the type filter and some other security settings in the code that configures the security surrounding remoting.   Fortunately we handle all of this outside of configuration files or I'm unsure it would have worked as changing configuration files seemed to have no impact.    Once I set the type filter to full everything worked as expected again.  

For our purposes this will likely work as we don't use remoting extensively.   That said there is like some change in 2.6.2 that may cause others problems as well.

Thanks -andy


at System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type type)
at System.Runtime.Serialization.Formatters.Binary.ObjectReader.ParseObject(ParseRecord pr)
at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Parse(ParseRecord pr)
at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryObjectWithMapTyped record)
at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryHeaderEnum binaryHeaderEnum)
at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
at System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String objectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel securityLevel)
at System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestHeaders, Stream requestStream, IMessage& responseMsg, ITransportHeaders& responseHeaders, Stream& responseStream)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
... snip application level frames ....

[Simone Busoli]

Hi Andy,

I think it's definitely related to the changes we did to the test context. 

Just to clarify, we recently implemented support for test methods marked with the async keyword in order to allow awaits in the test code, and it made it into 2.6.2. This means that the body of the test may execute on different threads and in order to provide a uniform view of the TestContext contents in the body of the tests we needed it to be able to flow the execution context across threads. As it turns out, this also enables it to flow across remoting boundaries, which should not happen as what we put in the test context is not supposed to be serializable, and in any case the remote application wouldn't have the assembly available anyway.

I'm still confused about why this is happening when you receive the response from your remote server, rather than when you make the call in the first place, but that's a good starting point nonetheless. We should probably find a way to prevent the test context from crossing appdomain boundaries, if there is one at all.

Simone

[Charlie Poole]

Hi Simone,

We could test this assumption by running a test that creates an
AppDomain and runs a method that tries to access the TestContext.

I'm wondering if the changes you made after we released would have
this behavior. If we think it may be fixed now, perhaps we should send
Andy a build he can try.

Charlie

[Simone Busoli]

Andy, is there perhaps a repro that you could submit?

[Andy Sipe]

Simone,

Unfortunately I can't provide the specific source at this time so I'll have to see if I can't pull together something small that shows the problem.   It should be fairly straight forward.   

Thanks -andy

--
Andy Sipe
Z Bar Technologies, LLC
an...@zbartech.net
919-272-2033 (cell)

[Ben New Yen]

I'd like to add that I'm also running into this problem.   I have a simple console app that utilizes a .net remoting service.  The test works in 2.6.1, but not 2.6.2 nunit-console.  When the tests are run via the nunit gui (2.6.2), the tests run fine.  When run through the nunit-console-x86, it fails.  I tried setting the /nothread to see if it made any impact but it still failed.   I also tried the domain/assembly loading options (separate, in process, etc.) to no avail.   Also tried normal 64bit nunit-console.exe and still failed.   For now, we'll have to switch back to 2.6.1.   Any other suggestion would be appreciated.

Here's stack trace:

C:\temp\ConsoleApplication1\ConsoleApplication1\bin\Release>c:\Devtoo
ls\NUnit-2.6.2\bin\nunit-console-x86.exe /nothread /framework:3.5 ConsoleApplica
tion1.exe
NUnit-Console version 2.6.2.12296
Copyright (C) 2002-2012 Charlie Poole.
Copyright (C) 2002-2004 James W. Newkirk, Michael C. Two, Alexei A. Vorontsov.
Copyright (C) 2000-2002 Philip Craig.
All Rights Reserved.

Runtime Environment -
   OS Version: Microsoft Windows NT 6.1.7601 Service Pack 1
  CLR Version: 2.0.50727.5472 ( Net 3.5 )

ProcessModel: Default    DomainUsage: Single
Execution Runtime: v3.5
.F
Tests run: 1, Errors: 1, Failures: 0, Inconclusive: 0, Time: 0.625276 seconds
  Not run: 0, Invalid: 0, Ignored: 0, Skipped: 0

Errors and Failures:
1) Test Error : ConsoleApplication1.TestMe.WriteReadDelete
   System.Runtime.Serialization.SerializationException : Because of security res

trictions, the type System.Runtime.Remoting.ObjRef cannot be accessed.

  ----> System.Security.SecurityException : Request failed.

Server stack trace:
   at System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(
Type type)
   at System.Runtime.Serialization.Formatters.Binary.ObjectReader.ParseObject(Pa
rseRecord pr)
   at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Parse(ParseRec
ord pr)
   at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWi
thMapTyped(BinaryObjectWithMapTyped record)
   at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWi
thMapTyped(BinaryHeaderEnum binaryHeaderEnum)
   at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
   at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(He

aderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAp
pDomain, IMethodCallMessage methodCallMessage)
   at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize
(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCr
ossAppDomain, IMethodCallMessage methodCallMessage)
   at System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessa
ge(String objectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel
 securityLevel)
   at System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(
IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders reques
tHeaders, Stream requestStream, IMessage& responseMsg, ITransportHeaders& respon
seHeaders, Stream& responseStream)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage req
Msg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgDa
ta, Int32 type)

   at FileDB3.IServicer.DeleteFile(String sDBName, String sKey)
   at FileDB3.FileDB.DeleteFile(String sDBName, String sKey)
   at ConsoleApplication1.TestMe.WriteReadDelete() in c:\temp\TestFileDB\Console
Application1\ConsoleApplication1\Module1.vb:line 23
--SecurityException
   at System.Runtime.Serialization.FormatterServices.nativeGetSafeUninitializedO
bject(RuntimeType type)
   at System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(
Type type)

[Charlie Poole]

Could you file a bug report on this and include your repro example?

Charlie

To unsubscribe from this group and stop receiving emails from it, send an email to nunit-discus...@googlegroups.com.

To post to this group, send email to nunit-...@googlegroups.com.

Visit this group at http://groups.google.com/group/nunit-discuss.
For more options, visit https://groups.google.com/groups/opt_out.