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

[Damien Miller]

The attack is on the client by a malicious server - a client can't DoS
a server with this bug. We generally don't put much effort into making
the client resilient to DoS from a hostile server.

-d

On Fri, 4 Mar 2011, Vincent Danen wrote:

> 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
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>