Proftpd堆溢出漏洞

=========================== VULNERABILITIES =========================== ../proftpd-master/src/pool.c:89-116 (Heap Overflow due to zero length malloc allocation) TYPE: CERT MEM04-C; CWE-131 Code Snippet: ............................ ret = malloc(size); } if (ret == NULL) { pr_log_pri(PR_LOG_ALERT, "Out of memory!"); #ifdef PR_USE_DEVEL if (debug_flags & PR_POOL_DEBUG_FL_OOM_DUMP_POOLS) { pr_pool_debug_memory(oom_printf); } #endif exit(1); } return ret; } ======================== TECHNICAL EXPLANATION ======================== The return value of malloc can be set to null for zero size allocs, and this would return a NULL pointer on certain implementations of MIPS32 and ARM architectures, or cause a SIGSEGV. Despite the exit() function call, the memory allocation would be attempted. Embedded platforms such as OpenWRT could be targeted and this defect can be taken advantage of, depending on where the swap is, this can be exploited. This would have critical impact on architectures such as ARM and MIPS32 used in embedded platforms, to cite as an example, and thus the impact is implementation specific. ================= CODE SNIPPET 2 ================= Line: 371-379 CERT MEM04-C; CWE-131 static cmd_rec *fxp_cmd_alloc(pool *p, const char *name, char *arg) { cmd_rec *cmd; cmd = pr_cmd_alloc(p, 2, pstrdup(p, name), arg ? arg : ""); cmd->arg = arg; return cmd; } fxp_cmd_alloc() can be a cause for unspecified behavior. Furthermore there is a memory pool management issue, which can result to heap overflows and DoS attacks. .................................................. ../src/pool.c:128-160, 771, 811 ................................................. There is a defect in the way the memory pool is organized. The issue itself is that the pool relies on malloc returning truly aligned memory; and explicitly freeing/allocating memory. The impact is that you can overwrite random memory. Behavior and impact of this reliance on aligned memory is implementation specific. ============================================ Reading USER_AUTH_INFO_RESP messages from client ../mod_sftp/kbdint.c#L297 Denial of Service ============================================= According to RFC 4256 Section 3.2 The server may send as many requests as are necessary to authenticate the client; the client MUST be prepared to handle multiple exchanges. According to RFC 4256 Section 3.2 The server may send as many requests as are necessary to authenticate the client; the client MUST be prepared to handle multiple exchanges. kbdint.c: 209-210 =================== RATIONALE ..................... IF multiple clients send multiple requests and where each request (resp_count in code) is thus not greater than SFTP_KBDINT_MAX_RESPONSE LIMIT (500) per user, this would cause significant problems to the aforementioned memory allocation pool defect. I could find no plausible MAX LIMIT on the size of the pool, nor any controls to restrict that apart from a buffer which is equal to 3072 in sinze, in kbdint.c ; in context of the created pool, which can be allocated on a per connection basis. kbdint.c: 209-210 buflen = bufsz = 3072; buf = ptr = palloc(pkt->pool, bufsz);