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

[Vincent Danen]

* [2011-03-06 09:00:47 +1100] Damien Miller wrote:

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

I'm confused.  Why would this be an attack on the client?  The client is
the one putting the glob (the server isn't pushing this as far as I can
see).  I do see a CPU spike (and blocking on the ability to execute any
subsequent commands) on the client, but I also see (excessive?) CPU
usage on the host.

Interestingly, subsequent sftp connections to the host, doing the same
thing do not increase CPU usage significantly.

Is this something you would be interested in disputing with MITRE over
the CVE assignment?

I see you also said:

>actually, the CVE description is nonsensical. sftp-server doesn't
>process globs in requests at all. All glob expansion is done by
>the client.
>
>So a user entering a malicious glob is DoSing their own end of the
>connection.

Doing further testing, I'm inclined to agree with you.  At best this is
a client DoS, but they are doing it to themselves (but you implied
malicious server above, so I'm not sure whether this should be
considered a flaw from a malicious server and the description needs to
be revised, or if this should be rejected outright since self-inflicted
issues shouldn't really be considered security flaws).

Thanks for the response, Damien.  If you could clarify the malicious
server bit you mentioned above, then I can engage with MITRE one way or
the other.

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

-- 
Vincent Danen / Red Hat Security Response Team