Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP APM
Known Affected Versions:
10.1.0, 10.2.4, 11.0.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5, 11.6.0 HF6, 11.6.0 HF7, 11.6.0 HF8, 11.5.1 HF1, 11.6.1 HF1, 11.5.1 HF2, 11.6.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.1 HF10, 11.5.1 HF11, 11.5.2 HF1, 11.6.2 HF1, 11.5.3 HF1, 11.5.3 HF2, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.1.0, 11.2.0, 11.2.1, 11.4.0, 11.4.1, 11.5.0, 11.5.1, 11.5.2, 11.5.3, 11.5.4, 11.5.5, 11.5.6, 11.5.7, 11.5.8, 11.5.9, 11.5.10, 11.6.0, 11.6.1, 11.6.2, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3, 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
Fixed In:
12.1.0
Opened: Jun 02, 2015 Severity: 3-Major
Access does not always properly enforce maximum sessions per user. Assume the maximum sessions per user limit is set to N > 0, for some K > 0, the user begins with N-K active sessions, and there are at least two CPUs (two TMMs). If for X > 0, a user attempts simultaneous access from K+X different devices, it is possible the user ends with N+X active sessions. The problem is most easily noticed when attempting to enforce N=1, in which it is possible for a user to have 2 (or more) active sessions.
The maximum sessions per user is not properly enforced as expected.
This happens in a Secure Web Gateway configuration with IP address-based credentials. The likelihood of encountering this issue is higher if there are more TMMs. The user either coincidentally or maliciously attempts simultaneous access from multiple devices.
An iRule can be written to manually enforce the session limit on a subsequent request.
ACCESS was not waiting for the response of an asynchronous operation before enforcing the max, which created a race condition. ACCESS now waits for the response before enforcing the max.