[Interest] libeay32.dll - The Ordinal 4369 could not be located

Bo Thorsen bthorsen at ics.com
Mon Jan 27 16:15:26 CET 2014


Hi Till,

It looks to me like the discussion you are bringing up here has several 
different questions:

1) How can we protect a Qt binary from picking up a bad ssl library - 
for example a wrong version?

2) How can we protect a Qt binary against an attack with a hacked ssl 
library?

3) What is the correct procedure when scanning for the ssl library?

To me this looks like the correct answers depend a lot on the answer to 
number 2. As we will not have a statically linked OpenSSL with 
commercial Qt apps, currently we have no choice but to deliver the two 
dll files. That means the question no longer can be a security issue, 
since we can't solve that.

So number 3 and 1 becomes one question. My argument that we should 
recompile Qt without ssl support is the proper solution to avoid a Qt 
app, that we didn't intend to use ssl, picking up the library anyway. 
But it would be nice if qt.conf had a "disallow ssl" option. Then it's 
easy to avoid a crash from a bad ssl library picked up from somewhere else.

It would be great if we could have trusted plugins that are 
cryptographically signed so my application could be shipped with a 
public key and check plugins. This would solve the security problem as 
well. It should be possible to create one that links statically to 
OpenSSL and ship that. I think. The license of OpenSSL is pretty annoying.

Bo.

-- 
Bo Thorsen, European Engineering Manager, ICS
Integrated Computer Solutions. Delivering World-Class Applications
http://ics.com/services



More information about the Interest mailing list