bugzilla-daemon at mindrot.org
2025-Jun-04 01:56 UTC
[Bug 3834] New: Uncontrolled memory allocation size in sshkey_read() and sftp_upload()
https://bugzilla.mindrot.org/show_bug.cgi?id=3834 Bug ID: 3834 Summary: Uncontrolled memory allocation size in sshkey_read() and sftp_upload() Product: Portable OpenSSH Version: 10.0p2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: sftp Assignee: unassigned-bugs at mindrot.org Reporter: shen497 at purdue.edu When parsing user?supplied data, both sshkey_read() and sftp_upload() allocate buffers whose sizes are derived directly from attacker?controlled input. In each case, an adversary can force OpenSSH to malloc (and copy) an arbitrarily large buffer, leading to denial of service. 1. sshkey_read(): During public?key loading, sshkey_read() calls: ``` space = strcspn(cp, " \t"); if ((blobcopy = strndup(cp, space)) == NULL) { /* ? */ } ``` Because strcspn() walks until it finds a space or tab (or the NUL), a single token with no separators can make space equal to the entire line length. An attacker who places a very long base64 token (hundreds of megabytes) in a ?public key? line will cause strndup() to attempt a huge allocation and memcpy. Even if malloc fails, the process wastes CPU and memory resources attempting to copy the blob. Worse, if the allocation succeeds, the program stalls for a long time or runs out of RAM. Potential fix: Introduce a hard cap (MAX_KEY_BLOB_LEN, e.g. 64 KiB) on space before calling strndup(). Reject any token longer than this limit as ?invalid format.? 2. sftp_upload() sftp -B accepts a numeric argument that controls buffer size for transfers. Internally, this value is parsed and passed directly to xmalloc() in sftp_upload() ``` data = xmalloc(conn->upload_buflen); ``` Because there is no upper bound, a malicious client can request an arbitrarily large buffer. For example: ``` sftp -B 10000000000 user at host ``` will cause malloc(10000000000) (10 GiB), potentially exhausting memory or triggering out?of?memory. Potential fix: Clamp the -B argument to a reasonable maximum, such as MAX_SFTP_IOBUF = 64 KiB. Treat any larger request as ?invalid option? and exit. -- You are receiving this mail because: You are watching the assignee of the bug.