Summary
esl_recv_event() parses Content-Length with atol() and passes the result straight to malloc(len + 1) with no sign or magnitude check. A malicious or man-in-the-middle ESL peer can send a frame with a negative Content-Length to corrupt the heap of, or crash, any process linked against libesl, before the client has authenticated to that peer.
Impact
Content-Length: -1 - malloc(0) succeeds and body[len] = '\0' underwrites one byte at body[-1]. The body-read loop then copies attacker-controlled bytes that the peer queued after the header into the zero-byte allocation, producing a heap buffer overflow with attacker-controlled length and contents.
Content-Length: -2 and lower - len + 1 underflows when converted to size_t, malloc returns NULL, and the following statement dereferences the NULL pointer. The connecting process crashes.
RCE has not been demonstrated.
Affected configurations
fs_cli, mod_esl, mod_hash, and any third-party application linked against libesl. The outbound socket dialplan application in mod_event_socket is not affected - it uses its own ESL implementation.
Attack prerequisites
ESL is a cleartext protocol meant for use on a trusted control plane (loopback or a private management network); transport confidentiality and integrity are the operator's responsibility. Within that boundary, this bug lets the ESL peer — or anyone with reach to the same segment - corrupt the heap of, or crash, a connecting libesl client before the client authenticates. No credentials or prior interaction are required; the malicious frame is the first event the client reads.
Workarounds
No reliable workaround. Operators who cannot upgrade should restrict which hosts libesl clients (fs_cli, mod_esl, mod_hash, third-party tools) are configured to connect to, and keep the control-plane network unreachable from less-trusted hosts.
Fix
Reject Content-Length values that are negative or above an ESL_MAX_CONTENT_LENGTH cap (16 MiB), replace the assert on the malloc result with a runtime check, and destroy the partially-built event on the new error paths so the handle is left in a clean state.
Credit
Adam Bedard, Security Researcher.
Summary
esl_recv_event()parsesContent-Lengthwithatol()and passes the result straight tomalloc(len + 1)with no sign or magnitude check. A malicious or man-in-the-middle ESL peer can send a frame with a negativeContent-Lengthto corrupt the heap of, or crash, any process linked against libesl, before the client has authenticated to that peer.Impact
Content-Length: -1-malloc(0)succeeds andbody[len] = '\0'underwrites one byte atbody[-1]. The body-read loop then copies attacker-controlled bytes that the peer queued after the header into the zero-byte allocation, producing a heap buffer overflow with attacker-controlled length and contents.Content-Length: -2and lower -len + 1underflows when converted tosize_t,mallocreturnsNULL, and the following statement dereferences the NULL pointer. The connecting process crashes.RCE has not been demonstrated.
Affected configurations
fs_cli,mod_esl,mod_hash, and any third-party application linked against libesl. Theoutbound socketdialplan application inmod_event_socketis not affected - it uses its own ESL implementation.Attack prerequisites
ESL is a cleartext protocol meant for use on a trusted control plane (loopback or a private management network); transport confidentiality and integrity are the operator's responsibility. Within that boundary, this bug lets the ESL peer — or anyone with reach to the same segment - corrupt the heap of, or crash, a connecting libesl client before the client authenticates. No credentials or prior interaction are required; the malicious frame is the first event the client reads.
Workarounds
No reliable workaround. Operators who cannot upgrade should restrict which hosts libesl clients (
fs_cli,mod_esl,mod_hash, third-party tools) are configured to connect to, and keep the control-plane network unreachable from less-trusted hosts.Fix
Reject
Content-Lengthvalues that are negative or above anESL_MAX_CONTENT_LENGTHcap (16 MiB), replace theasserton themallocresult with a runtime check, and destroy the partially-built event on the new error paths so the handle is left in a clean state.Credit
Adam Bedard, Security Researcher.