Any way we can update the OpenSSL manually or should we wait for VMWare to update the libraries?
I tried the latest version 3.1 from other product which has the same dll names, but VMWare fails to load 
Some details.
In the host, locations:
C:\Program Files (x86)\VMware\VMware Workstation and C:\Program Files (x86)\VMware\VMware VIX\Workstation-17.0.0\32bit
The files in libcrypto-1_1.dll and libssl-1_1.dll are still version 1.1.1q
In the location C:\Program Files (x86)\VMware\VMware VIX\Workstation-17.0.0\64bit
The files libcrypto-1_1-x64.dll and libssl-1_1-x64.dll are also still version 1.1.1q The lastest version is 1.1.1t
In the guest, vmware tools, location C:\Program Files\VMware\VMware Tools\VMware VGAuth
The files libcrypto-3-x64.dll and libssl-3-x64.dll are still versions 3.0.7 The lastest version is 3.1.0
Security fixes in version 1.1.1t
Changes between 1.1.1s and 1.1.1t [7 Feb 2023]
*) Fixed X.400 address type confusion in X.509 GeneralName.
There is a type confusion vulnerability relating to X.400 address processing
inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING
but subsequently interpreted by GENERAL_NAME_cmp as an ASN1_TYPE. This
vulnerability may allow an attacker who can provide a certificate chain and
CRL (neither of which need have a valid signature) to pass arbitrary
pointers to a memcmp call, creating a possible read primitive, subject to
some constraints. Refer to the advisory for more information. Thanks to
David Benjamin for discovering this issue. (CVE-2023-0286)
This issue has been fixed by changing the public header file definition of
GENERAL_NAME so that x400Address reflects the implementation. It was not
possible for any existing application to successfully use the existing
definition; however, if any application references the x400Address field
(e.g. in dead code), note that the type of this field has changed. There is
no ABI change.
[Hugo Landau]
*) Fixed Use-after-free following BIO_new_NDEF.
The public API function BIO_new_NDEF is a helper function used for
streaming ASN.1 data via a BIO. It is primarily used internally to OpenSSL
to support the SMIME, CMS and PKCS7 streaming capabilities, but may also
be called directly by end user applications.
The function receives a BIO from the caller, prepends a new BIO_f_asn1
filter BIO onto the front of it to form a BIO chain, and then returns
the new head of the BIO chain to the caller. Under certain conditions,
for example if a CMS recipient public key is invalid, the new filter BIO
is freed and the function returns a NULL result indicating a failure.
However, in this case, the BIO chain is not properly cleaned up and the
BIO passed by the caller still retains internal pointers to the previously
freed filter BIO. If the caller then goes on to call BIO_pop() on the BIO
then a use-after-free will occur. This will most likely result in a crash.
(CVE-2023-0215)
[Viktor Dukhovni, Matt Caswell]
*) Fixed Double free after calling PEM_read_bio_ex.
The function PEM_read_bio_ex() reads a PEM file from a BIO and parses and
decodes the "name" (e.g. "CERTIFICATE"), any header data and the payload
data. If the function succeeds then the "name_out", "header" and "data"
arguments are populated with pointers to buffers containing the relevant
decoded data. The caller is responsible for freeing those buffers. It is
possible to construct a PEM file that results in 0 bytes of payload data.
In this case PEM_read_bio_ex() will return a failure code but will populate
the header argument with a pointer to a buffer that has already been freed.
If the caller also frees this buffer then a double free will occur. This
will most likely lead to a crash.
The functions PEM_read_bio() and PEM_read() are simple wrappers around
PEM_read_bio_ex() and therefore these functions are also directly affected.
These functions are also called indirectly by a number of other OpenSSL
functions including PEM_X509_INFO_read_bio_ex() and
SSL_CTX_use_serverinfo_file() which are also vulnerable. Some OpenSSL
internal uses of these functions are not vulnerable because the caller does
not free the header argument if PEM_read_bio_ex() returns a failure code.
(CVE-2022-4450)
[Kurt Roeckx, Matt Caswell]
*) Fixed Timing Oracle in RSA Decryption.
A timing based side channel exists in the OpenSSL RSA Decryption
implementation which could be sufficient to recover a plaintext across
a network in a Bleichenbacher style attack. To achieve a successful
decryption an attacker would have to be able to send a very large number
of trial messages for decryption. The vulnerability affects all RSA padding
modes: PKCS#1 v1.5, RSA-OEAP and RSASVE.
(CVE-2022-4304)
[Dmitry Belyavsky, Hubert Kario]
Changes between 1.1.1r and 1.1.1s [1 Nov 2022]
*) Fixed a regression introduced in 1.1.1r version not refreshing the
certificate data to be signed before signing the certificate.
[Gibeom Gwon]
Changes between 1.1.1q and 1.1.1r [11 Oct 2022]
*) Fixed the linux-mips64 Configure target which was missing the
SIXTY_FOUR_BIT bn_ops flag. This was causing heap corruption on that
platform.
[Adam Joseph]
*) Fixed a strict aliasing problem in bn_nist. Clang-14 optimisation was
causing incorrect results in some cases as a result.
[Paul Dale]
*) Fixed SSL_pending() and SSL_has_pending() with DTLS which were failing to
report correct results in some cases
[Matt Caswell]
*) Fixed a regression introduced in 1.1.1o for re-signing certificates with
different key sizes
[Todd Short]
*) Added the loongarch64 target
[Shi Pujin]
*) Fixed a DRBG seed propagation thread safety issue
[Bernd Edlinger]
*) Fixed a memory leak in tls13_generate_secret
[Bernd Edlinger]
*) Fixed reported performance degradation on aarch64. Restored the
implementation prior to commit 2621751 ("aes/asm/aesv8-armx.pl: avoid
32-bit lane assignment in CTR mode") for 64bit targets only, since it is
reportedly 2-17% slower and the silicon errata only affects 32bit targets.
The new algorithm is still used for 32 bit targets.
[Bernd Edlinger]
*) Added a missing header for memcmp that caused compilation failure on some
platforms
[Gregor Jasny]
### Changes between 3.0.7 and 3.0.8 [7 Feb 2023]
* Fixed NULL dereference during PKCS7 data verification.
A NULL pointer can be dereferenced when signatures are being
verified on PKCS7 signed or signedAndEnveloped data. In case the hash
algorithm used for the signature is known to the OpenSSL library but
the implementation of the hash algorithm is not available the digest
initialization will fail. There is a missing check for the return
value from the initialization function which later leads to invalid
usage of the digest API most likely leading to a crash.
([CVE-2023-0401])
PKCS7 data is processed by the SMIME library calls and also by the
time stamp (TS) library calls. The TLS implementation in OpenSSL does
not call these functions however third party applications would be
affected if they call these functions to verify signatures on untrusted
data.
*Tomáš Mráz*
* Fixed X.400 address type confusion in X.509 GeneralName.
There is a type confusion vulnerability relating to X.400 address processing
inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING
but the public structure definition for GENERAL_NAME incorrectly specified
the type of the x400Address field as ASN1_TYPE. This field is subsequently
interpreted by the OpenSSL function GENERAL_NAME_cmp as an ASN1_TYPE rather
than an ASN1_STRING.
When CRL checking is enabled (i.e. the application sets the
X509_V_FLAG_CRL_CHECK flag), this vulnerability may allow an attacker to
pass arbitrary pointers to a memcmp call, enabling them to read memory
contents or enact a denial of service.
([CVE-2023-0286])
*Hugo Landau*
* Fixed NULL dereference validating DSA public key.
An invalid pointer dereference on read can be triggered when an
application tries to check a malformed DSA public key by the
EVP_PKEY_public_check() function. This will most likely lead
to an application crash. This function can be called on public
keys supplied from untrusted sources which could allow an attacker
to cause a denial of service attack.
The TLS implementation in OpenSSL does not call this function
but applications might call the function if there are additional
security requirements imposed by standards such as FIPS 140-3.
([CVE-2023-0217])
*Shane Lontis, Tomáš Mráz*
* Fixed Invalid pointer dereference in d2i_PKCS7 functions.
An invalid pointer dereference on read can be triggered when an
application tries to load malformed PKCS7 data with the
d2i_PKCS7(), d2i_PKCS7_bio() or d2i_PKCS7_fp() functions.
The result of the dereference is an application crash which could
lead to a denial of service attack. The TLS implementation in OpenSSL
does not call this function however third party applications might
call these functions on untrusted data.
([CVE-2023-0216])
*Tomáš Mráz*
* Fixed Use-after-free following BIO_new_NDEF.
The public API function BIO_new_NDEF is a helper function used for
streaming ASN.1 data via a BIO. It is primarily used internally to OpenSSL
to support the SMIME, CMS and PKCS7 streaming capabilities, but may also
be called directly by end user applications.
The function receives a BIO from the caller, prepends a new BIO_f_asn1
filter BIO onto the front of it to form a BIO chain, and then returns
the new head of the BIO chain to the caller. Under certain conditions,
for example if a CMS recipient public key is invalid, the new filter BIO
is freed and the function returns a NULL result indicating a failure.
However, in this case, the BIO chain is not properly cleaned up and the
BIO passed by the caller still retains internal pointers to the previously
freed filter BIO. If the caller then goes on to call BIO_pop() on the BIO
then a use-after-free will occur. This will most likely result in a crash.
([CVE-2023-0215])
*Viktor Dukhovni, Matt Caswell*
* Fixed Double free after calling PEM_read_bio_ex.
The function PEM_read_bio_ex() reads a PEM file from a BIO and parses and
decodes the "name" (e.g. "CERTIFICATE"), any header data and the payload
data. If the function succeeds then the "name_out", "header" and "data"
arguments are populated with pointers to buffers containing the relevant
decoded data. The caller is responsible for freeing those buffers. It is
possible to construct a PEM file that results in 0 bytes of payload data.
In this case PEM_read_bio_ex() will return a failure code but will populate
the header argument with a pointer to a buffer that has already been freed.
If the caller also frees this buffer then a double free will occur. This
will most likely lead to a crash.
The functions PEM_read_bio() and PEM_read() are simple wrappers around
PEM_read_bio_ex() and therefore these functions are also directly affected.
These functions are also called indirectly by a number of other OpenSSL
functions including PEM_X509_INFO_read_bio_ex() and
SSL_CTX_use_serverinfo_file() which are also vulnerable. Some OpenSSL
internal uses of these functions are not vulnerable because the caller does
not free the header argument if PEM_read_bio_ex() returns a failure code.
([CVE-2022-4450])
*Kurt Roeckx, Matt Caswell*
* Fixed Timing Oracle in RSA Decryption.
A timing based side channel exists in the OpenSSL RSA Decryption
implementation which could be sufficient to recover a plaintext across
a network in a Bleichenbacher style attack. To achieve a successful
decryption an attacker would have to be able to send a very large number
of trial messages for decryption. The vulnerability affects all RSA padding
modes: PKCS#1 v1.5, RSA-OEAP and RSASVE.
([CVE-2022-4304])
*Dmitry Belyavsky, Hubert Kario*
* Fixed X.509 Name Constraints Read Buffer Overflow.
A read buffer overrun can be triggered in X.509 certificate verification,
specifically in name constraint checking. The read buffer overrun might
result in a crash which could lead to a denial of service attack.
In a TLS client, this can be triggered by connecting to a malicious
server. In a TLS server, this can be triggered if the server requests
client authentication and a malicious client connects.
([CVE-2022-4203])
*Viktor Dukhovni*
* Fixed X.509 Policy Constraints Double Locking security issue.
If an X.509 certificate contains a malformed policy constraint and
policy processing is enabled, then a write lock will be taken twice
recursively. On some operating systems (most widely: Windows) this
results in a denial of service when the affected process hangs. Policy
processing being enabled on a publicly facing server is not considered
to be a common setup.
([CVE-2022-3996])
*Paul Dale*
* Our provider implementations of `OSSL_FUNC_KEYMGMT_EXPORT` and
`OSSL_FUNC_KEYMGMT_GET_PARAMS` for EC and SM2 keys now honor
`OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT` as set (and
default to `POINT_CONVERSION_UNCOMPRESSED`) when exporting
`OSSL_PKEY_PARAM_PUB_KEY`, instead of unconditionally using
`POINT_CONVERSION_COMPRESSED` as in previous 3.x releases.
For symmetry, our implementation of `EVP_PKEY_ASN1_METHOD->export_to`
for legacy EC and SM2 keys is also changed similarly to honor the
equivalent conversion format flag as specified in the underlying
`EC_KEY` object being exported to a provider, when this function is
called through `EVP_PKEY_export()`.
*Nicola Tuveri*
And there are new version 3.1 https://www.openssl.org/news/cl31.txt and 3.2 https://www.openssl.org/news/changelog.txt
@jen2 wrote:Although the things you wrote are the most ridiculous I have ever read when it comes to IT, I really hope it is true (NOT). But here is a hint, not even kids in primary schools will buy it.
So you are claiming using an old version of encrypting communication of an old branch that is reaching its end of life is not a security risk until proven to the contrary? I really hope you know what you are even talking about.
I really wonder, do you even know what is OpenSSL?
BTW talking in aggressive manner will only prove that you have a weak case and no strong argument!
A volunteer is trying to help and explain what the process is to get this sorted and that's YOUR reaction?
BTW, you can't drop in an openSSL v3 DLL in place of a v1 one as the API is completely different....
--
Wil
