Bug 681698 (CVE-2010-4755) - CVE-2010-4755 openssh: remote DoS in sftp via crafted glob expressions
Summary: CVE-2010-4755 openssh: remote DoS in sftp via crafted glob expressions
Alias: CVE-2010-4755
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2011-03-02 22:34 UTC by Vincent Danen
Modified: 2021-02-24 16:23 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-03-07 21:18:21 UTC

Attachments (Terms of Use)

Description Vincent Danen 2011-03-02 22:34:24 UTC
Common Vulnerabilities and Exposures assigned an identifier CVE-2010-4755 to
the following vulnerability:

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

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

Comment 1 Vincent Danen 2011-03-03 00:40:35 UTC
I let this run for an hour when sftp'ing into a RHEL6 box:

% time sftp odvrhel6 
Connecting to odvrhel6...
sftp> ls {..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*cx
Killed by signal 15.
sftp odvrhel6  156.31s user 459.50s system 17% cpu 59:22.55 total

On the RHEL6 box, sshd used a fairly consistent 25% CPU and sftp-server used 20%.  I did not observe any excessive memory consumption.

25825 vdanen    20   0 12424 1836 1200 S 24.9  0.2  14:36.12 sshd               
25826 vdanen    20   0  7616 1624 1264 S 18.3  0.2  11:14.87 sftp-server

I don't think this is a DoS for us (other than tying up a connection perhaps indefinitely).  It certainly doesn't impact other connections to ssh/sftp that I can see (although I suspect doing this a few times in parallel would cause issues, but with sftp at least that requires authentication).

Comment 2 Tomas Mraz 2011-03-03 07:46:52 UTC
Is the impact=moderate correct? If you have full shell access (not sftp-only) to the server, you can achieve the same thing with running any CPU consuming process in the server.

Comment 3 Vincent Danen 2011-03-03 20:45:18 UTC
Is there not a way to have sftp-only accounts "out of the box" in RHEL?  Or do you need something like scponly installed?

If having sftp access implies (by what packages we provide) that shell access is also permitted, then I would be ok with dropping this to low impact.  I was under the impression that at least later openssh releases had some built-in mechanism to only permit sftp (I could very well be wrong here though).

Comment 4 Jan F. Chadima 2011-03-04 09:05:16 UTC
There is such mechanism by the forced-command configuration option.

Comment 5 Vincent Danen 2011-03-04 15:57:11 UTC
Ok, thanks Jan.  In light of that, I think this needs to stay as moderate due to the worst-case scenario of someone using OpenSSH in this way, and being able to configure it this way easily.

Comment 6 Vincent Danen 2011-03-04 16:06:19 UTC
I've sent a message to upstream regarding this, as I do not know if they are aware of it:


Comment 7 Vincent Danen 2011-03-07 21:18:21 UTC
Upstream is disputing this as a security flaw:


In essence, upstream indicates that this is a bug in the glob support of the sftp client:

[djm@mothra openssh]$ grep -l 'glob[(]' *.c

As there are no glob calls in the server, the server cannot be vulnerable to malicious glob patterns as the CVE description implies.

The higher CPU usage on the server is incidental to this problem; upstream indicates that additional CPU being used on the server is due to the client issuing more requests.  Having done some testing here with four connections to a Red Hat Enterprise Linux 6 server, using the test case noted in comment #1, the per-process CPU utilization is actually lower than the single process on one connection.  Load average spikes briefly, but comes back down to sane levels (not normal or idle, but not excessive either).

To that end, the only DoS here is on the sftp client (self-inflicted using such a glob pattern), and the DoS is in preventing subsequent commands being issued to the server.  This could similarly happen by pressing CTRL-C or logging out of the session.


We do not consider a denial of service flaw in a client application such as sftp to be a security issue.

Comment 8 Jan F. Chadima 2011-03-08 02:11:30 UTC
It seems reasonally
but some questions:
   1) what about the line client - server is DoSed or not?
       - maybe the line bandwidth is the limit of server cpu utilisation.
       - whole DoS is there a infinite queue of the same requests to the server
   2) what happens when 10 broken clients access the same server
       - is the impact additive?
       - can be reached 100% utilisation?
   3) is there a possibility to break the clients without knowledge of the user
       - by spurious scripts ... & so on

Comment 9 Vincent Danen 2011-03-08 16:03:33 UTC
Some answers (perhaps mostly guesses; the most appropriate place to ask would be on the openssh-dev mailing list):

1) I can't imagine this would saturate bandwidth

start# ifconfig eth0|grep bytes
          RX bytes:3154207478 (2.9 GiB)  TX bytes:3055917616 (2.8 GiB)
30s# ifconfig eth0|grep bytes
          RX bytes:3167926846 (2.9 GiB)  TX bytes:3069620452 (2.8 GiB)
60s# ifconfig eth0|grep bytes
          RX bytes:3176837540 (2.9 GiB)  TX bytes:3078520162 (2.8 GiB)

Using the last sampling, we received 8.49MB over 30s, so 0.28MB per second; roughly doubled for the amount transmitted as well.  (Keep in mind that other things are running as well on a typical desktop, so if I do the above _without_ sshd/sftp running we only received 3920 bytes in 30s, so majority would be sftp traffic; also note this is over gigabit (not sure if that makes a difference)).  I don't believe this is enough to consider it a DoS on the bandwidth; obviously the more connections made, the more will be consumed.  Please correct me if I'm wrong.

2) No, upon more connections (tried here with four simultaneous connections), the CPU utilization of each process on the server dropped the amount of CPU it used (on the first connection, the CPU utilization of sshd was roughly 25%, sftp was 20% -- on the second connection sshd consumed approximately 15% per process, and sftp consumed 13% per process).  So the CPU utilization scales back per connection, although with more connections the overall CPU usage does go higher.

3) Possible, but unlikely.  If someone is running sftp in batch mode, it's more or less their responsibility to know what they are running before doing so.  At best it will be a blocking operation on the connection (similar to if the firewall was preventing outbound port 22 connections) and some higher-than-normal CPU usage.

Note You need to log in before you can comment on or make changes to this bug.