Re: Does .NET detect alterations to an assembly?

From: Marcelo Birnbach [MS] (mbirnbac@online.microsoft.com)
Date: 02/18/03 

From: "Marcelo Birnbach [MS]" <mbirnbac@online.microsoft.com>
Date: Mon, 17 Feb 2003 18:13:52 -0800

I think that's for performance reasons. BTW, if the file is not strong
named, it can be tampered anyway.

"Michel Gallant (MVP)" <neutron@istar.ca> wrote in message
news:3E4D9650.409B244E@istar.ca...
> Yes, this is correct. As verified with a multi-file assembly:
>
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconmultifileassemblyexample.asp
>
> ------ Unsigned multi-file assembly case ---------
> I generated a 3-file assembly (with 2 modules and one assembly, containing
only the manifest).
> The manifest in the assembly file contains, among other things, the hash
values of each of the
> component files.
> Executed the assembly as is. OK
> Modified one byte in one of the modules (part of text string printed out)
using VS.net [ Open File
> As ... binary]
> Executed this "hacked" assembly again. The assembly loaded and executed,
showing the modified
> Console
> output character string, with no errors (indicating that hashes of
assembly component files were not
> verified at loading).
>
> ------ Strong-Name signed assembly case -------
> Same 3 file assembly, except Strong-Name signed thus:
> al Client.netmodule Stringer.netmodule /main:MainClientApp.Main
/out:myAssemblysn1.exe
> /keyname:"mycryptickeycontainername" /target:exe
> Executed the assembly as is. OK
> Modified one byte in one of the modules (exactly as above).
> Executed the "hacked" assembly again. Failed with debugger indicating
failure of hash verif. for
> changed module.
>
> So, this was a simple brute-force demonstration of this.
>
> ***Question:****
> If multi-file assemblies always include the component hash values of the
various parts, why is
> hash verification NOT performed at load-time for non-signed assemblies
also?
>
> Cheers,
> - Michel Gallant
> MVP Security
> JavaScience Consulting
> http://pages.istar.ca/~neutron
>
> "Marcelo J. Birnbach" wrote:
>
> > The hash check is ONLY done for signed assemblies. The strong name
> > information is stored only in the first module of the assembly. The hash
is
> > verified for the extra modules added to the assembly when it's strongly
> > named.
> >
> > Thanks,
> > Marcelo
> >
> > "Michel Gallant (MVP)" <neutron@istar.ca> wrote in message
> > news:3E4D674D.3B9D48A1@istar.ca...
> > > That paragraph seems to indicate that the hash inclusion and
verification
> > > at assembly-loading is ALWAYS done, even without any strong name
> > > or Authenticode signature.
> > > This should be easy to check ...
> > > - Mitch
> > >
> > > David Thom wrote:
> > >
> > > > It's still not clear whether the hash-check is done whether or not
the
> > > > assembly is signed/strong-named.
> > > >
> > > > The quotation you included in your reply appears to be in the
context of
> > a
> > > > signed/strong-named assembly.
> > > >
> > > > But is hash-checking also done for "plain" assemblies?
> > > >
> > > > David Thom
> > > >
> > > > "Michel Gallant (MVP)" <neutron@istar.ca> wrote in message
> > > > news:3E4D3FFF.D485E045@istar.ca...
> > > > > see also:
> > > > >
> > > >
> >
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
> > > > l/cpconassembliessecurityconsiderations.asp
> > > > >
> > > > > "The common language runtime also performs a hash verification;
the
> > > > assembly
> > > > > manifest contains a list of all files that make up the assembly,
> > including
> > > > a hash
> > > > > of each file as it existed when the manifest was built. As each
file
> > is
> > > > loaded,
> > > > > its contents are hashed and compared with the hash value stored in
the
> > > > manifest.
> > > > > If the two hashes do not match, the assembly fails to load. "
> > > > >
> > > > > - Mitch
> > > > >
> > > > >
> > > > > "Shawn Farkas [MS]" wrote:
> > > > >
> > > > > > David,
> > > > > >
> > > > > > If you sign your assembly, then the framework will detect if
it
> > has
> > > > been
> > > > > > tampered with, and refuse to load it.
> > > > > >
> > > > > > -Shawn
> > > > > >
> > > > > > --
> > > > > > This posting is provided "AS IS" with no warranties, and confers
no
> > > > rights.
> > > > > > Please do not send email directly to this alias, this alias is
for
> > > > newsgroup
> > > > > > purposes only.
> > > > > >
> > > > > > "David Thom" <davidt@npsinc.com> wrote in message
> > > > > > news:uk8oMSD1CHA.1644@TK2MSFTNGP12...
> > > > > > > If an assembly were altered - say, with a hex editor - does
.NET
> > > > detect
> > > > > > the
> > > > > > > alteration?
> > > > > > >
> > > > > > > If, for example, we embed a string value in a .NET assembly,
can
> > it be
> > > > > > > changed by a hacker? (we don't care if it can be viewed, we
just
> > don't
> > > > > > want
> > > > > > > it to be changed).
> > > > > > >
> > > > > > > I seem to recall that .NET assemblies have a "hash count/code"
to
> > > > protect
> > > > > > > against this. But I don't know if that "feature" requires code
> > signing
> > > > or
> > > > > > > some other overt action on the developer's/deployer's part in
> > order to
> > > > > > > activate it.
> > > > > > >
> > > > > > > If I simply create a .NET assembly and do nothing else, is it
> > > > protected
> > > > > > > against modification? Or should I say, will the alteration at
> > least
> > > > be
> > > > > > > detected?
> > > > > > >
> > > > > > > Thanks!
> > > > > > >
> > > > > > > David Thom
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > >
>

Relevant Pages

  • Re: Does .NET detect alterations to an assembly?
    ... The hash check is ONLY done for signed assemblies. ... information is stored only in the first module of the assembly. ... > That paragraph seems to indicate that the hash inclusion and verification ...
    (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
    ... >> 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: 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)
  • Re: Does .NET detect alterations to an assembly?
    ... I generated a 3-file assembly (with 2 modules and one assembly, containing only the manifest). ... Failed with debugger indicating failure of hash verif. ... If multi-file assemblies always include the component hash values of the various parts, ... hash verification NOT performed at load-time for non-signed assemblies also? ...
    (microsoft.public.dotnet.security)