codepr
Five bugs in sol
Hi,codepr!I found five bugs in sol.
Environment Details
1.sol version: Commit # 172ff0f773722c8ba572ee8874d5c575354e3f55
2.Operating system and version:Kali GNU/Linux Rolling 2023.4
NULL Pointer Dereference in sol
Describe the bug
One bug (NULL Pointer Dereference) was found in sol MQTT broker: it processes non-CONNECT packets (e.g., SUBSCRIBE) before a valid CONNECT, violating MQTT v3.1.1 and leading to a server crash.
Actual Behavior
The server's process_message() and read_callback() do not verify that the first packet after TCP connection is a CONNECT. As a result, sending a SUBSCRIBE immediately causes NULL or bad-pointer dereference in internal state, triggering SIGSEGV.
Trigger and Crash
The server did not check the first message but processed it directly, causing an error:
Authentication Bypass in sol
Describe the bug
One protocol violation bug (Authentication Bypass) was found in sol MQTT broker. The server accepts and processes packets prior to CONNECT, violating [MQTT-3.1.0-1].
Actual Behavior
The sol server does not enforce that the first packet received from a client is a CONNECT packet, as required by the MQTT v3.1.1 specification. This allows clients to bypass the authentication phase and directly send PUBLISH or SUBSCRIBE packets, even when anonymous access is disabled.
Trigger and Crash
Set in sol.conf to prohibit anonymous user connections:
Set username and password:
Run the sol server:
Running the poc, sending a PUBLISH packet, the server should normally disconnect or reject the packet because it has not received a legitimate CONNECT. But the actual behavior is that the server accepts the PUBLISH, and the message is delivered to the subscribed client without any authentication.
UAF in sol
Describe the bug
One bug (UAF) was found in sol MQTT broker related to improper handling of long Client IDs, in violation of MQTT v3.1.1 spec.
Actual Behavior
The broker incorrectly enforces a 23-byte Client ID length limit by truncating longer IDs using a fixed-size buffer, violating the MQTT v3.1.1 spec. When two connections with the same 64-byte prefix in Client ID are made, a segmentation fault is triggered on disconnect.
Trigger and Crash
After running , it is found that the clientID request is truncated to the first 64 bytes:
After establishing a connection using two Client IDs with the same prefix:
1.The second connection is mistakenly identified as the first connection.
2.When one of the clients disconnects, the server accesses the released resources, triggering a segfault.
Resource Exhaustion in sol
Describe the Bug
One protocol compliance issue and a potential denial-of-service (DoS) vulnerability were discovered in sol MQTT broker when handling CONNECT packets.
Actual Behavior
When sol receives a CONNECT packet that it deems invalid—whether because it is a duplicate CONNECT from the same client or because the client fails authentication—the broker does not fully comply with MQTT v3.1.1’s error‐handling rules. Instead of sending a CONNACK with the appropriate non‐zero return code and then immediately closing the connection, sol sometimes drops the connection silently (on duplicate CONNECT) or sends the CONNACK but leaves the TCP session open (on bad credentials). In both cases, the session state remains allocated in memory, references to that client’s buffers persist, and no cleanup timer or idle‐timeout is invoked. An attacker can exploit this behavior by opening hundreds or thousands of such “half‐open” sessions—each holding onto memory and file descriptors indefinitely—ultimately exhausting available system memory and file handles. Under sustained load, the Linux OOM‐killer intervenes and terminates the sol process, resulting in a complete denial of service for all legitimate MQTT clients.
Trigger and Crash
Set in sol.conf to prohibit anonymous user connections:
Set username and password:
Run the sol server:
Poc creates a large number of TCP connections, each sending a malformed CONNECT, and keeps them alive indefinitely. Under this load, sol consumes all available memory and files, gets marked by the Linux OOM killer, and crashes.
Memory-Leak in sol
Describe the Bug
A specification compliance bug in sol MQTT broker’s handling of retained QoS-0 messages was discovered. According to MQTT v3.1.1, when a client sends a QoS-0 PUBLISH with the RETAIN flag set, the broker must discard any previously retained message for that topic. However, sol merely overwrites the retained-message pointer without freeing the old message, leading to unbounded memory growth.
Actual Behavior
When sol receives a QoS-0 PUBLISH packet with RETAIN=1 on a topic for which it has already stored a retained message, it replaces the internal pointer to the retained message with a newly allocated message object but does not deallocate the memory associated with the previous message. Over time, as more retained publishes arrive, the broker’s heap usage increases linearly, eventually leading to exhaustion of available memory and potential process termination. This behavior directly contradicts the MQTT v3.1.1 requirement that the server discard any message previously retained for that topic, which inherently implies freeing or otherwise removing the old message from memory.
Trigger and Crash
Run the poc to continuously send offending packets.After stopping sending, a memory leak is prompted.(Run with valgrind command)
Change the script's retain to False, and no memory leak occurs.
is 172ff0f773722c8ba572ee8874d5c575354e3f55 the correct hash? I cannot find it in any current branch (including main).
is 172ff0f773722c8ba572ee8874d5c575354e3f55 the correct hash? I cannot find it in any current branch (including main).
Hello, we are sorry that the previous version was submitted incorrectly. The correct version is 373d84877d22031b45a7f3599297f691eab09230.