Re: securing an assembly

From: Michel Gallant (neutron_at_NOSPAMistar.ca)
Date: 03/10/04


Date: Wed, 10 Mar 2004 14:14:48 -0500

Shawn,
I think that Microsoft has to be very careful to not introduce infrastructure (like delayed signing)
which can itself very easily lead to incorrect and insecure use.
I found SN delayed signing rather confusing at first glance.

Actually imo a bigger vulnerability is the fact that any keypairs created by sn -k are
cleartext PRIVATEKEYBLOBS (as I have posted many times :-)

I suspect most teams don't really practice good security .. so BY DEFAULT why shouldn't
sn.exe generate a pswd-protected keypair file?

Regards,
- Mitch Gallant
   MVP Security
   www.jensign.com

""Shawn Farkas"" <shawnfa@online.microsoft.com> wrote in message
news:rUUsIGtBEHA.3552@cpmsftngxa06.phx.gbl...
> No, if you've set up your development machines to not verify assemblies signed with that key
(which you have to do in order to work with delay
> signed assemblies), then as soon as you release a signed version of the assembly, anyone could
extract the public key token, and create a new
> assembly that has that token. Since verification is turned off for that specific token, the
malicious person could do whatever they want in their
> assembly. Also, since they have the correct public key token, the strong name will match what
you're expecting. The only obstical remains that
> they must find a way to get this modified assembly downloaded onto a machine where someone has
turned off verification for the token.
>
> -Shawn
> http://blogs.msdn.com/shawnfa
>
> --
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
> Note: For the benefit of the community-at-large, all responses to this message are best directed
to the newsgroup/thread from which they
> originated.
> --------------------
> >From: "SStory" <TheStorys@TAKEOUTTHISSPAMBUSTERsofthome.net>
> >References: <EAA195F6-8FE3-42AC-8BE3-A5771C5D15DE@microsoft.com>
<O5C4x##7DHA.1052@TK2MSFTNGP12.phx.gbl> <O9FP0L
> $7DHA.2412@TK2MSFTNGP09.phx.gbl> <O7UvMgF8DHA.2300@TK2MSFTNGP10.phx.gbl>
<lejk201po941d1u9gq1ancsf9cpbq6qn9k@
> 4ax.com> <#RLDwiL8DHA.3704@tk2msftngp13.phx.gbl> <uN9jX1hAEHA.1600@tk2msftngp13.phx.gbl>
<IziS#BxAEHA.604
> @cpmsftngxa06.phx.gbl>
> >Subject: Re: securing an assembly
> >Date: Tue, 9 Mar 2004 14:14:15 -0600
> >Lines: 192
> >X-Priority: 3
> >X-MSMail-Priority: Normal
> >X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
> >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
> >Message-ID: <uSChTLhBEHA.464@TK2MSFTNGP11.phx.gbl>
> >Newsgroups: microsoft.public.dotnet.security
> >NNTP-Posting-Host: 0-1pool140-179.nas12.nashville1.tn.us.da.qwest.net 65.135.140.179
> >Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP11.phx.gbl
> >Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.security:5331
> >X-Tomcat-NG: microsoft.public.dotnet.security
> >
> >But this means the anyone would have to be a rogue developer inside the
> >organization
> >who extracted the public key and made his own up right?
> >
> >Because once I signed it and sent that out, signed, this couldn't happen,
> >right?
> >
> >Thanks,
> >
> >Shane
> >
> >""Shawn Farkas"" <shawnfa@online.microsoft.com> wrote in message
> >news:IziS%23BxAEHA.604@cpmsftngxa06.phx.gbl...
> >> Hi Shane,
> >>
> >> The problem the article is pointing out is that a delay signed assembly
> >does not have a valid signature on it, so it cannot be verified.
> >> Because of this, on your development machines you need to turn off
> >verification of that assembly. Since anyone can extract a public key from a
> >> fully signed file, they could then create a replacement assembly that does
> >something bad and give it the same strong name (since only the public
> >> key token is part of the strong name, and they have access to that). They
> >don't have to get a valid signature onto this malicious assembly, since
> >> you've turned off verification.
> >>
> >> -Shawn
> >> http://blogs.msdn.com/shawnfa
> >>
> >> --
> >>
> >> This posting is provided "AS IS" with no warranties, and confers no
> >rights.
> >> Note: For the benefit of the community-at-large, all responses to this
> >message are best directed to the newsgroup/thread from which they
> >> originated.
> >> --------------------
> >> >From: "SStory" <TheStorys@TAKEOUTTHISSPAMBUSTERsofthome.net>
> >> >References: <EAA195F6-8FE3-42AC-8BE3-A5771C5D15DE@microsoft.com>
> ><O5C4x##7DHA.1052@TK2MSFTNGP12.phx.gbl> <O9FP0L
> >> $7DHA.2412@TK2MSFTNGP09.phx.gbl> <O7UvMgF8DHA.2300@TK2MSFTNGP10.phx.gbl>
> ><lejk201po941d1u9gq1ancsf9cpbq6qn9k@
> >> 4ax.com> <#RLDwiL8DHA.3704@tk2msftngp13.phx.gbl>
> >> >Subject: Re: securing an assembly
> >> >Date: Thu, 4 Mar 2004 13:19:26 -0600
> >> >Lines: 117
> >> >X-Priority: 3
> >> >X-MSMail-Priority: Normal
> >> >X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
> >> >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
> >> >Message-ID: <uN9jX1hAEHA.1600@tk2msftngp13.phx.gbl>
> >> >Newsgroups: microsoft.public.dotnet.security
> >> >NNTP-Posting-Host: 0-1pool98-163.nas16.nashville1.tn.us.da.qwest.net
> >65.144.98.163
> >> >Path:
> >cpmsftngxa06.phx.gbl!TK2MSFTNGXA06.phx.gbl!TK2MSFTNGXA05.phx.gbl!TK2MSFTNGP0
> >8.phx.gbl!tk2msftngp13.phx.gbl
> >> >Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.security:5247
> >> >X-Tomcat-NG: microsoft.public.dotnet.security
> >> >
> >> >Michel,
> >> >
> >> >in the SNing article you mention what does the following warning mean?
> >> >Protecting Your Development Team
> >> >Delay signing isn't perfect. Because your team must turn off strong name
> >> >verification for one or more public keys in order to test their own
> >> >assemblies during development, be very careful not to confer trust on an
> >> >assembly based solely on the presence one of these unverified strong
> >names.
> >> >Given your public key, an attacker can delay sign a malicious assembly
> >just
> >> >as easily as you can delay sign your own assemblies. And you must assume
> >> >that any attacker will be able to easily obtain your public key, since it
> >is
> >> >embedded as metadata in each strong-named assembly you build.
> >> >
> >> >Please tell me what the danger is in this? Is this a danger after it is
> >> >singed or just if it is released before being signed or what?
> >> >
> >> >Thanks,
> >> >
> >> >Shane
> >> >
> >> >
> >> >
> >> >"Michel Gallant" <neutron@NOSPAMistar.ca> wrote in message
> >> >news:%23RLDwiL8DHA.3704@tk2msftngp13.phx.gbl...
> >> >> Here is a simple walk-through for SNing an assembly and adjusting
> >> >> CAS for network-share deployment (similar for Internet deployment):
> >> >> http://www3.sympatico.ca/mitchg/dotnet/networkshare.html
> >> >>
> >> >> Also this excellent article on SNing:
> >> >>
> >>
> >>http://msdn.microsoft.com/security/default.aspx?pull=/library/en-us/dnnetse
> >c/html/strongnames.asp
> >> >>
> >> >> - Michel Gallant
> >> >> MVP Security
> >> >> JavaScienceConsulting
> >> >> http://pages.istar.ca/~neutron
> >> >>
> >> >> "Mary Chipman" <mchip@nomail.please> wrote in message
> >> >> news:lejk201po941d1u9gq1ancsf9cpbq6qn9k@4ax.com...
> >> >> > "Creating and Using Strong-Named Assemblies" in the help file is as
> >> >> > good place as any to start.
> >> >> >
> >> >> > -- Mary
> >> >> > MCW Technologies
> >> >> > http://www.mcwtech.com
> >> >> >
> >> >> > On Tue, 10 Feb 2004 22:32:19 -0600, "Joe Kaplan \(MVP - ADSI\)"
> >> >> > <joseph.e.kaplan@removethis.accenture.com> wrote:
> >> >> >
> >> >> > >The big decision is whether you want to do strong names or
> >> >authenticode. If
> >> >> > >you go with strong names, you first need to sign all of your
> >> >assemblies.
> >> >> > >This can be done via the AssemblyKeyName or AssemblyFile attributes
> >or
> >> >via
> >> >> > >the sn tool.
> >> >> > >
> >> >> > >To ensure that your assemblies are only used by code that has been
> >> >signed by
> >> >> > >one of these mechanisms, you create the appropriate permission and
> >> >Demand
> >> >> > >it. You can do this with attributes or in code with permission
> >objects
> >> >and
> >> >> > >the Demand method.
> >> >> > >
> >> >> > >I don't have a good sample I can point you too, but there is likely
> >> >someone
> >> >> > >else in the forum who might have one or could answer more detailed
> >> >questions
> >> >> > >if you get stuck.
> >> >> > >
> >> >> > >Joe K.
> >> >> > >
> >> >> > >"Jonas" <jonas@nospam.pl> wrote in message
> >> >> > >news:O9FP0L$7DHA.2412@TK2MSFTNGP09.phx.gbl...
> >> >> > >> Can You point us to some info on how to do this step-by-step?
> >> >> > >>
> >> >> > >> TIA
> >> >> > >>
> >> >> > >> Jonas
> >> >> > >>
> >> >> > >> "Joe Kaplan (MVP - ADSI)"
> ><joseph.e.kaplan@removethis.accenture.com>
> >> >wrote
> >> >> > >> in message news:O5C4x%23%237DHA.1052@TK2MSFTNGP12.phx.gbl...
> >> >> > >> > Signing your assemblies with a strong name key or authenticode
> >> >signing
> >> >> > >> them,
> >> >> > >> > along with using StrongNamePermissionAttribute or
> >> >> > >> > PublisherIdentityPermissionAttribute, should allow you to make
> >> >ensure
> >> >> > >that
> >> >> > >> > only code signed with the correct key or certificate can call
> >your
> >> >code.
> >> >> > >> > This is probably better than trying to implement this yourself.
> >> >> > >> >
> >> >> > >> > Joe K.
> >> >> > >> >
> >> >> > >> > "steve" <anonymous@discussions.microsoft.com> wrote in message
> >> >> > >> > news:EAA195F6-8FE3-42AC-8BE3-A5771C5D15DE@microsoft.com...
> >> >> > >> > > I have written a dll assembly which I want to make sure can
> >only
> >> >be
> >> >> > >> > accessed by applications written by our own company.
> >> >> > >> > > Are there any inbuilt mechanisms to achieve this or do I have
> >to
> >> >> > >> implement
> >> >> > >> > my own.
> >> >> > >> > >
> >> >> > >> > > Steve
> >> >> > >> >
> >> >> > >> >
> >> >> > >>
> >> >> > >>
> >> >> > >
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >>
> >>
> >
> >
> >
>
>



Relevant Pages

  • Re: When to use Public/Private Key & when to gen new one?
    ... The key pair is uniquely bound to each other: you can't have one private key ... options for extracting the public key, but not one for 'build new public key ... I was including in assemblies whatever it had spat one ... probably keep the same snk file across various builds of an assembly, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: securing an assembly
    ... >> signed assemblies), then as soon as you release a signed version of the assembly, anyone could ... Since verification is turned off for that specific token, ... Also, since they have the correct public key token, the strong name will match what ... >>>> The problem the article is pointing out is that a delay signed assembly ...
    (microsoft.public.dotnet.security)
  • Re: Loading unsigned assembly
    ... How can the solution be to ensure that there are no StrongName skip verification entries on the ... I'm also looking for a solution to this, as it seems there has to be a way to verify an assembly is your own by more than a public key check. ... however the signature is not computed. ... > best ways to avoid this situation would be to ensure that assemblies you don't want to load do not have FullTrust (even the Everything ...
    (microsoft.public.dotnet.security)
  • Re: securing an assembly
    ... who extracted the public key and made his own up right? ... > you've turned off verification. ... >>Delay signing isn't perfect. ... >>as easily as you can delay sign your own assemblies. ...
    (microsoft.public.dotnet.security)
  • Re: securing an assembly
    ... Michael's not saying that the key shouldn't be stored on the disk, rather he's saying that sn should encrypt the generated key with some sort of ... if you've set up your development machines to not verify assemblies ... Also, since they have the correct public key token, the ... >> turned off verification for the token. ...
    (microsoft.public.dotnet.security)