Just for everyone’s reference, you cannot manually update / replace the OpenSSL binaries in Veeam (and most applications) without likely introducing breaking changes.
Such changes need to be tested and validated against our other parts of the product first to ensure no breaking changes were introduced by the update, so a drop-in update is not possible (and I am 99.9% sure you will get a DLL validation error from the product, we check to make sure that the binaries trying to be called are the ones we actually distributed / tested)
Checking with Support is the correct answer.
Purely my speculation (so this is NOT an official answer), but since this CVE appears to only affect 32 bit systems, I’m doubtful it applies to most products as I don’t think we have to many 32-bit binaries out there anymore and similarly I don’t think there are too many 32-bit systems like the first post tells:
Description:A heap buffer overflow from converting large OCTET STRINGs to hex on 32 bit OpenSSL may crash or allow code execution; caused by 32 bit multiplication overflow; affects non FIPS OpenSSL 3.x on 32 bit systems.
Regardless, it’s best to check with Support first, changing the binaries manually is never a good idea.
A hint: many vulnerability scanners check systems exclusively by finding the binary and parsing out the version, which is not always reliable to tell if you’re actually impacted by a CVE. It’s best to read the CVE carefully and check the conditions to understand if you’re really impacted, as you can get some outrageous and scary results from these scanners when in fact you’re not affected. (e.g., one client I work with that has 10’s of thousands of agents got a spooky scan result telling they had 45 thousand vulnerabilities because the scanner flagged a CVE exclusive to Veeam v13 on their v12 environment; this is because the scanner only checked (is version < version CVE patched in?), so entire report was basically a senseless heart attack for the poor backup admins)
