none
I successfully tampered a strong named assembly in GAC RRS feed

  • Question

  • Hello,

    I am confused about the following situation:

    I build a c# based class libray (one class, one method)  which is just writing a string to the console, nothing else.
    The class library is signed with a sn generated key.

    I wrote a simple c# based command line executable, which creates an object of the class from lib above and calls the method to write the string to the console.

    Works perfect!
    Well not really suprising.

    Now I tampered the strong named assembly in a binary editor by manipulating the output string.

    I started the executable again and, ... surprise, surprise ... the tampered string is displayed on the console.

    Wow! I expected to get a FileLoadException, but there is none.

    So here are my questions:

    What is wrong with my code?

    In case of the behavior is expected (not to me), why do I need strong named assemblies?

    I used .NET Framework 4 Client Profile Platform Update 1 and VS 2010 Premium.
    Executable is running on W7 Enterprise.

    Regards
    r.b.





    • Edited by _Red_Baron_ Tuesday, September 25, 2012 7:18 AM
    Monday, September 24, 2012 9:50 AM

Answers

  • If you modify the dll after you install it then I'm not surprised. Validation is done when you install the dll, after that it is assumed that the strong name is valid. Keep in mind that you need administrator rights to modify files in GAC.
    • Proposed as answer by Mike FengModerator Wednesday, September 26, 2012 10:23 AM
    • Marked as answer by _Red_Baron_ Monday, October 1, 2012 8:17 AM
    Monday, September 24, 2012 11:53 AM
    Moderator
  • Hi Red Baron,

    >>The other point is that I use an assembly from the GAC and I do not know, which dll is loaded from which physical GAC path.

    Actually, you can find it by the platform and public token. This is unique.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by _Red_Baron_ Monday, October 1, 2012 8:08 AM
    Monday, October 1, 2012 5:10 AM
    Moderator

All replies

  • Strong name validation is not performed for applications running in full-trust (that is, most desktop .NET apps). The strong name is validated only when installing the assembly in GAC or when loading it in a partial-trust app domain (ASP.NET, IE etc.)

    http://msdn.microsoft.com/en-us/library/cc713694.aspx

    Monday, September 24, 2012 10:33 AM
    Moderator
  • Hello Mike,

    thank you for your answer.

    This is a good hint, but unfortunately I can tamper the GAC version as well without getting an exception, when the executable loads the GAC dll.

    Regards

    r.b.


    • Edited by _Red_Baron_ Monday, September 24, 2012 11:48 AM
    Monday, September 24, 2012 11:48 AM
  • If you modify the dll after you install it then I'm not surprised. Validation is done when you install the dll, after that it is assumed that the strong name is valid. Keep in mind that you need administrator rights to modify files in GAC.
    • Proposed as answer by Mike FengModerator Wednesday, September 26, 2012 10:23 AM
    • Marked as answer by _Red_Baron_ Monday, October 1, 2012 8:17 AM
    Monday, September 24, 2012 11:53 AM
    Moderator
  • Hi Baron,

    How about Mike Danes's explanation?

    Do you have any update?

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, September 26, 2012 10:24 AM
    Moderator
  • Hello Mike,

    OK, I understand. But I do not understand the security concept behind it.
    That means Administrator are inherently noble people and would never tamper assemblies?

    No just joking.

    I mean what does that help, that admins can change dlls and the Applications expect getting safe code?

    Regards

    r.b.

    Wednesday, September 26, 2012 10:46 AM
  • Hi Red,

    I tried to tampered an assembly, and I found that it cannot pass the sn check. So you can check it before use it.

    Here is the related API: StrongNameSignatureVerificationEx  http://msdn.microsoft.com/en-us/library/ms232579.aspx 

    Here is the test code:

     
            [DllImport("mscoree.dll", CharSet = CharSet.Unicode)]
            public static extern bool StrongNameSignatureVerificationEx(string wszFilePath, bool fForceVerification, out bool pfWasVerified);
    
    
            static void Main(string[] args)
            {
                //getTypes();
                bool result =true ;
                StrongNameSignatureVerificationEx(@"E:\C# Projects\WinFormsApp-ListView\WinFormsApp-ListView\bin\Release\2.exe", true, out result);
                Console.WriteLine(result );
                Console.Read();
            }
    Best regards,

    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thursday, September 27, 2012 10:02 AM
    Moderator
  • Hello Feng,

    thank you very much for your answer.

    I understand what you do, but this is not my use case.

    As far as I understand, everybody who has administration rights can tamper assemblies, even if they are in the gac.
    So every application which trust on gac assemblies not being tampered can be tampered indirectly in principle.

    Right?

    Best regards

    r.b.

    Thursday, September 27, 2012 10:53 AM
  • Hi Red,

    >>So every application which trust on gac assemblies not being tampered can be tampered indirectly in principle.

    Yes, I think so. But I recommend you to verify it before load it when it is related to security.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, September 28, 2012 3:35 AM
    Moderator
  • Hello Mike,

    thank you for your answser. Yes, you are right. I understood your previous answer.
    I expected that the runtime is doing it for me. OK, wrong understanding.

    The other point is that I use an assembly from the GAC and I do not know, which dll is loaded from which physical GAC path.

    Regards

    r.b.


    • Edited by _Red_Baron_ Friday, September 28, 2012 3:10 PM
    Friday, September 28, 2012 3:09 PM
  • Hi Red Baron,

    >>The other point is that I use an assembly from the GAC and I do not know, which dll is loaded from which physical GAC path.

    Actually, you can find it by the platform and public token. This is unique.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by _Red_Baron_ Monday, October 1, 2012 8:08 AM
    Monday, October 1, 2012 5:10 AM
    Moderator
  • Hello Mike,

    thank you for your answer, which is technically correct.
    In real life it happens that one doesn't know the tokens and versions from 3rd party libraries in gac.
    And your proposed test would even fail it the supplier updates the GAC.

    So I see your answers, which are all correct in a technical way, but not always feasible in real life.

    I am sitll surprised about that security concept.

    Nevertheless, thank you for your support.

    Regards

    r.b.

    Monday, October 1, 2012 8:08 AM
  • Hi Red Baron,

    >>In real life it happens that one doesn't know the tokens and versions from 3rd party libraries in gac.

    I don't think so. Because we need to get the 3rd party in an official way, and at the same time, we can get the usage and technical support. So we absolutely know the reference details.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, October 1, 2012 8:51 AM
    Moderator
  • Hello Mike,

    I do not know, who is "we" in your reply.
    The answer is not valid in the environments of our products.

    Regards

    r.b.

    Monday, October 1, 2012 9:09 AM
  • Hello Mike,

    I do not know, who is "we" in your reply.
    The answer is not valid in the environments of our products.

    Regards

    r.b.

    Hi Red Baron,

    The "we" means you, or the general developers who needs a third party reference, whatever the third party reference is developed by yourself or the other team.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, October 1, 2012 9:14 AM
    Moderator
  • Hello Mike,

    thanks again.
    There is another security leak, when 3rd party assemblies load other assemblies dynamically e.g via IoC frameworks.

    Normally we do not know, who is loading which assembly in which version and which token dynamically. So all the assemblies we load from others can be tampered in principle.

    Regards

    r.b.


    • Edited by _Red_Baron_ Monday, October 1, 2012 9:45 AM
    Monday, October 1, 2012 9:24 AM