For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

CGI's avatar
CGI
Icon for Altostratus rankAltostratus
Dec 09, 2020

F5 Bigip and CVE-2020-1971

Anyone know the status of F5 Bigip LTM version 15.1 and CVE-2020-1971, is there any changes required or is the F5 not affected by this bug ?   /Craig
BIG-IP
LTM
security
MegaZone's avatar
MegaZone
Icon for SIRT rankSIRT
Jan 22, 2021

The Security Advisory was published last week: https://support.f5.com/csp/article/K42910051

 

As far as I know, the only mitigation is ingesting only trusted CRLs.

Tom_Schaefer's avatar
Tom_Schaefer
Icon for Cirrus rankCirrus
Jan 22, 2021

I believe dealing with CRLs has more to do with what the functions was supposed to do. Looking at the description (and the code for the openssl fix), it would seem a mitigation would be to compare the type before the TLS session is created. I was thinking that an iRule with code handling the CLIENTSSL_CLIENTHELLO

event could use SSL::extensions to check if both GENERAL_NAMEs contain an EDIPARTYNAME (which is what triggers the error).

 

I do not know enough yet on how to dig into the type to check it yet. I also do not know for certain doing this in an iRule catches it early enough.

 

Obviously the best solution is for F5 to adopt the OpenSSL fix in OpenSSL 1.1.1i or OpenSSL 1.0.2x.