Bug ID 525378: iRule commands do not validate session scope

Last Modified: Dec 20, 2018

Bug Tracker

Affected Product:  See more info
BIG-IP APM(all modules)

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

Opened: May 27, 2015
Severity: 3-Major

Symptoms

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.

Impact

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.

Conditions

There may be multiple access profiles assigned to multiple virtual servers, but the iRule session commands will treat all sessions the same.

Workaround

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 } } }

Fix Information

None

Behavior Change