From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: CVE issue flagged in OpenVPN Date: Wed, 10 Nov 2021 08:58:01 +0000 Message-ID: <71F6A73D-16FB-4DC1-A4C1-18A31FEC489E@ipfire.org> In-Reply-To: <749caa33-bdec-1ca2-88e1-2f675f3fa23b@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6525100599140471187==" List-Id: --===============6525100599140471187== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 9 Nov 2021, at 21:30, Adolf Belka wrote: >=20 > Hi All, >=20 > On 08/11/2021 17:48, Adolf Belka wrote: >> Hi Michael, >>=20 >> 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: >>>>=20 >>>> Hallo all, >>>>=20 >>>> I had thought, from checks I had made, that there were no security relat= ed issues with OpenVPN after the release of 2.5.0 that is currently in IPFire. >>>>=20 >>>> However it has been highlighted in the forum that there is CVE-2020-1507= 8. I have had a look at this and very specific conditions have to be in place= for this to be feasible. >>>=20 >>> IPFire systems should not be vulnerable in any configuration because we d= o 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 i= ssue but it could occur if someone is also using one of the OpenVPN plug-ins = that are highlighted in the wiki and is also using "--auth-gen-token" or a us= er-specific token auth solution. >>>>=20 >>>> While the above is unlikely it is not impossible. A fix for this CVE was= put into 2.5.2 >>>>=20 >>>> I have looked through this release and 2.5.1 to see if there are any cha= nges that might cause a problem for people using earlier features. I don't be= lieve so from first glance but I am not 100% sure. I would want to very thoro= ughly test it to be sure there would be no unexpected impact. >>>>=20 >>>> Therefore what I am doing is an update that leaves the 2.5.0 source file= being used but where I will apply the patches from the commits in 2.5.2 that= fix this CVE. >>>=20 >>> We could in theory cherry-pick just the fix for the vulnerability, but on= the other hand I do not see anything that has DEPRECATION WARNING in big let= ters. >>>=20 >>> Also 2.5.4 is out already: https://github.com/OpenVPN/openvpn/releases/ta= g/v2.5.4 >>>=20 >>>> This will give us a quick fix to the CVE in IPFire so even any small cha= nce is closed and then I will look more closely at the later/latest versions = and build them and test them to see if I can find any issue, similarly to how= Erik and I tested out that 2.5.0 would not break anything. This way we can t= ake time to make sure everything is really working as expected. >>>>=20 >>>>=20 >>>> If there is any disagreement to my outlined approach above, please let m= e know. >>>>=20 >>>> PS:- I have also found why I missed the the existence of the CVE. I was = only reading the headlines of the changes from 2.4 to 2.5.4 and the CVE's wer= e only mentioned in the detailed change notes from the involved versions. I k= now 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= security 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 introduce= s any new regressions. The minor versions should not introduce any change in = behaviour. >> 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= couldn't find a member called 'multi_state' so the "simple" fix is not going= to be so "simple" anyway. >>>=20 > Have built 2.5.4 successfully and then installed it into my vm testbed syst= em. I have run both my Android Phone ,with OpenVPN for Android app ,and my la= ptop, with Network Manager applet, and been able to connect through the vpn t= unnel with the original 2.5.0 and then also with the 2.5.4 version of OpenVPN. >=20 > The above was with AES-GCM (256 bit) encryption cipher together with SHA2 (= 512 bit) hash algorithm with the TLS Channel Protection. >=20 > Is that testing sufficient or should I also test out some of the older ciph= ers in the list like BF-CBC? I would say that this is sufficient, because if there were any deprecated con= figuration options used in our configuration file, the daemon wouldn=E2=80=99= t start, or the connection would not connect. I believe this is good enough to go on the list and we should then make a pla= n about what to do with 2.6. Thank you for working on this. -Michael >=20 > Regards, >=20 > Adolf. >=20 >>> However, we are facing a lot of change with 2.6: https://community.openvp= n.net/openvpn/wiki/DeprecatedOptions >> Yes, just had a look at it. All those old weak ciphers will be actually re= moved. However I would really hope no one is still using ciphers like Blowfis= h. >>=20 >> Regards, >> Adolf. >>>=20 >>> Best, >>> -Michael >>>=20 >>>>=20 >>>> Regards, >>>>=20 >>>> Adolf. >>>>=20 >>>=20 > --=20 > Sent from my laptop --===============6525100599140471187==--