Stack buffer overflow in RT-Thread AT server

[0xdea]

Hi,

I would like to report another potential vulnerability in the current version of RT-Thread. Please let me know if you plan to ask for a CVE ID in case the vulnerability is confirmed. I'm available if you need further clarifications.

Potential stack buffer overflow in RT-Thread AT server

Summary

I spotted a potential stack buffer overflow vulnerability at the following location in the RT-Thread AT server source code: https://github.com/RT-Thread/rt-thread/blob/master/components/net/at/src/at_server.c#L410

Details

Lack of length check in the at_cmd_get_name() function could lead to a stack buffer overflow at the marked line:

#ifdef AT_USING_SERVER
...
static rt_err_t at_cmd_get_name(const char *cmd_buffer, char *cmd_name)
{
    rt_size_t cmd_name_len = 0, i = 0;

    RT_ASSERT(cmd_name);
    RT_ASSERT(cmd_buffer);

    for (i = 0; i < strlen(cmd_buffer); i++)
    {
        if (*(cmd_buffer + i) == AT_CMD_QUESTION_MARK || *(cmd_buffer + i) == AT_CMD_EQUAL_MARK
                || *(cmd_buffer + i) == AT_CMD_CR
                || (*(cmd_buffer + i) >= AT_CMD_CHAR_0 && *(cmd_buffer + i) <= AT_CMD_CHAR_9))
        {
            cmd_name_len = i;
            rt_memcpy(cmd_name, cmd_buffer, cmd_name_len); /* VULN: cmd_buffer is AT_SERVER_RECV_BUFF_LEN bytes (256), while cmd_name is only AT_CMD_NAME_LEN bytes (16); therefore, it might be possible to overflow past the cmd_name buffer with a carefully crafted cmd_buffer */
            *(cmd_name + cmd_name_len) = '\0';

            return RT_EOK;
        }
    }

    return -RT_ERROR;
}

Impact

If the unchecked input above is confirmed to be attacker-controlled and crossing a security boundary, the impact of the reported buffer overflow vulnerability could range from denial of service to arbitrary code execution.

[0xdea]

Hi, it's been one month since I reported this vulnerability, and I wanted to ask if you have any update. As standard practice, I plan to request a CVE ID for every confirmed vulnerability. I also intend to publish an advisory by February at the latest, unless there's a specific reason to postpone. Thanks!

[0xdea]

Hi there, CVE-2024-25393 was assigned to this vulnerability. I'm planning to publish my security advisory and writeup on March 5th. Thanks.

[mysterywolf]

Hi so sorry for the late reply, I just review some issues. Yes you can, and thanks for the bug report!

[0xdea]

You're welcome, happy to help! Thank you for your feedback.