Improve company productivity with a Business Account.Sign Up

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 479
  • Last Modified:

Mitigating measures for F5 LB's Ssh

I think our VA detected most Openssh vulnerabilities listed below in our
F5 loadbalancers.

Besides upgrading the IOS of the LB, what other measures we can undertake?
Any patch?  Or any IPS signature we can put in place?

===================================================

OpenSSH: Privilege Separation Monitor Weakness  
OpenSSH: Signal Handler Pre-authentication Race Condition Code Execution
OpenSSH: Trusted X11 Cookie Connection Policy Bypass  
OpenSSH: Client Rejected HostCertificate Handling Missing SSHFP Record Verification Weakness
OpenSSH: sshd Configuration AcceptEnv Wildcard Handling Remote Restriction Bypass
OpenSSH: GSSAPI Authentication Abort Username Enumeration  
OpenSSH: linux_audit_record_event Crafted Username Audit Log Injection  
OpenSSH: S/KEY Authentication Account Enumeration  
OpenSSH: logingracetime / maxstartup Threshold Connection Saturation Remote DoS
OpenSSH: libc/glob(3) resource exhaustion
OpenSSH: X11 Forwarding Local Session Hijacking
OpenSSH: ForceCommand Command Execution Weakness
OpenSSH: ssh-keysign ssh-rand-helper Utility File Descriptor Leak Local Information Disclosure
OpenSSH: post-authentication resource exhaustion bug via GSSAPI
OpenSSH: Forced Command handling leaks private information to ssh clients
OpenSSH: Cipher-Block Chaining (CBC) Mode Arbitrary Information Disclosure
0
sunhux
Asked:
sunhux
  • 7
  • 2
  • 2
5 Solutions
 
gheistCommented:
Best is to upgrade. Half of vulnerabilities are without even showing username.
0
 
giltjrCommented:
You could check F5's site and look at your level of whatever product you have and see if there are any configuration changes you can make to mitigate the vulnerabilities.

However, gheist is correct, upgrading is the best solution.
0
 
gheistCommented:
You need to say CVE number to get mitigation if at all, otherwise it is just whistling in the wind...
0
Become an IT Security Management Expert

In today’s fast-paced, digitally transformed world of business, the need to protect network data and ensure cloud privacy has never been greater. With a B.S. in Network Operations and Security, you can get the credentials it takes to become an IT security management expert.

 
gheistCommented:
CVE-2006-5794 Privilege Separation Monitor Weakness
You need software patch to address it. There is no configuration workaround
Also there is no need to look further, you should patch more often that every 8 years.
0
 
giltjrCommented:
Looking at F5's site LTM versions 10.x and newer are not vulnerable to CVE-2006-5794.  So if your F5 has that vulnerability, it means that it is some level of V9.

F5 has documentation on how to upgrade.  Depending on the exact LTM version you have, you might have to do multiple upgrades.  Example:, you can NOT go from 9.4.7 directly to any 10.x or 11.x, you have to upgrade to 9.4.8, then go to 10.x or 11.x.
0
 
gheistCommented:
0
 
sunhuxAuthor Commented:
Well, actually we're on Ver 11.2 when they scanned : so are the reported vulnerabilities false positives
or those vulnerabilities are present in Ver 11.2

We've just upgraded to 11.5 (understand the latest version 11.6 is rather buggy).

I'll dig out the CVE numbers tomorrow
0
 
gheistCommented:
Check F5 website for other CVE numbers (cve.mitre.org can convert text to CVE number). The one i checked was false positive.
Best to start with later numbers. They are more likely to yield need to patch.
0
 
sunhuxAuthor Commented:
I checked that Outpost24 VA scan reports : it did not give any CVE number but CVSS indicator
& it simply recommends to upgrade to OpenSSH Ver 6.6 or above for all the vulnerabilities it reported below.  I'm inclined to think the
scanner simply expects the latest version of OpenSSH to be available for Linux servers as it expects for appliances.

Below are what it gave for CVSS & Description columns:
(AV:N/AC:L/Au:N/C:P/I:P/A:P) (cdp:ND/td:ND/cr:ND/ir:ND/ar:ND)
(AV:N/AC:M/Au:N/C:C/I:C/A:C) (cdp:ND/td:ND/cr:ND/ir:ND/ar:ND)
(AV:N/AC:L/Au:N/C:P/I:P/A:P) (cdp:ND/td:ND/cr:ND/ir:ND/ar:ND)
(AV:N/AC:M/Au:N/C:P/I:P/A:N) (cdp:ND/td:ND/cr:ND/ir:ND/ar:ND)
(AV:N/AC:M/Au:N/C:P/I:P/A:N) (cdp:ND/td:ND/cr:ND/ir:ND/ar:ND)
(AV:N/AC:L/Au:N/C:P/I:N/A:N) (cdp:ND/td:ND/cr:ND/ir:ND/ar:ND)
(AV:N/AC:M/Au:N/C:N/I:P/A:N) (cdp:ND/td:ND/cr:ND/ir:ND/ar:ND)
(AV:N/AC:L/Au:N/C:P/I:N/A:N) (cdp:ND/td:ND/cr:ND/ir:ND/ar:ND)
(AV:N/AC:L/Au:N/C:N/I:N/A:P) (cdp:ND/td:ND/cr:ND/ir:ND/ar:ND)
(AV:N/AC:L/Au:S/C:N/I:N/A:P) (cdp:ND/td:ND/cr:ND/ir:ND/ar:ND)
(AV:L/AC:M/Au:N/C:C/I:C/A:C) (cdp:ND/td:ND/cr:ND/ir:ND/ar:ND)
(AV:N/AC:L/Au:S/C:P/I:P/A:P) (cdp:ND/td:ND/cr:ND/ir:ND/ar:ND)
(AV:L/AC:L/Au:N/C:P/I:N/A:N) (cdp:ND/td:ND/cr:ND/ir:ND/ar:ND)
(AV:N/AC:M/Au:S/C:N/I:N/A:P) (cdp:ND/td:ND/cr:ND/ir:ND/ar:ND)
(AV:N/AC:M/Au:S/C:P/I:N/A:N) (cdp:ND/td:ND/cr:ND/ir:ND/ar:ND)


Unspecified vulnerability in the sshd Privilege Separation Monitor in OpenSSH before 4.5 causes weaker verification that authentication has been successful, which might allow attackers to bypass authentication. NOTE: as of 20061108, it is believed that this issue is only exploitable by leveraging vulnerabilities in the unprivileged process, which are not known to exist.

Signal handler race condition in OpenSSH before 4.4 allows remote attackers to cause a denial of service (crash), and possibly execute arbitrary code if GSSAPI authentication is enabled, via unspecified vectors that lead to a double-free.

ssh in OpenSSH before 4.7 does not properly handle when an untrusted cookie cannot be created and uses a trusted X11 cookie instead, which allows attackers to violate intended policy and gain privileges by causing an X client to be treated as trusted.

The verify_host_key function in sshconnect.c in the client in OpenSSH allows remote servers to trigger the skipping of SSHFP DNS RR checking by presenting an unacceptable HostCertificate.

sshd in OpenSSH does not properly support wildcards on AcceptEnv lines in sshd_config, which allows remote attackers to bypass intended environment restrictions by using a substring located before a wildcard character.

Unspecified vulnerability in portable OpenSSH before 4.4, when running on some platforms, allows remote attackers to determine the validity of usernames via unknown vectors involving a GSSAPI "authentication abort."

Unspecified vulnerability in the linux_audit_record_event function in OpenSSH 4.3p2, as used on Fedora Core 6 and possibly other systems, allows remote attackers to write arbitrary characters to an audit log via a crafted username.  NOTE: some of these details are obtained from third party information.

OpenSSH 4.6 and earlier, when ChallengeResponseAuthentication is enabled, allows remote attackers to determine the existence of user accounts by attempting to authenticate via S/KEY, which displays a different response if the user account exists, a similar issue to CVE-2001-1483.

The default configuration of OpenSSH enforces a fixed time limit between establishing a TCP connection and completing a login, which makes it easier for remote attackers to cause a denial of service (connection-slot exhaustion) by periodically making many new TCP connections.

The (1) remote_glob function in sftp-glob.c and the (2) process_put function in sftp.c allow remote authenticated users to cause a denial of service (CPU and memory consumption) via crafted glob expressions that do not match any pathnames, as demonstrated by glob expressions in SSH_FXP_STAT requests to an sftp daemon, a different vulnerability than CVE-2010-2632.

OpenSSH allows local users to hijack forwarded X connections by causing ssh to set DISPLAY to :10, even when another process is listening on the associated port, as demonstrated by opening TCP port 6010 (IPv4) and sniffing a cookie sent by Emacs.

OpenSSH 4.4 up to versions before 4.9 allows remote authenticated users to bypass the sshd_config ForceCommand directive by modifying the .ssh/rc session file.

ssh-keysign.c in ssh-keysign in OpenSSH on certain platforms executes ssh-rand-helper with unintended open file descriptors, which allows local users to obtain sensitive key information via the ptrace system call.

The ssh_gssapi_parse_ename function in gss-serv.c, when gssapi-with-mic authentication is enabled, allows remote authenticated users to cause a denial of service (memory consumption) via a large value in a certain length field.  NOTE: there may be limited scenarios in which this issue is relevant.

The auth_parse_options function in auth-options.c provides debug messages containing authorized_keys command options, which allows remote authenticated users to obtain potentially sensitive information by reading these messages, as demonstrated by the shared user account required by Gitolite.  NOTE: this can cross privilege boundaries because a user account may intentionally have no shell or filesystem access, and therefore may have no supported way to read an authorized_keys file in its own home directory.
0
 
gheistCommented:
I will cross-check in couple of hours all your list
0
 
gheistCommented:
CVE-2006-5794 OpenSSH: Privilege Separation Monitor Weakness  
CVE-2006-5051 OpenSSH: Signal Handler Pre-authentication Race Condition Code Execution
CVE-2007-4752 OpenSSH: Trusted X11 Cookie Connection Policy Bypass  

Patch now: https://support.f5.com/kb/en-us/solutions/public/15000/700/sol15780.html
CVE-2014-2653 OpenSSH: Client Rejected HostCertificate Handling Missing SSHFP Record Verification Weakness
CVE-2014-2532 OpenSSH: sshd Configuration AcceptEnv Wildcard Handling Remote Restriction Bypass
CVE-2006-5052 OpenSSH: GSSAPI Authentication Abort Username Enumeration  
CVE-2007-3102 OpenSSH: linux_audit_record_event Crafted Username Audit Log Injection  
CVE-2007-2243 OpenSSH: S/KEY Authentication Account Enumeration  
CVE-2010-5107
CVE-2004-2069
OpenSSH: logingracetime / maxstartup Threshold Connection Saturation Remote DoS
OpenSSH: libc/glob(3) resource exhaustion

HERE I STOP - they blame vulnerabilities based on version number. Namely this is *BSD (including F5) and other is Linux. There is no way they can be present on same system. The scanner will keep burping even after you patch.

OpenSSH: X11 Forwarding Local Session Hijacking
OpenSSH: ForceCommand Command Execution Weakness
OpenSSH: ssh-keysign ssh-rand-helper Utility File Descriptor Leak Local Information Disclosure
OpenSSH: post-authentication resource exhaustion bug via GSSAPI
OpenSSH: Forced Command handling leaks private information to ssh clients
OpenSSH: Cipher-Block Chaining (CBC) Mode Arbitrary Information Disclosure
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Building an Effective Phishing Protection Program

Join Director of Product Management Todd OBoyle on April 26th as he covers the key elements of a phishing protection program. Whether you’re an old hat at phishing education or considering starting a program -- we'll discuss critical components that should be in any program.

  • 7
  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now