Well, like I wrote, it effects all programs that use ICS. And it is a
bit harder to find a solution that fits all in this case due to nature
of the problem.
This is how ICS loads for example SSLLEAY32.DLL:
const GSSLEAY_DLL_Name : String = 'SSLEAY32.DLL';
...
GSSLEAY_DLL_Handle := LoadLibrary(PChar(GSSLEAY_DLL_Name));
If DLL is provided like this it will activate DLL search if DLL is not
present in the application directory. If it is, no big deal. But if it
isn't the next directory it moves on unless safe search is enabled in
Windows (you can't count on it) is the problematic "current
directory". If this dir is on network share then it will load DLL from
this network share (for example a user running a program over a LAN).
If attacker places a DLL in that folder and calls it "ssleay32.dll" it
can put whatever he wants and program will load it. It's not a huge
deal but it is a security breach.
MS will probably move "current directory" down the search line so that
application folder, and system folders are scanned first but this is
all they can do. They already did so with XP SP2 but the current
directory is still there only not second but fifth in the search
order.
One of the suggested solutions is to call SetDllDirectory(""); which
disables search in the current directory. This should be called early
in the initialization before doing LoadLibrary call. I'm not really
sure how much is current directory needed for DLL search - remember it
is not application directory which comes first and neither system
directories. Perhaps in certain - I would guess - rare - applications
it could be used. But this affects also the entire calling process so
this may not be something the user wants.
ICS could introduce a "SkipCurrentDir" flag somewhere when loading
that would default to "true" (for safer version) or "false" (for
non-breaking) if the above is used.
It is not a good idea to load only from app dir. A user may want to
put SSLEAY32.DLL and LIBEAY32.DLL in system folder for sharing either
with other apps or with multiple apps he uses for himself. So search
cannot be avoided by doing this as this would limit ICS more and
introduce even more breaking changes. Maybe if that one is implemented
as a flag again "LoadDLLOnlyFromCurrentDir" - true / false, then this
could work. In fact I rather like that approach personally but not
everyone might.
Maybe the best for ICS would be to introduce something like
"SslDllPath" property that would be prepended to "GSSLEAY_DLL_Name".
If left empty - it works as before so no breaking occurs. If set, it
just puts a path before GSSLEAY_DLL_Name and it is left to user to
search DLL or secure his application. A care must be taken if this
path contains "\" (filesystem path) or "/" (network path) at the end
to remove or add it to avoid slash or backslash duplication. Stricter
measure would be not to work unless this path is provided. Breaking
change yes, but this vulnerability breaks all applications so it is a
rather big breaking change for everyone altogether.
If anyone has other ideas, do share them!
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
