Re: Reason behind implicit FullTrust LinkDemand?

From: kv (kv_at_daimi[)
Date: 08/03/04 

Date: Tue, 3 Aug 2004 10:57:18 +0200

Thanks a lot; it does indeed shed some sight on the situation. I don't quite
follow you, though. What are the "drastic measures" in the 1.0 timeline you
refer to? The removal of permissions from the Internet Zone or the
introduction of APTCA?

The latter, I can't make sense of, so let me sum up how I read it:

By Beta2, the Handle Recycle attack is discovered. Microsoft doesn't have
time to protect the System* assemblies from this attack.

By 1.0, the framework is released with a large number of security holes in
it. The damage is minimized by not allowing code from the Internet to use
the framework, effectively blocking one of the most important features of
the framework (rich client, yada-yada).

By SP1, the security holes are patched.

So far so good. The holes are patched. Why do any more? Because the old 1.0
assemblies may still be in the GAC and are insecure? Why not just tell the
world that they are insecure and patch (i.e. remove) them, like Microsoft
does with all other security holes?

Anyway, SP1 introduces the "brilliant" (do you mean that, or are you being
sarcastic?) FullTrust LinkDemand. I can see how this retrofixes and
minimizes the damage done by the 1.0 release while allowing Internet code to
actually execute, but it also hurts all other code. Assemblies must now use
the APTCA to be useful in environments without FullTrust.

Why not use an *explicit* FullTrust LinkDemand on the 1.0 assemblies when
they were released (they were aware of the security issues) instead of
removing permissions from the Internet Zone? They must've had time to do
that. The knew the LinkDemand would be a fix (or the know now). They must've
really been in a hurry... I can probably understand that if they required a
fix that allowed the 1.0 assemblies to be remain, a lot of better, less
destructive fixes could not be used.

Do you see my counter argument about the effects of the FullTrust
LinkDemand?

You write about the Handle Recycle attack and mention that it's part of a
whole class of weaknesses and that "There are many other equally (or even
more) dangerous and equally (or even more) difficult to detect security
weaknesses that could be unknowingly introduced to the system by sharing
APTCA assemblies." Can you point me in the direction of info about other
attacks? My suspicion is that an assembly doesn't assert any permission,
none of these weaknesses are exposed. If, furthermore, the assembly doesn't
use unsafe and/or unmanaged code and doesn't implement Dispose or custom
finalizers, there would be even less trouble. I bet that covers about
ninety-nine-point-what?-eight? percent of code out there. All this code is
unnecessarily hurt by the implicit LinkDemand and should in principle just
add the APTCA. Am I wrong?

/kv

"Valery Pryamikov" <Valery@nospam.harper.no> wrote in message
news:uDIvPMFeEHA.2764@TK2MSFTNGP11.phx.gbl...
> Hi,
> You can check this my blog post
>
http://www.harper.no/valery/PermaLink,guid,8f5084eb-6a78-4ad9-8696-5c3595bc8
e7b.aspx
> that answers some of your questions.
>
> -Valery.
> http://www.harper.no/valery
>
> "kv" <kv@daimi[ ]dk['.au.' in the gap]> wrote in message
> news:cejafc$d9a$1@news.net.uni-c.dk...
> > Hi.
> >
> > I have a simple request: can someone please explain to me, the reasoning
> > behind strong naming an assembly also implies a FullTrust LinkDemand?
> >
> > The .NET Framework assemblies (mscorlib.dll, System.*) all have the APTC
> > Attribute making them useful in scenarios where assemblies have limited
> > trust (plug-ins etc.); however, in my experience most other assemblies
> > (3rd
> > party such as log4net, nunit, and many more, and even most of
Microsoft's
> > own non-Framework assemblies, such as Microsoft.mshtml) does not have
the
> > APTCA.
> >
> > Is it "just to be safe"? One may counter argue that the implicit
FullTrust
> > LinkDemand just forces users to grant full trust to code that doesn't
> > really
> > need it, thus introducing unnecessary security concerns on the part of
the
> > user?
> > Hypothetical case in point: I've bought a product from a guy over the
> > internet. I find it very useful; however, I don't completely trust that
> > it's
> > not a Trojan, so I limit its access to the network using CAS. It stops
> > working claiming it does not have sufficient permissions to run. Calling
> > up
> > the guy accusing him of selling be a Trojan, he assures me that it's
just
> > because it uses log4net or that it uses the HTML component to render the
> > about box or some other such harmless actions. Now I *have* to grant it
> > FullTrust and I have absolutely no way of knowing if it's a Trojan (even
> > if
> > I can see that it never references a System.Net or System.Web class, I
> > could
> > be sure it didn't do unsavory things by means of unsafe or unmanaged
code
> > or
> > through reflection). What are my options now? What are his options?
> >
> > The reason I'm asking is that I've lately become very frustrated trying
to
> > employ a security scheme based on CAS in a project of ours, with custom
> > permissions describing custom actions allowed or not in the system. We
> > wanted simply to develop permission types PermissionX, PermissionY, and
> > PermissionZ, and grant some (not all) of these permissions to some
> > assemblies and some to others, based on a custom scheme. Now, we've long
> > ago
> > chosen to use a certain 3rd party product for logging throughout our
> > product. This product consists of an assembly that is strong named (as
it
> > should be), but does not have the APTCA (as many don't). This forces us
to
> > give all our assemblies FullTrust, including(!!!) granting them
> > Permissions
> > X, Y, and Z, in turn completely foiling our otherwise beautiful scheme.
> >
> > Not only am I frustrated that so many (very likely harmless) assemblies
> > LinkDemands FullTrust, I am also frustrated by the mere existence of a
> > special FullTrust permission set that includes any permissions I may
chose
> > to develop. Why should anyone be made to care if their assembly has been
> > granted my custom permission (which is included in FullTrust)? Why not
> > just
> > have a more specific StrongNameLinkPermission that was implicitly
> > LinkDemanded by strong named assemblies? In the hypothetical case, I
could
> > then choose to grant that permission to the product without granting it
> > permissions to use sockets. This is in a way the problem in a nutshell:
I
> > can't, as a response to the guys claim that it uses log4net, grant it
some
> > permission that would allow it to use log4net, without also granting it
> > permission to read stuff from my harddisk and sending them back home
over
> > the internet. (Please note that I am not at all bashing log4net here; as
I
> > mentioned, they are not the only ones not using the APTCA. In fact it's
> > open
> > source, so a problem with log4net can always be solved quickly).
> >
> > After having stared at this issue for awhile, I can no longer avoid
> > thinking
> > that the .NET Framework designers *intended* for the internet guy's
> > product
> > to be granted all access to umanaged code private class members, and
even
> > my
> > custom permissions. But it makes absolutely no sense to me. What am I
> > missing?? Am I going nuts?
> >
> > Thanks
> > /kv
> >
> >
>
>

Quantcast