TC 7.56 issue with paths to DLLs vulnerability

[Sob]

27.08.10 Added: Check whether Total Commander is vulnerable to DLL load problem - no, not directly, but plugins may be vulnerable -> add protection

I guess this is the reason why TC 7.56 is not able to load OpenSSL dlls from directory included in PATH. It seems that now it checks only it's install directory, system directory, Windows directory, all with absolute paths and that's it.
Because the dll loading vulnerability affects only current directory, for just TC it'd be enough to change current directory to it's own before calling LoadLibrary. So the change must have something to do with this protection for plugins.
So I'm wondering, how is it supposed to work? Does it somehow prevent plugin from going into unsafe directory, calling LoadLibrary with just filename without path and suffering from vulnerability?

[ghisler(Author)]

Total Commander now does the following:
1. It calls SetDllDirectory with the path of the plugin:
http://msdn.microsoft.com/en-us/library/ms686203%28VS.85%29.aspx
2. It calls LoadLibrary with the plugin name
3. It calls SetDllDirectory with an empty string "".

This shouldn't affect loading of openssl dlls by plugins.

The loading of openssl dlls in the ftp client is indeed restricted to the TC directory now, for security reasons.

[Sob]

Total Commander now does the following:
...
This shouldn't affect loading of openssl dlls by plugins.

Right, it doesn't.

MS released fix for removing current directory from search order, but I think it's not enabled (or even installed, I'm not sure) by default. So solving it in TC is good.

The loading of openssl dlls in the ftp client is indeed restricted to the TC directory now, for security reasons.

Can't say I believe this one. ;) Why should be directories in PATH less secure than TC's directory (or Windows or system, they're searched too)? But there's not much point arguing, because even if you decided to change it, it's long time before new TC is released. Luckily for me, Windows now know symbolic links, so TC can think it's loading dlls from own directory, while I can have them elsewhere.

[ghisler(Author)]

Well, there will be a 7.56a version soon, so there is still a chance to change it. However, not to the entire path, because the path variable can be manipulated and point anywhere. But I could add other search dirs like Windows or System32 if that would help...

[Sob]

According to Process Monitor you use them already in TC 7.56. TC checks all these (in this order) before complaining about missing OpenSSL:

Code: Select all

C:\tc\install\dir\libssl32.dll
C:\tc\install\dir\ssleay32.dll
C:\tc\install\dir\libeay32.dll
C:\tc\install\dir\libssl32.dll
C:\Windows\SysWOW64\libssl32.dll
C:\Windows\libssl32.dll
C:\tc\install\dir\ssleay32.dll
C:\Windows\SysWOW64\ssleay32.dll
C:\Windows\ssleay32.dll
C:\tc\install\dir\libeay32.dll
C:\Windows\SysWOW64\libeay32.dll
C:\Windows\libeay32.dll

[ghisler(Author)]

You are indeed right, I just checked my source code. It just doesn't look in the current dir and the path any more.

[white]

The loading of openssl dlls in the ftp client is indeed restricted to the TC directory now, for security reasons.

Currently the situation seems to be as follows:
* When using the FTPS protocol the openssl dlls are also searched in folders in PATH.
* When using secure FTP plugin the openssl dlls are NOT searched in folders in PATH.

Is this correct?