On BIG-IP versions 15.0.0-15.1.0, 14.0.0-14.1.2.3, 13.1.0-13.1.3.2, 12.1.0-12.1.5, and 11.5.2-11.6.5.1, BIG-IQ versions 7.0.0, 6.0.0-6.1.0, and 5.0.0-5.4.0, iWorkflow version 2.3.0, and Enterprise Manager version 3.1.1, authenticated users granted TMOS Shell (tmsh) privileges are able access objects on the file system which would normally be disallowed by tmsh restrictions. This allows for authenticated, low privileged attackers to access objects on the file system which would not normally be allowed.
On BIG-IP versions 15.0.0-15.0.1.1, 14.1.0-14.1.2.2, 14.0.0-14.0.1, 13.1.0-13.1.3.1, 12.1.0-12.1.5, and 11.5.2-11.6.5 and BIG-IQ versions 6.0.0-6.1.0 and 5.2.0-5.4.0, a user is able to obtain the secret that was being used to encrypt a BIG-IP UCS backup file while sending SNMP query to the BIG-IP or BIG-IQ system, however the user can not access to the UCS files.
On BIG-IP 15.0.0-15.0.1, 14.1.0-14.1.2, 14.0.0-14.0.1, 13.1.0-13.1.3.1, 12.1.0-12.1.5, and 11.5.1-11.6.5, vCMP hypervisors are incorrectly exposing the plaintext unit key for their vCMP guests on the filesystem.
The BIG-IP 15.0.0-15.0.1, 14.0.0-14.1.2.2, 13.1.0-13.1.3.1, 12.1.0-12.1.5, and 11.5.1-11.6.5.1, BIG-IQ 7.0.0, 6.0.0-6.1.0, and 5.2.0-5.4.0, iWorkflow 2.3.0, and Enterprise Manager 3.1.1 configuration utility is vulnerable to Anti DNS Pinning (DNS Rebinding) attack.
On BIG-IP 13.1.0-13.1.3.1, 12.1.0-12.1.5, and 11.5.2-11.6.5.1, a reflected cross-site scripting (XSS) vulnerability exists in an undisclosed page of the BIG-IP Traffic Management User Interface (TMUI), also known as the BIG-IP Configuration utility.
On versions 14.0.0-14.1.2, 13.0.0-13.1.3, 12.1.0-12.1.5, and 11.5.1-11.6.5, the BIG-IP system fails to perform Martian Address Filtering (As defined in RFC 1812 section 5.3.7) on the control plane (management interface). This may allow attackers on an adjacent system to force BIG-IP into processing packets with spoofed source addresses.
A vulnerability was found in OpenSSL 1.0.2. When an application encounters a fatal protocol error and then calls SSLshutdown() twice, OpenSSL can respond differently to the calling application if a 0 byte record is received with invalid padding compared to if a 0 byte record is received with an invalid MAC. This difference in behaviour can be detected by a remote peer, then this amounts to a padding oracle that could be used to decrypt data. In order for this to be exploitable "non-stitched" ciphersuites must be in use. Also the application must call SSLshutdown() twice even if a protocol error has occurred (applications should not do this but some do anyway). AEAD ciphersuites are not impacted. This issue does not impact OpenSSL 1.1.1 or 1.1.0.
Upstream bug: https://www.openssl.org/news/secadv/20190226.txt
Upstream Patch: https://github.com/openssl/openssl/commit/e9bbefbf0f24c57645e7ad6a5a71ae649d18ac8e