Re: [Lilux-help] Help with nmap (and ssh)

On Wed, Jan 28, 2004 at 01:17:42PM +0100, Brent Frère wrote: Haha. Go read the previous 2 or 3 OpenSSH security advisories and then tell me if you are still of this opinion. Let's quote a few things, from their own "security" page: OpenSSH 2.1.0 and newer do not allow a remote attacker to execute arbitrary commands with the privileges of sshd if UseLogin is enabled by the administrator. UseLogin is disabled by default. This problem has been fixed in OpenSSH 2.1.0. OpenSSH 2.3.0 and newer are not vulnerable to the "Feb 8, 2001: SSH-1 Daemon CRC32 Compensation Attack Detector Vulnerability", RAZOR Bindview Advisory CAN-2001-0144. A buffer overflow in the CRC32 compensation attack detector can lead to remote root access. This problem has been fixed in OpenSSH 2.3.0. However, versions prior to 2.3.0 are vulnerable. OpenSSH 2.3.0 and newer do not allow malicious servers to access the client's X11 display or ssh-agent. This problem has been fixed in OpenSSH 2.3.0. OpenSSH 2.3.1, a development snapshot which was never released, was vulnerable to "Feb 8, 2001: Authentication By-Pass Vulnerability in OpenSSH-2.3.1", OpenBSD Security Advisory. In protocol 2, authentication could be bypassed if public key authentication was permitted. This problem does exist only in OpenSSH 2.3.1, a three week internal development release. OpenSSH 2.3.0 and versions newer than 2.3.1 are not vulnerable to this problem. OpenSSH 2.9.9 and newer do not allow users to delete files named "cookies" if X11 forwarding is enabled. X11 forwarding is disabled by default. OpenSSH 2.9.9 and newer are not vulnerable to "Sep 26, 2001: Weakness in OpenSSH's source IP based access control for SSH protocol v2 public key authentication.", OpenSSH Security Advisory. Portable OpenSSH 3.7.1p2 and newer are not vulnerable to "September 23, 2003: Portable OpenSSH Multiple PAM vulnerabilities", OpenSSH Security Advisory Etc, etc. I took only a few. So, they had many, many, security holes in the past. Why would it be secure *now*? It is a network protocol, but it is (supposed to be) transport-agnostic. So, you can use it over TCP, you can use it over DECnet, you can use it over Unix domain sockets. If you are running the X-client on the same host, then communicating with the server over Unix domain sockets is faster. And you can disable TCP altogether, because all local programs will happily use Unix domain sockets. Note that running an X-client over an ssh session with X11 port forwarding counts as a local client for this purpose. No need to enable TCP listening on the X server for this. -- Lionel