Open 0xdea opened 7 months ago
If an attacker is able to control fullpath above and craft it as required to trigger the reported heap buffer overflow vulnerabilities, their impact could range from denial of service to arbitrary code execution.
the fullpath from dfs_normalize_path,shouldn't be the case with Fullpath's provenance?
Based on my analysis, fullpath
comes indeed from dfs_normalize_path()
, which in turn processes user input. I couldn't see any limits imposed on path length in dfs_normalize_path()
, i.e.:
if (filename[0] != '/') /* it's a absolute path, use it directly */
{
fullpath = (char *)rt_malloc(strlen(directory) + strlen(filename) + 2);
if (fullpath == NULL)
return NULL;
/* join path and file name */
rt_snprintf(fullpath, strlen(directory) + strlen(filename) + 2,
"%s/%s", directory, filename);
}
else
{
fullpath = rt_strdup(filename); /* copy string */
if (fullpath == NULL)
return NULL;
}
Therefore, unless there are other filesystem limitations in place or I'm missing something else, I think an attacker might be able to control fullpath
and trigger the buffer overflows. Just to err on the side of caution, I'd recommend adding some explicit length checks.
Thank you for your feedback. @geniusgogo have fixed with #8305. If you could check it again, we would greatly appreciate! 🙏
It looks good now. I'm glad my bug report has sparked some improvements also in other areas of the codebase!
However, I'm not entirely sure about this fix that is included in the same commit but is related to https://github.com/RT-Thread/rt-thread/issues/8286 (heap buffer overflows in finsh):
if (rt_strcmp(".", dirent->d_name) != 0 &&
rt_strcmp("..", dirent->d_name) != 0)
{
if (strlen(pathname) + 1 + strlen(dirent->d_name) > DFS_PATH_MAX)
{
rt_kprintf("cannot remove '%s/%s', path too long.\n", pathname, dirent->d_name);
continue;
}
rt_sprintf(full_path, "%s/%s", pathname, dirent->d_name);
if (dirent->d_type != DT_DIR)
{
...
if (rt_strcmp(".", dirent->d_name) != 0 &&
rt_strcmp("..", dirent->d_name) != 0)
{
if (strlen(pathname) + 1 + strlen(dirent->d_name) > DFS_PATH_MAX)
{
rt_kprintf("'%s/%s' setattr failed, path too long.\n", pathname, dirent->d_name);
continue;
}
rt_sprintf(full_path, "%s/%s", pathname, dirent->d_name);
if (dirent->d_type == DT_REG)
{
The added length check doesn't account for the terminating NUL byte: if strlen(pathname) + 1 + strlen(dirent->d_name) == DFS_PATH_MAX, we would pass the check but have an off-by-one bug in the rt_sprintf() calls. It would probably be better to replace rt_sprintf() with snprintf(), slprintf(), or a similar safer alternative.
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!
Hi, I just wanted to let you know that I've requested a CVE ID from MITRE for this vulnerability and for https://github.com/RT-Thread/rt-thread/issues/8271 as well. I'm planning to do the same for the other issues that I've opened in November 2023.
As anticipated, I intend to publish an advisory that documents these issues and possibly a short writeup on my blog. The tentative date for publication is February 28th, 2024, more than 90 days since the initial report, which is standard practice for security researchers. Especially considering that these issues are already public on GitHub, I don't see any reasons to postpone. However, it would be great to have these issues triaged and patched before publication.
I remain available in case you need any clarifications. Thanks!
Hi there, CVE-2024-24334 was assigned to this vulnerability. I'm planning to publish my security advisory and writeup on March 5th. Thanks.
Hi,
I would like to report other potential vulnerabilities in the current version of RT-Thread. Please let me know if you plan to ask for a CVE ID in case the vulnerabilities are confirmed. I'm available if you need further clarifications.
Potential heap buffer overflows in RT-Thread dfs_v2 dfs_file
Summary
I spotted some potential heap buffer overflow vulnerabilities at the following locations in the RT-Thread dfs_v2 dfs_file source code: https://github.com/RT-Thread/rt-thread/blob/master/components/dfs/dfs_v2/src/dfs_file.c#L234 https://github.com/RT-Thread/rt-thread/blob/master/components/dfs/dfs_v2/src/dfs_file.c#L262 https://github.com/RT-Thread/rt-thread/blob/master/components/dfs/dfs_v2/src/dfs_file.c#L284 https://github.com/RT-Thread/rt-thread/blob/master/components/dfs/dfs_v2/src/dfs_file.c#L314
Details
Lack of length check in the the
dfs_nolink_path()
function could lead to heap buffer overflows at the marked lines:Impact
If an attacker is able to control
fullpath
above and craft it as required to trigger the reported heap buffer overflow vulnerabilities, their impact could range from denial of service to arbitrary code execution.