Link to home
Start Free TrialLog in
Avatar of sunhux
sunhux

asked on

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
SOLUTION
Avatar of gheist
gheist
Flag of Belgium image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Avatar of giltjr
giltjr
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
You need to say CVE number to get mitigation if at all, otherwise it is just whistling in the wind...
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.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of sunhux
sunhux

ASKER

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
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of sunhux

ASKER

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.
I will cross-check in couple of hours all your list
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial