From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: CVE issue flagged in OpenVPN Date: Mon, 08 Nov 2021 17:48:29 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7542503178865403726==" List-Id: --===============7542503178865403726== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, On 08/11/2021 17:25, Michael Tremer wrote: > Hello Adolf, >=20 > Thank you for raising this. >=20 >> On 8 Nov 2021, at 13:59, Adolf Belka wrote: >> >> Hallo all, >> >> I had thought, from checks I had made, that there were no security related= issues with OpenVPN after the release of 2.5.0 that is currently in IPFire. >> >> However it has been highlighted in the forum that there is CVE-2020-15078.= I have had a look at this and very specific conditions have to be in place f= or this to be feasible. >=20 > IPFire systems should not be vulnerable in any configuration because we do = not use the affected feature. However, we should of course still upgrade to a= fixed version. >=20 >> So I believe that for the majority of IPFire users this will not be an iss= ue but it could occur if someone is also using one of the OpenVPN plug-ins th= at are highlighted in the wiki and is also using "--auth-gen-token" or a user= -specific token auth solution. >> >> While the above is unlikely it is not impossible. A fix for this CVE was p= ut into 2.5.2 >> >> I have looked through this release and 2.5.1 to see if there are any chang= es that might cause a problem for people using earlier features. I don't beli= eve so from first glance but I am not 100% sure. I would want to very thoroug= hly test it to be sure there would be no unexpected impact. >> >> Therefore what I am doing is an update that leaves the 2.5.0 source file b= eing used but where I will apply the patches from the commits in 2.5.2 that f= ix this CVE. >=20 > We could in theory cherry-pick just the fix for the vulnerability, but on t= he other hand I do not see anything that has DEPRECATION WARNING in big lette= rs. >=20 > Also 2.5.4 is out already: https://github.com/OpenVPN/openvpn/releases/tag/= v2.5.4 >=20 >> This will give us a quick fix to the CVE in IPFire so even any small chanc= e is closed and then I will look more closely at the later/latest versions an= d build them and test them to see if I can find any issue, similarly to how E= rik and I tested out that 2.5.0 would not break anything. This way we can tak= e time to make sure everything is really working as expected. >> >> >> If there is any disagreement to my outlined approach above, please let me = know. >> >> PS:- I have also found why I missed the the existence of the CVE. I was on= ly reading the headlines of the changes from 2.4 to 2.5.4 and the CVE's were = only mentioned in the detailed change notes from the involved versions. I kno= w better now how to keep a correct eye on the changes. >=20 > Usually this should be at least referred to at the top (=E2=80=9CIncludes s= ecurity fixes=E2=80=9D), or there should be a separate security advisory. >=20 > I would suggest trying to upgrade to 2.5.4 and see whether that introduces = any new regressions. The minor versions should not introduce any change in be= haviour. No problem. I will give 2.5.4 a go and see how it goes. Trying just the commit fixes for the CVE has just failed anyway because it co= uldn't find a member called 'multi_state' so the "simple" fix is not going to= be so "simple" anyway. >=20 > However, we are facing a lot of change with 2.6: https://community.openvpn.= net/openvpn/wiki/DeprecatedOptions Yes, just had a look at it. All those old weak ciphers will be actually remov= ed. However I would really hope no one is still using ciphers like Blowfish. Regards, Adolf. >=20 > Best, > -Michael >=20 >> >> Regards, >> >> Adolf. >> >=20 --===============7542503178865403726==--