OpenVPN
backport the security patch of CVE-2024-28882
Here is a vulnerability which is fixed in the master branch https://github.com/OpenVPN/openvpn/commit/55bb3260c12bae33b6a8eac73cbb6972f8517411, but is not fixed in the branch of release/2.5, maybe it should be backported?
OpenVPN 2.5.x is git only and only critical security fixes at this point. See also https://community.openvpn.net/openvpn/wiki/SupportedVersions
When we fixed this in 2.6.x we did not consider this critical enough to also patch 2.5.x as well. Is there a reason that you consider this critical?
Also we recommend to use 2.6.x.
For clarification about the criticality. While the functionschedule_exit in 2.5.x also has the same behaviour as in 2.6.x that calling it multiple times will reset the timeout, the functionality of command channel exit notification is not present in 2.5.x, so there is no known way to exploit this in behaviour in 2.5.x And backporting this fix with that knowledge did go over security fix for 2.5.x bar. If 2.5.x was the current stable, we probalby would backport this fix from master as it is a bug fix.
For clarification about the criticality. While the function
schedule_exitin 2.5.x also has the same behaviour as in 2.6.x that calling it multiple times will reset the timeout, the functionality of command channel exit notification is not present in 2.5.x, so there is no known way to exploit this in behaviour in 2.5.x And backporting this fix with that knowledge did go over security fix for 2.5.x bar. If 2.5.x was the current stable, we probalby would backport this fix from master as it is a bug fix.
so maybe you will backport this fix? l am aware that there are stilmany users relying on the 2.5.x version, so ensuring the security of this version is crucial for us and for other users.
so maybe you will backport this fix? l am aware that there are stilmany users relying on the 2.5.x version, so ensuring the security of this version is crucial for us and for other users.
This is not exploitable, so this is not a security bugfix as far as 2.5 is concerned, just "a minor bug".
We do not backport "minor bug" fixes to releases that are out of full maintenance, see the link @schwabe has posted.
I wouldn't say it's not exploitable in all scenarios. It's certainly not as exploitable as in 2.6! However, it would require a very specific setup using the management interface where the adversary can trigger certain management commands at will. In my opinion this scenario is bordering improper usage of the management interface. With these nuances I think there are good arguments for why this is not a *critical' security bug in 2.5.x
I was trying to avoid going into the discussion "but an adversary could do things via the management interface" :-) - indeed, but that would open much bigger issues than "keeping a connection online that should be terminated", and would need a very particular setup which does not happen in a "standard deployment" (client GUI usage of the management-interface, or server usage where management is either not enabled by default, or already has "something" taking care of it)...
