/ Bug 3586 – mod_sftp behaves badly when receiving badly formed SSH messages
Bug 3586 - mod_sftp behaves badly when receiving badly formed SSH messages
: mod_sftp behaves badly when receiving badly formed SSH messages
Status: CLOSED FIXED
Product: ProFTPD
mod_sftp
: 1.3.3
: All All
: P3 normal
Assigned To: TJ Saunders
:
: Backport
:
:
  Show dependency treegraph
 
Reported: 2011-01-24 20:54 UTC by TJ Saunders
Modified: 2011-05-13 18:05 UTC (History)
8 users (show)

See Also:


Attachments
Fixes problem (5.38 KB, patch)
2011-01-24 21:00 UTC, TJ Saunders
Details

Note You need to log in before you can comment on or make changes to this bug.
Description TJ Saunders 2011-01-24 20:54:52 UTC
A proftpd user noticed that mod_sftp behaves badly (i.e. crashes, tries to
allocate enormous amounts of memory and is eventually killed by the kernel,
etc) in certain situations.  Some analysis showed that the problem relates to
badly-formed SSH messages, e.g. messages from clients where the packet length
and/or payload length encoded in the message is of enormous (and usually
ridiculous) size.  One such TraceLog showed:

  <ssh2:20>: SSH2 packet len = 1264032678 bytes
  <ssh2:20>: SSH2 packet padding len = 158 bytes
  <ssh2:20>: SSH2 packet payload len = 1264032519 bytes

and then mod_sftp would try to allocate that much memory -- which led to the
problems.

Why does mod_sftp not check for such things as it's reading in the packet, and
simply drop the packet/connection as soon as it sees bad values like this?

An issue was reported against the SSH protocol: CPNI-957037, see:

  http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt
  http://openssh.com/txt/cbc.adv

The actual details revolved around sending a malformed SSH packet to a server,
and watching how quickly the server choked/dropped on the packet.  Very similar
to an information leak attack in nature.

To work around this attack, clients can use CTR modes (if supported).  Servers
can read in the entire packet, even if it is determined to be malformed early,
so that the client can't get a good idea of how far into the packet the server
read before dropping it.  This is what mod_sftp does.

Except that it is still trying to allocate memory for that reported payload
length -- and that's what is causing problems.  The fix, then, is to keep
reading in the entire packet, but to NOT allocate that payload length if it is
above some hardcoded limit, one that in practice is not encountered by
well-behaved clients.
Comment 1 TJ Saunders 2011-01-24 20:55:43 UTC
One such badly behaved client implementation, for example, is libssh-0.2.
Comment 2 TJ Saunders 2011-01-24 21:00:24 UTC
Created attachment 3539 [details]
Fixes problem

This patch should catch such situations, and handle them properly.  In the
SFTPLog, you would see a message like:

  client sent buggy/malicious packet payload length, ignoring

And a detailed TraceLog would show:

  <ssh2:20> payload len (1264032519 bytes) exceeds max payload len (262144),
ignoring payload
Comment 3 TJ Saunders 2011-02-12 12:41:46 UTC
Patch committed to CVS, and backported to 1.3.3 branch.
Comment 4 TJ Saunders 2011-02-12 13:04:55 UTC
*** Bug 3587 has been marked as a duplicate of this bug. ***
Comment 5 Henri Salo 2011-03-02 18:22:19 UTC
CVE-2011-1137 identifier got assigned to this vulnerability.
Comment 6 TJ Saunders 2011-04-06 03:37:46 UTC
Resolved in 1.3.4rc2.
Comment 7 TJ Saunders 2011-05-13 18:05:06 UTC
For future reference, another terse but very accurate description of the
CPNI-957037 issue can be found in the PuTTY docs:

 
http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/ssh2-cbc-pktlen-weakness.html