Re: Signed assemblies easily cracked?

From: Nicole Calinoiu (calinoiu)
Date: 11/25/04

  • Next message: Nicole Calinoiu: "Re: Signed assemblies easily cracked?" 
    Date: Thu, 25 Nov 2004 12:15:41 -0500

    "Frank Wallwitz" <Frank.Wallwitz@t-online.de> wrote in message
    news:OmsAyvL0EHA.3976@TK2MSFTNGP09.phx.gbl...
    > I would not call it a bug.

    Interesting. The documentation on strong name use by the .NET Framework
    would strongly suggest that at least one somebody at Microsoft might
    disagree with you on this one. (See, for example,
    http://msdn.microsoft.com/library/en-us/cpguide/html/cpconstrong-namedassemblies.asp.)

    > It's simply the way Microsoft has implemented the
    > verification of sn-signed assemblies.

    Obviously, but just because it shipped this way doesn't mean it's not a bug
    in either design or implementation.

    > In the end, there must be a flag, or some code somewhere inside the
    > assembly
    > telling the framework that it is strong named or whatever.

    It doesn't have to be a separate flag. The presence of the strong name
    signature in a reserved position should be a sufficient, self-contained flag
    for the validation.

    > Implementing this
    > 'cracker-proof' is very hard (if not impossible).

    Sure, but it could be a lot more robust than allowing a flag byte to disable
    validation.

    > The problem is that an application in fact can't trust while loading a sn
    > assembly, that it is the expected.

    Expected by whom? Probably not by folks who've read the documentation on
    the framework's use of strong names for assembly validation.

    > As I wrote in my first statement: strong names aren't a method for making
    > your code secure and the are not intended to do this.

    Nope, but they are expected to help protect users from manipulation or
    substitution of highly trusted assemblies.

    > The intention was to make sure, that only well-known, 'trusted' assemblies
    > can load each other.

    The documentation would suggest that the main goal was to provide a
    mechanism to prevent execution of assemblies modified by anyone other than
    their legitimate author.

    > From my point of view that's not longer true :(

    Do we have any evidence that it was ever true, or has the switch byte been
    active in all shipped versions of the .NET Framework?

    >
    > regards
    > Frank
    >
    >

  • Next message: Nicole Calinoiu: "Re: Signed assemblies easily cracked?"

    Relevant Pages

    • Registering a .NET assembly for COM interop access from an ASP page
      ... the assembly will only be accessed from pages in the ASP ... above documentation suggests I don't have to and the .NET Framework ... that "it is not necessary to install assemblies into the global assembly ...
      (microsoft.public.dotnet.framework.interop)
    • Re: Goodbye and Best Wishes
      ... "The .NET Framework supports both backward and forward compatibility. ... > a collection of assemblies and applications) that uses Avalon's GDI+ ...
      (borland.public.delphi.non-technical)
    • Re: Links for .NET security stuff
      ... .NET Framework Developer's Guide: Configuring Permission ... .NET Framework Developer's Guide: Configuring Code Groups ... Strong-Named Assemblies ...
      (microsoft.public.dotnet.general)
    • RE: Problem registering managed component with COM
      ... You need to use some COM interoperability mechanism. ... "Exposing .NET Framework Components to COM" in the VS documentation. ... Failed to register assembly 'ChatterBox, Version=1.0.0.0, ...
      (microsoft.public.dotnet.general)
    • Article : .NET Framework Configuration Tool (Mscorcfg.msc)
      ... We have almost covered all the .NET Framework Tools except a few, ... a .Net configuration tool, which allows you to manage .Net Framework GAC, ... to manage assemblies in GAC. ... configured assemblies and remoting services. ...
      (microsoft.public.dotnet.framework.setup)
    • Quantcast