/
Bugzilla – Bug 3586
mod_sftp behaves badly when receiving badly formed SSH messages
Last modified: 2011-05-13 18:05:06 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.
One such badly behaved client implementation, for example, is libssh-0.2.
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
Patch committed to CVS, and backported to 1.3.3 branch.
*** Bug 3587 has been marked as a duplicate of this bug. ***
CVE-2011-1137 identifier got assigned to this vulnerability.
Resolved in 1.3.4rc2.
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