gajim windows installer ships SSLEAY32.DLL/LIBEAY32.DLL from OpenSSL 0.9.8l
The gajim windows installer has two files that seem to be a very old version of OpenSSL: LIBEAY32.dll SSLEAY32.dll
Running strings on them indicates they come from OpenSSL 0.9.8l. Obviously such an old version suffers from plenty of known vulnerabilities, 0.9.8 is out of support since a long time.
However I don't think these files are actually used. None of the other files seem to reference these files, so they may be just a leftover. _ssl.pyd seems to contain a python module from OpenSSL 1.0.1j. While this is much newer, it's still quite outdated and should be replaced with an up-to-date version.
hi, thanks for reporting
this is known, as you already mentioned these files are not used in anyway, they where used years back and nobody cared to adapt the installer script to not include them anymore, so i think no harm is done here.
we made a new installer script for the wndows version which should pull the newest versions on every release.
closedToggle commit list
Just to make sure there will be only one openssl library in future. For now there are even many of them (gajim-0.16.6-1.exe unpacked with 7zip):
gajim-0.16.6-1-unpacked$ for f in `find .`; do if [[ `strings $f | grep '^OpenSSL .\..\.'` ]]; then echo $f; strings $f | grep '^OpenSSL .\..\.'; echo; fi; done ./bin/SSLEAY32.dll OpenSSL 0.9.8l 5 Nov 2009 ./bin/cryptography.hazmat.bindings._openssl.pyd OpenSSL 1.0.2d 9 Jul 2015 OpenSSL 1.0.2d 9 Jul 2015 ./bin/LIBEAY32.dll OpenSSL 0.9.8l 5 Nov 2009 ./bin/_ssl.pyd OpenSSL 1.0.1j 15 Oct 2014
0.9.8l 5 Nov 2009 1.0.1j 15 Oct 2014 1.0.2d 9 Jul 2015
1.0.1 is not supported anymore. But even 1.0.2d has numerous fixed CVEs. The latest 1.0.2 release is
1.0.2j 26 Sep 2016
Hi, Christian Heimes from Python core security here. I saw Hanno's post on Twitter. Since your
_ssl.pydis statically linked against OpenSSL 1.0.1j, you must be running an old and outdated Python version, too. Python's ssl module is always linked against the most recent stable version of OpenSSL at the time of release. 1.0.1j was used in 2.7.9.
Please update your internal Python distribution to a more recent version. Python had a couple of security-relevant issues in the last 2 years, too.
thanks @tiran for clearing up what _ssl.pyd links against.
We use cx_freeze to ship python to our windows users, and it seems through a mistake we did not use the most current version of python. So users have no control over which python version is used.
we will use 2.7.13 on the next release so this is resolved
changed milestone to %48Toggle commit list
Updating affected status:
bin/pycurl.pyd OpenSSL 1.0.2e 3 Dec 2015
build/pycurl.pyd OpenSSL 1.0.2e 3 Dec 2015 build/libopenssl.dll OpenSSL 1.0.2g 1 Mar 2016 build/Crypto/SelfTest/PublicKey/test_vectors/ECC/openssl_version.txt OpenSSL 1.0.2e-fips 3 Dec 2015
and too old python 3.4.4 with
build/_ssl.pyd OpenSSL 1.0.2d 9 Jul 2015
we use the most current version of pycurl and cryptodome so i dont see what we can do here
libopenssl.dll is from gtk which lags behind on windows, but we dont use gtk for any ssl stuff.
in the future we will use python 3.6 for our master branch, but the python ssl module is also not used.
@ag Python doesn't have a formal process for out-of-bounce updates for OpenSSL. I talked to a release manager about the issue. Please start a discussion on python-dev list or python-security list if you are interested in a policy. I'm currently travelling and don't have time to take care of it.