Impact
An issue was spotted in the function that is called to retrieve the root folder path of a process that could allow an attacker with high privileges (at least CAP_SYS_CHROOT) to achieve partial memory corruption. Given the details below this does not appear likely to be exploitable ("Exploitability: None").
|
if ( readlink(root_path, tinfo->root, sizeof(tinfo->root)) > 0) |
The issue is that readlink does not null-terminate the string that will read and copied into tinfo->root and the size of the buffer is sizeof(tinfo->root) instead of sizeof(tinfo->root) - 1 to let space for inserting a zero at the last index. Thus it’s possible to create a path exceeding SCAP_MAX_PATH_SIZE and chroot a program into it in order for this part of the code to write a not null-terminated string into the structure of the size. See the following listing for the structure in which the root buffer appears.
|
char root[SCAP_MAX_PATH_SIZE+1]; |
In theory, because the static size buffer is inserted directly in the structure, the situation could potentially mean that future reads of this string, supposed to be null-terminated, could overflow and read the data of the next structure’s fields values. However, the size of the buffer is SCAP_MAX_PATH_SIZE + 1, which translates to 1025, so the compiler will align the next fields, resulting in the next integer to be shifted by some blocks. And because this structure is allocated using calloc, the bytes hole will be filled with zeros. The result will be a string with a size equal to the expected length plus one, which could potentially be an issue with copies trusting that the string is well formed.
Patches
Upgrade to libs 0.10.3
Workarounds
None
References
Falco Security Audit report, 23-01-1097-LIV by Victor Houal, Laurent Laubin and Mahé Tardy
Impact
An issue was spotted in the function that is called to retrieve the root folder path of a process that could allow an attacker with high privileges (at least CAP_SYS_CHROOT) to achieve partial memory corruption. Given the details below this does not appear likely to be exploitable ("Exploitability: None").
libs/userspace/libscap/linux/scap_procs.c
Line 561 in 5c25fca
The issue is that readlink does not null-terminate the string that will read and copied into
tinfo->rootand the size of the buffer issizeof(tinfo->root)instead ofsizeof(tinfo->root) - 1to let space for inserting a zero at the last index. Thus it’s possible to create a path exceedingSCAP_MAX_PATH_SIZEandchroota program into it in order for this part of the code to write a not null-terminated string into the structure of the size. See the following listing for the structure in which the root buffer appears.libs/userspace/libscap/scap.h
Line 302 in 5c25fca
In theory, because the static size buffer is inserted directly in the structure, the situation could potentially mean that future reads of this string, supposed to be null-terminated, could overflow and read the data of the next structure’s fields values. However, the size of the buffer is
SCAP_MAX_PATH_SIZE + 1, which translates to 1025, so the compiler will align the next fields, resulting in the next integer to be shifted by some blocks. And because this structure is allocated usingcalloc, the bytes hole will be filled with zeros. The result will be a string with a size equal to the expected length plus one, which could potentially be an issue with copies trusting that the string is well formed.Patches
Upgrade to libs 0.10.3
Workarounds
None
References
Falco Security Audit report, 23-01-1097-LIV by Victor Houal, Laurent Laubin and Mahé Tardy