Last Modified: Apr 28, 2025
Affected Product(s):
BIG-IP APM
Known Affected Versions:
12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 12.1.3, 12.1.3.1, 12.1.3.2, 12.1.3.3, 12.1.3.4, 12.1.3.5, 12.1.3.6, 12.1.3.7, 12.1.4, 12.1.4.1, 12.1.5, 12.1.5.1, 12.1.5.2, 12.1.5.3, 12.1.6
Opened: May 27, 2015 Severity: 3-Major
Assume that a user establishes a session on one virtual server. If the user learns his session ID, he may attempt to reuse that session ID to gain access to resources guarded by a different virtual server. When this happens, the iRule access session commands like [ACCESS::session sid] and [ACCESS::session exists] do not validate the scope of the session. The iRules consider sessions from other virtual servers to be valid, which can cause unintended results and potentially lead to end-users gaining higher privileges than administrators intended.
If the administrator is not careful with how the iRule session commands are used, it can result in a user bypassing the access policy and receiving higher privileges than the administrator intended.
There may be multiple access profiles assigned to multiple virtual servers, but the iRule session commands will treat all sessions the same.
Care must be used to ensure that iRules using the session commands do not result in unintended behavior. An iRule similar to one below can be used to restrict a session to the virtual server on which it was created: when ACCESS_ACL_ALLOWED { set sessionlistener [ACCESS::session data get "session.server.listener.name"] set virtualname [virtual name] if { [HTTP::cookie MRHSession] != "" } { if { not ($sessionlistener equals $virtualname) } { # enter whatever command you wish to use to prevent the connection reject } } }
None