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

Vincent Danen vdanen at
Tue Mar 8 08:07:59 EST 2011

* [2011-03-08 07:59:43 +1100] Damien Miller wrote:

>On Mon, 7 Mar 2011, Vincent Danen wrote:
>> * [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.
>Sorry, I was incorrect above - the attack is purely client end. If there
>is additional CPU usage on the server then it is just from the client
>issuing more requests.

That makes sense.  Thanks.

>> 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?
>Feel free to forward this email conversation. I don't understand why they
>don't contact the vendor to verify CVEs to begin with.

I think it simply has to do with volume (I suspect it isn't feasible to
try to initiate contact with all upstream vendors considering how much
they have to deal with).

>> 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).
>Here's a simple proof:
>[djm at mothra openssh]$ grep -l 'glob[(]' *.c
>There are no glob calls in the server, so it can't be vulnerable to
>malicious glob patterns.

Perfect.  Thanks, Damien.   I'm going to summarize this in our bug and
then point it to MITRE (as well as this thread) so that it can be

Vincent Danen / Red Hat Security Response Team 

More information about the openssh-unix-dev mailing list