TinyWeb Socket Counter Imbalance Re-enables Slowloris Connection Exhaustion

Technical Details

Root Cause

The connection limit introduced in v2.02 relies on a single global counter, SocksCount. MainLoop increments the counter when it accepts a connection and hands it to a worker thread. TSocket.Destroy was responsible for decrementing the counter when a connection ends. The decrement was unconditional: it ran for every TSocket instance that was destroyed, even for connections that were never counted in the first place.

Mechanism

A socket is created but never counted when it is rejected before it becomes an active worker connection, for example when the underlying Startup (socket setup) fails, or when the CMaxConnections guard refuses the connection because the server is already at its limit. In these paths the counter was never incremented, yet TSocket.Destroy still decremented it. Every rejected connection therefore left SocksCount one lower than the true number of live connections.

Because the imbalance is cumulative, the counter drifts steadily negative under normal operation and much faster under attack. Once SocksCount is below zero, the comparison against CMaxConnections can no longer reach the limit at the intended point, so the guard stops rejecting new connections. The Slowloris protection that v2.02 added is effectively neutralized.

Attack Scenario

A remote, unauthenticated attacker repeatedly opens TCP connections and drops them (or triggers the CMaxConnections rejection path), driving SocksCount negative. The attacker then holds many slow connections open. With the counter drifted below zero, the server admits far more concurrent connections than CMaxConnections was meant to allow, exhausting worker threads and stack memory and denying service to legitimate clients, exactly the condition the v2.02 mitigation was designed to prevent.

Fix Applied in Version 2.05

The problem has been patched in version 2.05. TSocket now carries a Counted flag, and TSocket.Destroy decrements SocksCount only when a matching increment occurred in MainLoop. Sockets rejected by a Startup failure or by the CMaxConnections guard are never counted and are never decremented, so the counter can no longer drift and the connection limit holds at its intended threshold.

• Fix commit: 06efa04
• Fix pull request: PR #5

Workarounds

If upgrading to v2.05 is not immediately possible, consider the following mitigations:

• Restart the server periodically to reset SocksCount to its true value.
• Place TinyWeb behind a reverse proxy or firewall that caps the number of concurrent connections per source address, so the drifting internal counter cannot be exploited from a single client.

Timeline

Other TinyWeb CVEs