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

5 Replies

Sort By
  • MegaZone's avatar
    MegaZone
    Icon for SIRT rankSIRT
    Dec 09, 2020

    As this is a fairly new CVE I recommend opening a support case to get an official answer.

  • jaikumar_f5's avatar
    jaikumar_f5
    Icon for MVP rankMVP
    Dec 10, 2020

    From the articles I read - The high risk vulnerability is affected on Openssl 1.1.1 & 1.0.2 versions. F5 v15 is running on 1.0.2, so yes this version might be affected.

    ​

    Fixed in 1.1.1l​.

    ​

    We should wait for an official confirmation on this.​

    ​

  • Tom_Schaefer's avatar
    Tom_Schaefer
    Icon for Cirrus rankCirrus
    Jan 21, 2021

    We did open a support case 6 weeks ago now. The F5 answer was they are evaluating it and we should just keep checking for HotFixes or other content to see if there will be a change. My security folks are not very pleased with that answer so I hope this is reviewed faster. We just pinged the case again yesterday but they are itching to close it since they have no response.

     

    I would settle for a workaround but I believe doing anything in an iRule would be too late in the process when using TLS in the BIG-IP.

    • 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.