Implications of using typeFilterLevel=Full after strong naming assemblies

[Stu Carter]

Hi,

Env: Windows 2003, VS 2003, .Net 1.1

We just started strong naming our assemblies and ran into a .Net Security
Exception when remoting between ASP.Net and our Windows service. The
remoting call that failed with this exception returns an array of DataRows
(from a strongly typed DataSet) from the service to ASP.Net. All our
assemblies (apart from Microsft.Security.SSPI sink) are private.

The exception is:
Security Exception
Description: The application attempted to perform an operation not allowed
by the security policy. To grant this application the required permission
please contact your system administrator or change the application's trust
level in the configuration file.

Exception Details: System.Security.SecurityException: Request failed.

Source Error:
An unhandled exception was generated during the execution of the
current web request. Information regarding the origin and location of the
exception can be identified using the exception stack trace below.
Stack Trace:
[SecurityException: Request failed.]

Anyway, we solved this by setting the 'typeFilterLevel' to 'Full' in our
server config file:
<formatter ref="binary" typeFilterLevel="Full" />

After some research I found that people have mentioned security and possible
performance issues with setting this level to 'Full', so I've a few
questions on the implications of opening this up:

1) Why does strong naming a private assembly cause this problem, when an
unnamed private assembly works fine?

2) I doubt it, but are there any performance issues?

3) The security issues appear to be from spoofing and code injection:
http://blogs.msdn.com/manishg/archive/2004/10/27/248841.aspx

Can you please confirm that these security issues existed before we strong
named our assemblies and had to set the typeFilterLevel to full?

This doesn't mean we'll ignore the vulnerabilities (we already authenticate
callers), but we're just trying to understand the impact of this change.

Thanks very much,
Stuart

PS. This is reposted from 'microsoft.public.dotnet.security' as I didn't
realise that one wasn't a managed group.

 

[Peter Huang [MSFT]]

Hi

This issue is documened at
http://www.gotdotnet.com/team/changeinfo/Backwards1.0to1.1/default.aspx#0000
0153 (Secure Serialization in .NET Remoting - ackwards Breaking Changes
from version 1.0 to 1.1)

A level of security has been added to Serialization. Specifically, there
are now two levels of serialization security: Low (Default) and Full.

Low Level Security:
? Remoting infrastructure objects. These are the types needed to make
remoting work at a basic level.
? Primitive types, and reference and value types that are composed of
primitive types.
? Reference and value types that are marked with the SerializableAttribute
attribute but do not implement the ISerializable interface.
? System-provided types that implement ISerializable with a reduced
permission set.

? Custom types that implement ISerializable.
? Types that implement the ILease interface.
? ObjRef objects used for activation (to support client-activated objects).

Full Level Security:
? ObjRef objects passed as parameters.
? Objects that implement the ISponsor interface.
? Objects that are inserted between the proxy and client pipeline by the
IContributeEnvoySink interface.

MORE INFORMATION:

In version 1.1 of the .Net Framework, a new security feature was added to
the .Net Remoting infrastructure called Type Filtering. This feature, which
is enabled by default, limits the type of objects that may be marshaled by
a Remoting client to a Remoting server. Type Filtering effectively
prohibits the server from deserializing instances of CLR types that may
serve as vectors of attack. This feature is part of Microsoft¡¯s commitment
to be secure by default.
The following outlines several of the threats that are mitigated by use of
this feature (we are not going to give out details about how to exploit
these threats), specifically when typeFilterLevel is set to Low:

Exposing a Remoting server with a method or member that takes a delegate.
Threat: Delegates may be used to invoke methods on other types that have
the same signature

Exposing a Remoting server with a method or member that takes a
MarshalByRefObject type. Threat: The serialized form of a
MarshalByRefObject contains a mutable URL

Exposing a Remoting server with a method or member that takes an
ISerializable type.
Threat: Deserialization of an ISerializable type causes the Remoting
infrastructure to run the type¡¯s code.

Exposing a Remoting server with a method or member that takes an type found
in the GAC on the server machine in an assembly without APTCA
Threat: Types in the GAC are well known to anyone with the .Net Framework
installed.

Exposing a Remoting server that enables remote clients to register sponsors
Threat: There is no limit on the number of sponsors that can be registered.

See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconautomaticdeserializationinnetremoting.asp for more info.

So I think strongname is not the cause of the problem. It should caused by
what you are marshalling via remoting.

From above, we know the Full level need to be enabled when we want to pass
following objects.
Full Level Security:
? ObjRef objects passed as parameters.
? Objects that implement the ISponsor interface.
? Objects that are inserted between the proxy and client pipeline by the
IContributeEnvoySink interface.

I think the Full Level will not cause much performance hit, but as the
secenario listed above, the Remoting mechanism needs to do more job which
may have a little side effect.

Since you will authenticate the remoting call, so I think the Full level
will not cause the security concern in your scenario.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Stu Carter]

Hi Peter,

Thanks for the reply.

See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconautomaticdeserializationinnetremoting.asp for more info.

So I think strongname is not the cause of the problem. It should caused by
what you are marshalling via remoting.

I think Strong naming must be the issue since the only change was to strong
name all our assemblies (private, not in the GAC).

So the remoting object, method, parameters and callee remained identical.
We've been running against the 1.1 framework for a long time now and have
didn't come across this problem until we strong named, so I doubt it is
caused by the type of object being marshalled.

Regards,
Stu

 

[Peter Huang [MSFT]]

Hi

I am sorry if I have any confusion.
Based on my further research, this problem may also be caused when Custom
types that have strong names and live in an assembly that is not marked
with the AllowPartiallyTrustedCallersAttribute attribute.

BTW, set typeFilterLevel to FullTrust is also an workaround).

For how to set AllowPartiallyTrustedCallersAttribute, take a look at the
link below.
PRB: Strong Named User Controls Do Not render in Internet Explorer
http://support.microsoft.com/Default.aspx?id=814669

You may try to marked the strong name assembly with
AllowPartiallyTrustedCallersAttribute see if that works for you.

Hope this helps.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Peter Huang [MSFT]]

Hi

In addition, from the document below, it think set FullTrust is also a good
alternative.
CAUTION .NET remoting does not do authentication or encryption by
default. Therefore, it is recommended that you take all necessary steps to
make certain of the identity of clients or servers before interacting with
them remotely. Because .NET remoting applications require FullTrust
permissions to execute, if a unauthorized client were granted access on
your server, the client could execute code as though it were fully trusted.
Always authenticate your endpoints and encrypt the communication streams,
either by hosting your remoted types in Internet Information Services (IIS)
or by building a custom channel sink pair to do this work.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconremotingexamplecallcontext.asp

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Stu Carter]

That makes sense, our assemblies were not marked with the trust level
attribute.

Thanks for your help,
Stuart

 

[Peter Huang [MSFT]]

Hi

Thanks for your feedback.
If you still have any concern, please feel free to post here.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.