Re: [twsocket] New DLL hijacking vulnerability KB 2269637
Arno Garrels wrote:
The DLL names are globally writable typed constants, set their values
before the OpenSSL libraries are loaded.
Is there any advantage to use writable typed constants like
const GSSLEAY_DLL_Name : String = 'SSLEAY32.DLL';
instead of
var GSSLEAY_DLL_Name : String = 'SSLEAY32.DLL';
?
Both seems to work but I try to avoid the first one whenever possible because
it can break multi-threading when not used properly. For example I had a
commercial component that contained code like this to save some code lines:
procedure SomeProc();
{$J+} // enable writeable consts
const
Buffer : array[0..31] of byte = (0, 0, ..., 0);
{$J-} // disable writeable consts
begin
// read and write to Buffer like it's a variable
end;
which caused problems when the procedure is used by different threads
simultaneously because all instances read and write to the same block in
memory.
I know this is not a problem with ICS but I wonder why writable consts are
used/preferred at all.
Regards,
Tobias
--
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
Re: [twsocket] New DLL hijacking vulnerability KB 2269637
Tobias Rapp wrote:
Arno Garrels wrote:
The DLL names are globally writable typed constants, set their values
before the OpenSSL libraries are loaded.
Is there any advantage to use writable typed constants like
const GSSLEAY_DLL_Name : String = 'SSLEAY32.DLL';
instead of
var GSSLEAY_DLL_Name : String = 'SSLEAY32.DLL';
There is no advantage IMO. According to the documentation they are
in essence initialized variables
and
In early versions of Delphi and Object Pascal, typed constants were always
writeable, corresponding to the {$J+} state. Old source code that uses
writeable typed constants must be compiled in the {$J+} state, but for new
applications it is recommended that you use initialized variables and compile
your code in the {$J-} state.
Both seems to work but I try to avoid the first one whenever possible
because it can break multi-threading when not used properly. For
example I had a commercial component that contained code like this to
save some code lines:
procedure SomeProc();
{$J+} // enable writeable consts
const
Buffer : array[0..31] of byte = (0, 0, ..., 0);
{$J-} // disable writeable consts
begin
// read and write to Buffer like it's a variable
end;
which caused problems when the procedure is used by different threads
simultaneously because all instances read and write to the same block
in memory.
Yes, but no problem in this case since you should write
the DLL names just once.
--
Arno Garrels
--
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
Re: [twsocket] New DLL hijacking vulnerability KB 2269637
I prefer this anyway since the load errors don't raise somewhere
but where I can handle them easily:
I also log the SSL version and directory at the point, since multiple SSL
DLLs may be available on the PC and like to know the expected versions
are being used:
MySslContext.InitContext;
AddLogLine ('SSL Version: ' +
OpenSslVersion + ', Dir: ' + GLIBEAY_DLL_FileName) ;
Angus
--
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
Re: [twsocket] New DLL hijacking vulnerability KB 2269637
const GSSLEAY_DLL_Name : String = 'SSLEAY32.DLL'; This is not required since writable typed constants is enabled. That's all fine but I don't see it published as property anywhere. How do I modify its value during runtime to set full path for SSLEAY32.DLL and LIBEAY32.DLL? -- 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
Re: [twsocket] New DLL hijacking vulnerability KB 2269637
const GSSLEAY_DLL_Name : String = 'SSLEAY32.DLL'; This is not required since writable typed constants is enabled. That's all fine but I don't see it published as property anywhere. How do I modify its value during runtime to set full path for SSLEAY32.DLL and LIBEAY32.DLL? So simple: Just assign GSSLEAY_DLL_Name the value you need, before it is first used. -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- 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
Re: [twsocket] New DLL hijacking vulnerability KB 2269637
Zvone wrote: const GSSLEAY_DLL_Name : String = 'SSLEAY32.DLL'; This is not required since writable typed constants is enabled. That's all fine but I don't see it published as property anywhere. How do I modify its value during runtime to set full path for SSLEAY32.DLL and LIBEAY32.DLL? The DLL names are globally writable typed constants, set their values before the OpenSSL libraries are loaded. OSSL is dynamically loaded at runtime, that is when the first OpenSSL function is called. In order to enforce a load call TSslContext.InitContext or set TSslDynamicLock/TSslStaticLock.Enabled to TRUE. I prefer this anyway since the load errors don't raise somewhere but where I can handle them easily: try GSSLEAY_DLL_Name := full path and filename; GLIBEAY_DLL_Name := full path and filename; MySslContext.InitContext; except // Something went wrong with loading OSSL, handle it. end; -- Arno Garrels -- Arno Garrels -- 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
Re: [twsocket] New DLL hijacking vulnerability KB 2269637
I think here is what we should do: - the OpsnSSL DLLs must be loaded only from process folder of the ICS-based-our-code-exe - before loading the DLLs, we must check for their presence in RAM and fire an exception in that case. Regards, SZ On Sat, Sep 4, 2010 at 10:29 AM, Francois PIETTE francois.pie...@skynet.bewrote: Maybe you could carefully read those documentation and review ICS code to see if it needs some improvement. If improvment is needed, then propose some changes. Don't forget the gold rule: change in ICS must not break any existing code. -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be - Original Message - From: Zvone pha...@gmail.com To: ICS support mailing twsocket@elists.org Sent: Saturday, September 04, 2010 1:45 AM Subject: [twsocket] New DLL hijacking vulnerability KB 2269637 It appears that this new vulnerability requires programs to adopt secure DLL loading. As Microsoft says they can't fix the issue by patching Windows as it would mess up a lot of programs so it is up to programmers to fix it in their own programs. This applies to all programs that load external libraries (DLL files) one way or another - so it applies to ICS as well as it loads SSLEAY32.DLL and other DLL's The solution is to load DLL files in a secure manner as described here: Dynamic-Link Library Security - how to load libraries securely: http://msdn.microsoft.com/en-us/library/ff919712%28VS.85%29.aspx More info about this vulnerability: Microsoft Security Advisory (2269637): http://www.microsoft.com/technet/security/advisory/2269637.mspx http://www.f-secure.com/weblog/archives/2018.html Google search on this issue: http://www.google.com/search?q=KB+2269637 -- 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 -- 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
Re: [twsocket] New DLL hijacking vulnerability KB 2269637
Forget about my remark about \ or /. The DllPath could be used as is just DllPath + LibraryName. This avoids the need to process needlessly slashes or backslashes. If this is used I would suggest a bold remark in the docs on Wiki to encourage use of this property if this is to be used. Anyway, other ideas are still welcome. -- 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
Re: [twsocket] New DLL hijacking vulnerability KB 2269637
const GSSLEAY_DLL_Name : String = 'SSLEAY32.DLL'; I think the solution is much simpler than what you think: Change const by var so that the DLL name is provided thru a global variable (by the way a global typed constant can be used as a global variable if J+ option is used which is the case in ICS). This way, the problem is moved to the component user, that is the application and that's fine for me. Probably a change in the sample programs is required to explain that. But no real change in the component. -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be - Original Message - From: Zvone pha...@gmail.com To: ICS support mailing twsocket@elists.org Sent: Saturday, September 04, 2010 3:44 PM Subject: Re: [twsocket] New DLL hijacking vulnerability KB 2269637 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 -- 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
Re: [twsocket] New DLL hijacking vulnerability KB 2269637
Francois PIETTE wrote: const GSSLEAY_DLL_Name : String = 'SSLEAY32.DLL'; I think the solution is much simpler than what you think: Change const by var so that the DLL name is provided thru a global This is not required since writable typed constants is enabled. -- Arno Garrels -- 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
