Veeam Agent for Linux - CVE-2023-38545 & CVE-2023-38546

[RussellEquinix]

Veeam Agent for Linux (All Versions?) is currently vulnerable to CVE-2023-38545 & CVE-2023-38546 as it distributes a version of LibCurl that is under 8.4.0.
E.g. Veeam Agent For Linux 6.1.0.1498 uses LibCurl v.7.79.1 in the following location; /opt/veeam/transport/vddk_7_0/lib64/libcurl.so.4

CVE-2023-38545 (https://nvd.nist.gov/vuln/detail/CVE-2023-38545) - This CVE is a 9.8 Critical but Veeam Support have been saying this is under analysis for over a month now, when can we expect some sort of resolution for this?

CVE-2023-38546 (https://nvd.nist.gov/vuln/detail/CVE-2023-38546)

Support Cases: 07042296 & 06399980

[Gostev]

Veeam products are not vulnerable to CVE-2023-38545 because the vulnerability is in SOCKS5 proxy handshake process, but we do not use SOCKS5 in any shape or form for communication between our components.

CVE-2023-38546 is a low-severity vulnerability which requires local access to the system with sufficient access to create specific, named files. In the presence of an attacker who have obtained local access and such privileges, the additional risk posed by this vulnerability is negligible (there's simply no reason to exploit this particular vulnerability at this point).

Nevertheless, we do plan to get rid of the component that brings this library over (VMware VDDK) in future VBR release. It's not actually a part of Veeam Agent for Linux (VAL) and you won't find it in its distributive. Rather, it is something installed by the Agent Management functionality as a part of the shared Transport package. It's not a very simple change as we will need to create and deploy different packages depending on a situation, instead of the same single package for every situation.

Importantly, VDDK is never actually used by managed VAL. It is only ever invoked by our code if the Linux server you're protecting with VAL is also acting as a VMware backup proxy. In every other case, VDDK files are nothing but a dead weight on your file system (and can be safely deleted if desired).

[RussellEquinix]

Thank you for your confirmation Gostev

[RussellEquinix]

Importantly, VDDK is never actually used by managed VAL. It is only ever invoked by our code if the Linux server you're protecting with VAL is also acting as a VMware backup proxy. In every other case, VDDK files are nothing but a dead weight on your file system (and can be safely deleted if desired).

Could you confirm this applies to all the VDDK transport files?

/opt/veeam/transport/vddk_6_0
/opt/veeam/transport/vddk_6_7
/opt/veeam/transport/vddk_7_0

[Gostev]

Confirming.

[Gostev]

And the same in a more official form > https://www.veeam.com/kb4523