Security of DLL vs static linking
Results 1 to 7 of 7

Thread: Security of DLL vs static linking

  1. #1
    Junior Member
    Join Date
    Mar 2005
    Posts
    5

    Security of DLL vs static linking

    If I have a method that returns an important security call that tells me whether I am entitled to launch the application or not. It is a security hole to access this through a DLL rather than by statically linking to the library?

    In what way might this compromise security?

    Cheers,
    David

  2. #2
    Senior Member
    Join Date
    Jun 2003
    Posts
    236
    Im not entirely sure about this maybe some other members can correct me if Im wrong.
    First if its a .dll then it resides in a portion of memory where other programs that use the same dll can all access it, whereas if you built the program statically the code would reside in the 'text' portion of memory.

    I cant see how aceessing it would in either way would jepordize security from an internal coding standing point. But if I were stack tracing the program or using something like process explorer you would be able to tell what .dll was being accessed.

    Now the benefit of using a dll over statically linking is that if a bug is found in the code your linking in. Lets say a buffer overflow. Now your code can be directly affected, maybe even allowing a compormise of the system. If the bug is fixed a new dll can go out and basically correct the issue. And any programs that use it as a dll will now be safe. But if youve statically linked your binary will continue to be affected.
    That which does not kill me makes me stronger -- Friedrich Nietzche

  3. #3
    Senior Member Maestr0's Avatar
    Join Date
    May 2003
    Posts
    604
    There are quite a few advantages of mobile code or dymaically linked code, the security is a serious factor however. Luckily .NET has some pretty nifftty stuff for this which basically allows you to encrypt assemblies with key pairs. Have a look at
    http://msdn.microsoft.com/library/de...Assemblies.asp
    and
    http://msdn.microsoft.com/library/de...classtopic.asp


    -Maestr0
    \"If computers are to become smart enough to design their own successors, initiating a process that will lead to God-like omniscience after a number of ever swifter passages from one generation of computers to the next, someone is going to have to write the software that gets the process going, and humans have given absolutely no evidence of being able to write such software.\" -Jaron Lanier

  4. #4
    Junior Member
    Join Date
    Mar 2005
    Posts
    5
    Thanks for the answers!

    I thought the rpoblem was that someone could just put a dummy DLL in place with the same method call that always returns true.

    So I have my C DLL with a function license_paid(). I access it from a C# application.

    Someone take a look at the DLL guesses that thye just have to get a zero back from license_paid() and drops in a dummy DLL which always returns true for that method.

    Have I understood correctly?

  5. #5
    Senior Member
    Join Date
    Mar 2004
    Posts
    557
    Hi

    Davidlock, I think you did understand correctly. There are two interesting point of
    views here:

    Assume, a certain function in some system dll does have a security issue (vulnerability).
    If an executable is linked dynamical, it will be affected by the vulnerability as long as that
    system dll is not patched. A statically linked executable will "always" be vulnerable.

    Assume, an API has been "hooked" by some kind of rootkit, such that a certain function
    in a dll is not doing what is expected. Then, your dynamically linked executable is
    affected (as in your example), however there is a chance that your static executable is not.

    There are advantages and disadvantages in both cases (related in this context, the "GDI-hell"
    in September 2004 might be worth mentioned).

    Cheers.
    If the only tool you have is a hammer, you tend to see every problem as a nail.
    (Abraham Maslow, Psychologist, 1908-70)

  6. #6
    Senior Member Maestr0's Avatar
    Join Date
    May 2003
    Posts
    604
    If you use strong named assemblies people will not be able to:
    1. Link against or use your assebly without the key
    2. substitue or tamper with the assembly (this would change the signature)


    -Maestr0
    \"If computers are to become smart enough to design their own successors, initiating a process that will lead to God-like omniscience after a number of ever swifter passages from one generation of computers to the next, someone is going to have to write the software that gets the process going, and humans have given absolutely no evidence of being able to write such software.\" -Jaron Lanier

  7. #7
    Junior Member
    Join Date
    Mar 2005
    Posts
    5
    Thanks for the posts.

    The scenario I have is a standard C DLL being accessed by a .NET C# application using the interopservices and DLLIMPORT. I don't believe there would be any way to sign that DLL because out is not managed. So this dynamically linked model seems to be very easy to bypass in this example.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •