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