remote DoS in sftp via crafted glob expressions (CVE-2010-4755)

[Vincent Danen]

Hi folks.

We were made aware of a MITRE CVE assignment on OpenSSH for a remote DoS
in sftp, described as:

The (1) remote_glob function in sftp-glob.c and the (2) process_put
function in sftp.c in OpenSSH 5.8 and earlier, as used in FreeBSD 7.3
and 8.1, NetBSD 5.0.2, OpenBSD 4.7, and other products, 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.


This looks to have been corrected in NetBSD, but I don't know how
portable their fix is.  Here are some references:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4755
http://securityreason.com/achievement_securityalert/89
http://cxib.net/stuff/glob-0day.c
http://securityreason.com/exploitalert/9223
http://cvsweb.netbsd.org/cgi-bin/cvsweb.cgi/src/crypto/dist/ssh/Attic/sftp-glob.c#rev1.13.12.1
http://cvsweb.netbsd.org/cgi-bin/cvsweb.cgi/src/crypto/dist/ssh/Attic/sftp.c#rev1.21.6.1
http://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2010-008.txt.asc
https://bugzilla.redhat.com/show_bug.cgi?id=681698

I did try on a Red Hat Enterprise Linux 6 system and did see that
sftp-server and sshd were consistently consuming about 20% and 25% CPU
respectively for the one crafted ls command:

sftp> ls {..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*cx

It did not prevent other sftp/ssh logins while this was running, but I
imagine a few of these commands running in parallel would tie up quite a
bit of CPU.

I'm bringing this up because I've not seen any mention of this on the
list, so I'm not sure as to whether or not upstream is aware of this.

It certainly isn't something critical, but I would think it deserves a
fix.

Note that the only reason why I would even consider this moderately
security-relevant is that you can restrict access to a system to
sftp-only using forced commands; if this was not possible and the user
had ssh/shell access guaranteed, then they could "DoS" the system just
as easily a hundred other ways.

Thanks.

-- 
Vincent Danen / Red Hat Security Response Team