Re: StrongNameIdentityPermission LinkDemand versus internal

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Nicole Calinoiu (calinoiu)
Date: 10/29/04 

Date: Fri, 29 Oct 2004 08:27:37 -0400

Neither limited accessibility (e.g.: internal modifier) nor SNIP provide any
serious deterrent to a determined and/or priviledged attacker. That said,
they do have other benefits, and not all code needs to be protected against
all possible threats, so you'll need to make some decisions about what's
worth implementing.

Low accessibility helps you constrain even your own use of your code. This
has multiple benefits, such as reducing your testing requirements, so you'll
probably want to restrict visibility as much as possible/reasonable
irrespective of whether it provides true security benefits. However, it
remains important to recognize that you can't count on low accessibilty to
enforce security.

SNIP is essentially just a mechanism for declaring access by only "friends
and family" assemblies, essentially attempting to enforce an accessibility
level that isn't available in current production versions of the .NET
Framework. It is not a reasonable substitute for a robust licensing scheme
since it is too easily bypassed.

If you're concerned about potential breach of your accessibility and/or SNIP
protections, you essentially have only a few options:

1. Obfuscate your assemblies, thereby making it more difficult to determine
what any given piece actually does. If you're lucky, this may push the
effort required to use your code past the level required to try to reproduce
the same functionality from scratch, thereby making your code an
unattractive target for at least some types of attacks.

2. Make attempted breach of the protections an offense under any relevant
license (for ISV) or employment contract (for internal applications). Since
you're unlikely to discover any breaches, this isn't a great protection, but
at least attackers can't say they weren't forewarned, and it might be enough
to discourage at least a few. Also, you should keep in mind that a
developer may not realize that they are circumventing SNIP if CAS has
already been disabled on their machine. (Coding against low accessibility
members is always a conscious decision since it requires use of reflection.)

3. If you can move "sensitive" code onto a machine that is at less risk, do
so.

4. Use a licensing scheme instead of SNIP and in addition to low
accessibility in order to restrict callers to your code. This is a lot of
work, can affect performance, and won't help restrict access to private
member variables via reflection in all scenarios. Its only real benefit is
that it will likely be harder to circumvent than SNIP.

5. Check that CAS is enabled and callers are fully strongly signed (as
opposed to delay signed). Same cons as licensing. Just makes it more
difficult to bypass SNIP protections.

1-3 are almost always worth implementing. I wouldn't recommend 4 or 5
except for truly sensitive methods and, even then, the implementation
details should probably be bundled into a single "is it OK to run?" method
that can be easily changed.

"Kevin Burton" <KevinBurton@discussions.microsoft.com> wrote in message
news:B3892C6A-39A6-40F6-9941-CC5AFC73D833@microsoft.com...
> So in the end SNIP is just annoying the attacker not really providing any
> protection. Right?
>
> "Nicole Calinoiu" wrote:
>
>> Sorry, but the calling code does not need to be run in an admin user
>> context
>> to bypass SNIP checks. In addition, there are plenty of scenarios in
>> which
>> a machine administrator may be considered potentially malicious wrt any
>> given piece of code. For example, an ISV may consider its clients to be
>> potential abusers of libraries that the clients have not paid to use
>> outside
>> the applications with which they are packaged. Similar scenarios can
>> also
>> be encountered within a single enterprise where, for example, a satellite
>> location might attempt to misuse a centrally distributed application.
>> The
>> "attackers" in such cases rarely considers that their actions are
>> malicious,
>> but the software provider may have a very different opinion.
>>
>>
>>
>> "Richard Blewett [DevelopMentor]" <richardb@develop.com> wrote in message
>> news:uaB6U%23SvEHA.4044@TK2MSFTNGP15.phx.gbl...
>> > Well only if the malicious attempt is on a machine under the control of
>> > the attacker. If it happens to be happening on your machine that a
>> > malicious component that happens to be running with full trust is
>> > deployed
>> > then no - it will not be able to bypass StrongNameIdentityPermission -
>> > unless the user running the malicious software is an admin in which
>> > case
>> > you have bigger problems
>> >
>> > Regards
>> >
>> > Richard Blewett - DevelopMentor
>> > http://staff.develop.com/richardb/weblog
>> >
>> > "Richard Blewett [DevelopMentor]" <richardb@develop.com> wrote in
>> > message
>> > news:OjAWrIRvEHA.1976@TK2MSFTNGP09.phx.gbl...
>> > > Internal methods can be called by any code running with fulltrust if
>> > > it
>> > > uses reflection, but code guarded by the
>> > > StrongNameIndentityPermission is alos guarded against reflection
>> > > based
>> > invocation.
>> >
>> > Only if the caller is well-behaved, and one could argue that an attempt
>> > to
>> > invoke internal or SNIP-protected members via reflection isn't
>> > particularly
>> > "nice". If the attempt is indeed malicious, SNIP won't be much
>> > protection
>> > at all since it's trivial to bypass by disabling CAS or skipping strong
>> > name
>> > verification.
>> >
>> >
>>
>>
>>

Relevant Pages