[BUG] Unlimited User Label Appends in Userlabel Cluster causes Resource Exhaustion and Potential DoS

[BoB13-Matter]

Reproduction steps

1. Run chip-tool and chip-all-clusters-app separately:

   ./chip-tool interactive start

   ./chip-all-clusters-app

2. Write a user label list with a large number of entries using chip-tool:

   userlabel write label-list '[{"label":"roomName", "value":"master bedroom 1"}, {"label":"orientation", "value":"east"}, {"label":"floor", "value":"2"}, {"label":"roomType", "value":"bedroom"}, ... , {"label":"roomType", "value":"bedroom"}]' 1 0

   • Full command example: command.txt

3. Observe the CPU usage and responsiveness of chip-all-clusters-app during the write operation:

   • CPU utilization reaches 100% and remains consistently high.
   • Processing times increase exponentially as more entries are appended, eventually resulting in timeout errors.

4. Attempt to read back the user label list:

   userlabel read label-list 1 0

   • CPU usage spikes again during the read operation, and timeout occurs before completion.

     

     [1733664929.591] [38705:38707] [DMG] Time out! failed to receive report data from Exchange: 42522i
     [1733664929.592] [38705:38707] [TOO] Error: src/app/ReadClient.cpp:723: CHIP Error 0x00000032: Timeout
     [1733664929.592] [38705:38707] [TOO] Run command failure: src/app/ReadClient.cpp:723: CHIP Error 0x00000032: Timeout
     

     Full log: chip-tool userlabel read log.txt

5. General system slowness: After adding many entries, even unrelated commands sent via chip-tool to other clusters become significantly slower. This suggests that excessive user label entries are affecting the overall responsiveness of the system.

---

Summary

The User Label Cluster implementation in Matter allows an unlimited number of entries to be appended via the WriteLabelList function when using the AppendItem operation.

This lack of enforced maximum entries leads to:

• High CPU usage
• Prolonged processing times
• Timeout failures
• General degradation of system responsiveness, including unrelated Matter commands

Additionally, the unlimited append functionality creates a clear vector for a Denial of Service (DoS) attack, particularly in resource-constrained IoT environments. An attacker could exploit this behavior to overload the device, rendering it unresponsive.

Root Cause Analysis

The issue lies in the WriteLabelList function and the associated AppendUserLabel implementation. While WriteLabelList uses an AttributeList with a maximum size of kMaxUserLabelListLength (10) for overwriting operations, the AppendItem operation bypasses this limit entirely.

1. AppendItem Operation in WriteLabelList:

   if (aPath.mListOp == ConcreteDataAttributePath::ListOperation::AppendItem)
   {
       Structs::LabelStruct::DecodableType entry;
   
       // Validate the new entry's label and value lengths
       ReturnErrorOnFailure(aDecoder.Decode(entry));
       VerifyOrReturnError(IsValidLabelEntry(entry), CHIP_IM_GLOBAL_STATUS(ConstraintError));
   
       // Add the entry without checking total list size
       return provider->AppendUserLabel(endpoint, entry);
   }
   

2. Unlimited Append in AppendUserLabel:

   CHIP_ERROR DeviceInfoProvider::AppendUserLabel(EndpointId endpoint, const UserLabelType & label)
   {
       size_t length;
   
       // Fetch current list length and increase by 1
       ReturnErrorOnFailure(GetUserLabelLength(endpoint, length));
       ReturnErrorOnFailure(SetUserLabelLength(endpoint, length + 1));
   
       // Add the new entry to the end of the list
       ReturnErrorOnFailure(SetUserLabelAt(endpoint, length, label));
   
       return CHIP_NO_ERROR;
   }
   

This implementation lacks any mechanism to enforce a maximum entry limit during append operations.

Description

Expected Behavior:

• The AppendItem operation should respect the maximum entry count defined by kMaxUserLabelListLength (10 by default).
• When the maximum number of entries is reached, subsequent append attempts should return an error (e.g., CHIP_ERROR_NO_MEMORY).

Actual Behavior:

• The append operation allows entries to be added indefinitely.
• Resource usage (CPU, memory, disk) escalates with each appended entry, leading to:
• The /tmp/chip_kvs file grows uncontrollably, consuming storage resources.

This behavior poses a risk for IoT devices with limited computational power and memory, potentially leading to service interruptions and making them vulnerable to exploitation.

Proposed Solution

Introduce a check in AppendUserLabel to enforce the maximum entry limit:

CHIP_ERROR DeviceInfoProvider::AppendUserLabel(EndpointId endpoint, const UserLabelType & label)
{
    size_t length;

    // Fetch current list length
    ReturnErrorOnFailure(GetUserLabelLength(endpoint, length));

    // Enforce maximum entry limit
    if (length >= kMaxUserLabelListLength)
    {
        return CHIP_ERROR_NO_MEMORY; // Return an error if the limit is exceeded
    }

    // Add the new entry to the list
    ReturnErrorOnFailure(SetUserLabelLength(endpoint, length + 1));
    ReturnErrorOnFailure(SetUserLabelAt(endpoint, length, label));

    return CHIP_NO_ERROR;
}

Bug prevalence

always

GitHub hash of the SDK that was being used

ffbc362

Platform

core

Platform Version(s)

all versions

Anything else?

No response