|
|
This was a security hole that has been there for a while, but the
public awareness have recently rised so the threat is more imminent
now.
The solution is to fix all places where we dynamically load system
libraries. More specifically, we now load all system libraries with
an absolute path that points to a library in the system directory
(usually c:\windows\system32).
We therefore introduce a small class named QSystemLibrary that only loads
libraries located in the system path. This shares some of the API with
QLibrary (in order to make the patch as small as possible).
We don't fix QLibrary due to risk of regressions. In
addition, applications can fix the code that calls QLibrary themselves.
The problem does not apply to Windows CE, since the search order is
documented as not searching in the current directory.
However, it touches some CE-specific code - therefore QSystemLibrary
is sometimes used on WinCE (however, it will just do a normal
LoadLibrary() since its safe anyway).
This change does not affect the testability plugin (it is not clearly
documented where that plugin is located, and the plugin should never
be used in production code anyway)
Loading OpenSSL libraries
The ssl libraries are handled specially, and searched in this order
(we cannot expect them to always be in the system folder):
1. Application path
2. System libraries path
3. Trying all paths inside the PATH environment variable
Task-number: QT-3825
Reviewed-by: Thiago Macieira
Reviewed-by: Peter Hartmann
|
