Any value to signing assemblies if not using the GAC?

[Tom Dacon]

If you're not putting assemblies in the GAC, but are referencing shared code
with copylocal=true into the projects that use them, is there any value to
signing the assemblies?

In the environment I've just begun to work in, there are customer-facing web
sites, internally-accessed maintenance and admin web sites, middle-tier
business logic assemblies, services, and Windows Forms apps that run on the
middle-tier. The policy is to sign the assemblies, but never to place them
in the GAC, even on the production servers.

My question: is there any actual value to signing the assemblies at all?
Presumably there's some assurance at runtime that the assemblies haven't
been compromised, but I'm having a hard time constructing a scenario in
which it pays off.

Any thoughts? Links? Best practices?

Tom Dacon
Dacon Software Consulting

[Steven Cheng[MSFT]]

Hi Tom,

Thanks for your posting. Regarding on this question, I've also found your
another thread in the
public.dotnet.framework newsgroup. I've posted my reply there. I'd
appreciate if you have a look there. Also, if you feel it convenient that
we continue to disscus in that thread, please feel free to post there.
Thanks.

Regards,

Steven Cheng
Microsoft Online Support

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

[Richard Blewett [DevelopMentor]]

Version numbers are ignored without strong names so if you want to take advantage of version aware loading then that is an issue.

You can't use codebase hint based deployment without a strong name

You can't use the StrongNameIdentityPermission attribute to control who can call your code

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<eR**************@TK2MSFTNGP10.phx.gbl>

If you're not putting assemblies in the GAC, but are referencing shared code
with copylocal=true into the projects that use them, is there any value to
signing the assemblies?

In the environment I've just begun to work in, there are customer-facing web
sites, internally-accessed maintenance and admin web sites, middle-tier
business logic assemblies, services, and Windows Forms apps that run on the
middle-tier. The policy is to sign the assemblies, but never to place them
in the GAC, even on the production servers.

My question: is there any actual value to signing the assemblies at all?
Presumably there's some assurance at runtime that the assemblies haven't
been compromised, but I'm having a hard time constructing a scenario in
which it pays off.

Any thoughts? Links? Best practices?

Tom Dacon
Dacon Software Consulting

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.809 / Virus Database: 551 - Release Date: 09/12/2004

[microsoft.public.dotnet.framework]

[Nick Malik]

If you have zero-touch deployment, then it is imperative that you sign your
assemblies. Even if you don't use zero-touch, but you do download your
windows app to the client, you need to do this.

Security scenario:
Your server has a copy of your client windows app and associated assemblies.
Your users download the client from the server on install.
Hacker cracks your server system and downloads your client and assemblies.
He modifies the code in an assembly to include a trojan and re-uploads the
modified assembly.

All new users of your app will download the client and the trojan-infected
assembly. Locally running DLLs run in the security space of the user, who
is often an administrator on their own machine.

Also, if your client checks the server for the updated dll and downloads it,
then all of your users will be infected, not just the current ones.

Signed code avoids this because the signature is an encrypted version of a
hash that is made of the assembly. Signed assemblies are checked, when they
are loaded, to make sure that the hash still matches. If someone had played
with it, the hash wouldn't match and the assembly wouldn't load.

This also allows you to insure that malware cannot call your application use
some of the features of .NET.

Therefore, to provide the foundation for security, your organization is
right to dictate, across the board, that all assemblies should be signed.

--- Nick

"Tom Dacon" <td****@community.nospam> wrote in message
news:eR**************@TK2MSFTNGP10.phx.gbl...

If you're not putting assemblies in the GAC, but are referencing shared code with copylocal=true into the projects that use them, is there any value to
signing the assemblies?

In the environment I've just begun to work in, there are customer-facing web sites, internally-accessed maintenance and admin web sites, middle-tier
business logic assemblies, services, and Windows Forms apps that run on the middle-tier. The policy is to sign the assemblies, but never to place them
in the GAC, even on the production servers.

My question: is there any actual value to signing the assemblies at all?
Presumably there's some assurance at runtime that the assemblies haven't
been compromised, but I'm having a hard time constructing a scenario in
which it pays off.

Any thoughts? Links? Best practices?

Tom Dacon
Dacon Software Consulting

[kfkyle]

Nick,
I've read some articles that indicated that protecting against the
"Trojan Horse" attack is altogether foolproof. In your example, if the
hacker could get copies of the server assemblies, then couldn't he rebuild
them with a virus embedded and then sign them with his own key pair. At this
point, whatever was downloaded by subsequent clients would successfully pass
the verification step.

This protection seems to work fine if the attacker only compromises some
of the application assemblies, which is of course a valuable layer of
security in of itself.

Is there a verification step in this scenario that I am not aware of? I
am relatively new to .NET and am trying to verify my own understanding of
these details.

http://msdn.microsoft.com/library/de...trongNames.asp
"Nick Malik" wrote:

If you have zero-touch deployment, then it is imperative that you sign your
assemblies. Even if you don't use zero-touch, but you do download your
windows app to the client, you need to do this.

Security scenario:
Your server has a copy of your client windows app and associated assemblies.
Your users download the client from the server on install.
Hacker cracks your server system and downloads your client and assemblies.
He modifies the code in an assembly to include a trojan and re-uploads the
modified assembly.

All new users of your app will download the client and the trojan-infected
assembly. Locally running DLLs run in the security space of the user, who
is often an administrator on their own machine.

Also, if your client checks the server for the updated dll and downloads it,
then all of your users will be infected, not just the current ones.

Signed code avoids this because the signature is an encrypted version of a
hash that is made of the assembly. Signed assemblies are checked, when they
are loaded, to make sure that the hash still matches. If someone had played
with it, the hash wouldn't match and the assembly wouldn't load.

This also allows you to insure that malware cannot call your application use
some of the features of .NET.

Therefore, to provide the foundation for security, your organization is
right to dictate, across the board, that all assemblies should be signed.

--- Nick

"Tom Dacon" <td****@community.nospam> wrote in message
news:eR**************@TK2MSFTNGP10.phx.gbl...

If you're not putting assemblies in the GAC, but are referencing shared

code

with copylocal=true into the projects that use them, is there any value to
signing the assemblies?

In the environment I've just begun to work in, there are customer-facing

web

sites, internally-accessed maintenance and admin web sites, middle-tier
business logic assemblies, services, and Windows Forms apps that run on

the

middle-tier. The policy is to sign the assemblies, but never to place them
in the GAC, even on the production servers.

My question: is there any actual value to signing the assemblies at all?
Presumably there's some assurance at runtime that the assemblies haven't
been compromised, but I'm having a hard time constructing a scenario in
which it pays off.

Any thoughts? Links? Best practices?

Tom Dacon
Dacon Software Consulting

[kfkyle]

I have a question related to this thread that you didn't explicitly address
and was wondering if you have any suggestions or input.

We are currently developing our build process for an ASP.NET
application.
This application will consist of about 8 assemblies in total. Even though
these assemblies will be deployed in a private application directory, we are
would like to apply strong names to them.

If possible, we would like to avoid the need to rebuild any given
Assembly if code changes have not occurred. However, a problem I see with
this approach has to do with the fact that Strong Names are partly comprised
of the version number itself. This can easily be seen in the assembly
manifest using the ILDASM.exe to look at referenced strongly named assemblies.

For example, lets say I build Assembly A & B and they are both strongly
named. If A references B then an extern reference will be placed in the
Assembly A's manifest (during compilation) pointing to Assembly B via its
strong name.

So, if I change Assembly B, but not A, this appears to require a rebuild
of both since Assembly A's manifest would need to be updated to use the new
strong name for Assembly B, even though Assembly A did not change. (This
assumes you follow the good practice of updating your Assembly versions when
changes are made.)

Am I missing something here, or is this simply the way things must work
when using .NET strong named assemblies.

-Keith

"Steven Cheng[MSFT]" wrote:

Hi Tom,

Thanks for your posting. Regarding on this question, I've also found your
another thread in the
public.dotnet.framework newsgroup. I've posted my reply there. I'd
appreciate if you have a look there. Also, if you feel it convenient that
we continue to disscus in that thread, please feel free to post there.
Thanks.

Regards,

Steven Cheng
Microsoft Online Support

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

[Steven Cheng[MSFT]]

Thanks for your join Keith,

Yes, your description is correct and that's why the .net framework can make
use of the STRONG-NAMED to avoid the DLL HELL in win32 DLL based program.
In addition, be care that ASP.NET web application doesn't support put
Strong-named assemblies in private bin folder, it is suggested to put into
GAC so as to avoid some unexpected errors. And you can find some kb
articles discussing on such problem.

Thanks.

Regards,

Steven Cheng
Microsoft Online Support

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