Uploaded image for project: 'vpp'
  1. vpp
  2. VPP-2037

CVE-2022-46397 FD.io VPP (Vector Packet Processor) IPSec generates a predictable IV in AES-CBC mode

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Open
    • Icon: Highest Highest
    • None
    • None
    • IPsec
    • None

      From: Benoit Ganne (bganne) via lists.fd.io <bganne=cisco.com@lists.fd.io>
      Subject: aes cbc ipsec vulnerability in VPP? (and DPDK?)
      Reply-To: bganne@cisco.com

      Hello fd.io Security Team,

      I think we have a vulnerability in VPP IPsec AES-CBC encryption. In a nutshell, we generate a predictable IV for CBC mode [0] when using the ipsecmb or native crypto backends:

      • VPP IPsec ESP encrypt let the crypto backend to initialize the IV for all modes apart from CTR and GCM - especially CBC [1]
      • both NIST SP 800-38a Appendix C [2] and RFC-3602 (AES-CBC Cipher Algorithm Use with IPsec) [3] state that CBC IV must be chosen so that an attacker cannot predict it
      • OpenSSL crypto backend use RAND_bytes() to generate the IV [4], which is a CSPRNG [5], so this looks fine
      • ipsecmb [6] and native [7] crypto backends generate a stream of IVs by "chaining" them using a round of AES. This is fully predictable: by capturing 1 IV (which transits in clear in the ESP) you can predict the full stream of IV for all the subsequent packets

      There are several ways of fixing it. I experimented with (but there might be other solutions too):

      • https://gerrit.fd.io/r/c/vpp/+/34965 which tried to kill 2 birds with 1 stone: fix the CBC issue and improve the usage of CTR and GCM with PSK
      • use a simpler version of the above to just fix CBC (so no PRNG)
      • use RDRAND to generate random IVs but that's extremely slow (RDRAND is high latency)
      • implement FIPS DRBG-CTR to generate random IVs: faster but a bit complex. However, we can claim we follow FIPS recommendations

      Also, I think DPDK has the same issue: they seem to use packet counter as IV [8] [9]. We do not use that code so this does not really concern fd.io directly, but as it might be a similar issue in a similar project, I feel like we should coordinate with them.

      Best,
      ben

      [0] https://cwe.mitre.org/data/definitions/329.html
      [1] https://git.fd.io/vpp/tree/src/vnet/ipsec/esp_encrypt.c#n405
      [2] https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf
      [3] https://www.rfc-editor.org/rfc/rfc3602#section-3
      [4] https://git.fd.io/vpp/tree/src/plugins/crypto_openssl/main.c#n107
      [5] https://www.openssl.org/docs/manmaster/man3/RAND_bytes.html
      [6] https://git.fd.io/vpp/tree/src/plugins/crypto_ipsecmb/ipsecmb.c#n246
      [7] https://git.fd.io/vpp/tree/src/plugins/crypto_native/aes_cbc.c#n273
      [8] http://git.dpdk.org/dpdk/tree/lib/ipsec/esp_outb.c#n315
      [9] http://git.dpdk.org/dpdk/tree/lib/ipsec/crypto.h#n206

            dwallacelf Dave Wallace
            dwallacelf Dave Wallace
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: