Apart from getting the application to perform a CRC check of the DLL
it uses, is there any other way of making sure that an application is
using the DLL it thinks it is.

For example, a fake DLL could be placed in the application's execution
path (or wherever the application is going to load it from) that calls
the real DLL whenever it needs information that it can't provide
itself, and return dummy results in other cases. What could be done
to prevent this?

By the way, this isn't crucial - I'm just interested.

Mike

--
Michael Winter
M.Winter@[no-spam]blueyonder.co.uk (remove [no-spam] to reply)

On Tue, 23 Sep 2003 23:34:40 GMT, "Michael Winter" <M.Winter@[no-spam]blueyonder.co.uk> wrote:

I think this is off-topic here, because it doesn't have to do with
Windows programming per se.

But there is a difference between the situation you describe and what's
basically the 'man in the middle' scenario for security considerations,
namely that you assume that the system on which the 'server' resides is
physically compromised.

In that case there is nothing you can do to achieve 100% security, but
you can make it _more difficult_ to do the impostor thing.

You can start by modifying the default search for DLLs. In Windows
XP (see doc of LoadLibrary and doc of DLL redirection), set
HKLM\System\CurrentControlSet\Control\SessionManag er\SafeDllSearchMode
to 1, to have the current directory searched after the Windows and system
directory but before directories in the PATH. This can prevent a fake
'user32.dll', say, from being loaded from your app's current directory.
Also, still Windows XP, you can place a file named 'myappname.local' in the
app's directory, which will cause this directory to be searched first
even when a path is specified, overriding that path. Whether it gives
better security to have this file or to remove it if it exists depends
very much on the situation; in your case, assuming a compromised system,
I think it would be a good idea to remove that file if it exists.

Second, you can check whether the DLL has some known properties.

The CRC check idea, or generalizations thereof, is a good starting point.
CRC can be faked, some other schemes are less easily faked. E.g., newer
versions of Windows provide support for digital certificates. But this
is only a general idea. I haven't used them myself, so I suggest you post
this question on some security related group (perhaps post answers back!).

Third, you can have two or more differently named duplicates of the DLL,
or of parts of the DLL, and compare them against each other -- this will
make it somewhat harder to simply replace a DLL.

Fourth, you can encrypt each DLL and decrypt it using a key supplied by
your application. However, what if the application itself is replaced?
As mentioned, on a compromised system there's no such thing as 100% secure.

Fifth, you can let the decryption key reside on a smart-card. Newer
versions of Windows have built-in smart-card support. Combine that with
authentication and verification of the app itself using a helper program
on secure storage (e.g., again, smartcard, or write-protected floppy),
and I think that's about the best that can be done; not 100%, and certainly
not safe against a dedicated attack, but good enough to defeat common
viruses and such.

"Michael Winter" <M.Winter@[no-spam]blueyonder.co.uk> wrote in message
news:kM4cb.3658$FA3.32767023@news-text.cableinet.net...
The whole thing can be roughly divided as follows:

1. The application loads the DLL explicitly. Then the application can
theoretically check the identity of the DLL [and reject it if it is
unknown].

2. The application loads the DLL implicitly. Then it cannot check its
identity and somebody else must do it for it. This case is harder, and more
so because most DLLs are loaded this way.

Checking identity is not very hard these days when strong digital signatures
and cryptographic algorithms [and libraries] are ubiquitous. What is hard is
maintaining a library of such signatures, especially in case 2, especially
when you need to manage it centrally for hundreds and thousands of
installations. But that can be done, I know a company that does that for
living.

S

What about Dll Hijacking ?