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

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.

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

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?

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 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

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.