> From: openssl-users <openssl-users-boun...@openssl.org> on behalf of 
> Steven_M.irc via openssl-users <openssl-users@openssl.org>
> Sent: Monday, November 21, 2022 15:56
 
> However, I am running Windows 10, and since (unlike Linux) every piece of 
> software outside of Windows itself
> needs to be updated individually, I don't know how to track down every single 
> application that might be using
> OpenSSL and make sure that the copy of OpenSSL it uses is up-to-date.

You don't. There may be applications that have OpenSSL linked statically, or 
linked into one of its own DLLs, or just with the OpenSSL DLLs renamed.

> As many of you would know, under repository-based systems (such as most Linux 
> distros), this would not be an
> issue as I could update every single application (system or non-system) at 
> once.

This is not true in the general case. There are applications which are 
available on Linux which do not use the distribution's package manager. There 
are applications which use their own OpenSSL build, possibly linked statically 
or linked into one of their own shared objects or with the OpenSSL shared 
objects renamed. Linux distributions have not magically solved the problem of 
keeping all software on the system current.


Back to Windows: It is possible, with relatively little effort, to find all the 
copies of the OpenSSL DLLs under their usual names on a system, and then glean 
from them their version information. With significantly more effort, you can 
search for exported OpenSSL symbols within third-party binaries, which will 
detect some more instances. With quite a lot of additional effort, you can 
winkle out binaries which contain significant portions of code matching some 
OpenSSL release (see various research efforts on function-point and code-block 
matching, and compare with alignment strategies in other fields, such as 
genomics). If your definition of "OpenSSL in an application" is not too 
ambitious, this might even be feasible.

But to what end? Each application will either be well-supported, in which case 
you can find out from the vendor what OpenSSL version it contains and whether 
an update is available; or it is not, in which you'll be out of luck.

This is true of essentially every software component, most of which are not as 
well-maintained or monitored as OpenSSL. Modern software development is mostly 
a haphazard hodgepodge of accumulating software of uncertain provenance and 
little trustworthiness into enormous systems with unpredictable behavior and 
failure modes. I'm not sure OpenSSL versions should be particularly high on 
anyone's priority list.

What are you actually trying to accomplish? What's your task? Your threat model?

-- 
Michael Wojcik

Reply via email to