Bug 681698 (CVE-2010-4755)

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).

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.

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).

There is such mechanism by the forced-command configuration option.

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.

I've sent a message to upstream regarding this, as I do not know if they are aware of it:

http://lists.mindrot.org/pipermail/openssh-unix-dev/2011-March/029427.html

Upstream is disputing this as a security flaw:

http://lists.mindrot.org/pipermail/openssh-unix-dev/2011-March/029433.html

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

[djm@mothra openssh]$ grep -l 'glob[(]' *.c
sftp-glob.c
sftp.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.


Statement:

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

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

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.