Bug ID 707447: Default SNI clientssl profile's sni_certsn_hash can be freed while in use by other profiles.

Last Modified: Sep 13, 2023

Affected Product(s):
BIG-IP LTM(all modules)

Known Affected Versions:
12.0.0, 12.0.0 HF1, 12.1.0 HF1, 12.0.0 HF2, 12.1.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2, 12.1.0, 12.1.1, 12.1.2, 12.1.3, 12.1.3.1, 12.1.3.2, 12.1.3.3, 12.1.3.4, 12.1.3.5, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5

Fixed In:
14.0.0, 13.1.0.6, 12.1.3.6

Opened: Feb 21, 2018

Severity: 2-Critical

Symptoms

SSL SNI mechanism creates a hash containing a mapping between SAN entries in a given profile's certificate and the profile. This hash is owned by the default SNI profile, however is held by the other profiles on the VIP without a reference. If a connection utilizes SNI to use a non-default SNI profile *and* the default SNI profile reinitializes its state for any reason, the prf->sni_certsn_hash can be cleared and freed, leaving the existing connection(s) with profiles that refer to the freed hash. If then the connection attempts a renegotiation that causes the hash to be used, the freed hash can cause a fault should it have been reused in the meantime (i.e. the contents are invalid). The fix: When the default SNI profile is initializing, and SSL handshake is searching SAN/COMMON cert from non-default SNI profile, stop the search and return NULL.

Impact

Traffic is disrupted while TMM restarts.

Conditions

SNI configured with one default SNI profile, one or multiple SNI profiles. The default SNI profile is changed and renegotiation with SNI(with non-default SNI profile) is issued.

Workaround

There is no workaround at this time.

Fix Information

When the default SNI profile is initializing, and SSL handshake is searching SAN/COMMON cert from non-default SNI profile, stop the search and return NULL.

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips