Summary
The mod_verto HTTP request handler allocates a fixed 2 MiB buffer for a POST application/x-www-form-urlencoded body but accepts Content-Length up to just under 10 MiB. The body-read loop is bounded by Content-Length rather than the buffer size, producing an attacker-controlled heap overflow of up to ~8 MiB -- before the HTTP basic-auth check runs.
Impact
- Heap corruption with fully attacker-controlled contents: every byte the attacker sends past 2 MiB lands on the heap.
- Reliable denial of service via heap corruption is trivial to trigger.
- Possible information disclosure: depending on heap layout, the overflow may corrupt adjacent allocations whose contents are later reflected on the same connection (HTTP response or WebSocket frames).
- RCE has not been demonstrated, but is plausible given the size of the overflow and complete attacker control over its contents.
Affected configurations
Reachable only on verto profiles with at least one <vhost> configured (the HTTP request handler is wired up only when vhosts are present). The vanilla verto.conf.xml defines its profile without <vhost> blocks and is not reachable as-is. Deployments come into scope as soon as an operator adds a <vhost> -- typically to serve files or a landing page (e.g. Verto Communicator deployments serving the web UI from the same FreeSWITCH port). Default listener ports are :8081 plaintext and :8082 TLS.
Attack prerequisites
Network reach to the verto listener. The overflow lands before HTTP basic-auth runs, so no credentials, WebSocket upgrade, JSON-RPC framing, or prior interaction are required. TLS does not mitigate: the overflow is in HTTP body parsing after the transport is terminated.
Workarounds
- Restrict the verto listener to trusted networks (firewall / bind address).
- Remove all
<vhost> entries from the verto profile. This disables the HTTP request handler entirely and confines verto to WebSocket / JSON-RPC; files previously served via the verto vhost will no longer be reachable on the verto port.
- Disable
mod_verto outright if it is not in use.
Fix
Size the body-buffer allocation to the request's Content-Length (plus one byte for the trailing NUL) so the read loop's natural termination matches the allocation. The accepted Content-Length ceiling is unchanged; only the allocation now tracks the gate.
Credit
Adam Bedard, Security Researcher.
Summary
The
mod_vertoHTTP request handler allocates a fixed 2 MiB buffer for aPOST application/x-www-form-urlencodedbody but acceptsContent-Lengthup to just under 10 MiB. The body-read loop is bounded byContent-Lengthrather than the buffer size, producing an attacker-controlled heap overflow of up to ~8 MiB -- before the HTTP basic-auth check runs.Impact
Affected configurations
Reachable only on verto profiles with at least one
<vhost>configured (the HTTP request handler is wired up only when vhosts are present). The vanillaverto.conf.xmldefines its profile without<vhost>blocks and is not reachable as-is. Deployments come into scope as soon as an operator adds a<vhost>-- typically to serve files or a landing page (e.g. Verto Communicator deployments serving the web UI from the same FreeSWITCH port). Default listener ports are:8081plaintext and:8082TLS.Attack prerequisites
Network reach to the verto listener. The overflow lands before HTTP basic-auth runs, so no credentials, WebSocket upgrade, JSON-RPC framing, or prior interaction are required. TLS does not mitigate: the overflow is in HTTP body parsing after the transport is terminated.
Workarounds
<vhost>entries from the verto profile. This disables the HTTP request handler entirely and confines verto to WebSocket / JSON-RPC; files previously served via the verto vhost will no longer be reachable on the verto port.mod_vertooutright if it is not in use.Fix
Size the body-buffer allocation to the request's
Content-Length(plus one byte for the trailing NUL) so the read loop's natural termination matches the allocation. The acceptedContent-Lengthceiling is unchanged; only the allocation now tracks the gate.Credit
Adam Bedard, Security Researcher.