uTox through 0.18.1 doesn't validate incoming file name, allowing remote attacker to overwrite arbitrary file on victim's machine.
Remote attacker may overwrite ~/.bashrc or ~/.profile as well, causing remote code execution.
To exploit this vulnerability, modified uTox client may be used.
Just set name and name_length variables in file_transfers.c, in ft_send_file(), before tox_file_send(), and send an evil shell script. For example:
name = "/home/krobelus/.bashrc";
name_length = strlen(name);
Second vulnerability exists only if uTox is in portable mode, with --portable parameter.
https://github.com/uTox/uTox/blob/develop/src/xlib/filesys.c
void native_autoselect_dir_ft(uint32_t fid, FILE_TRANSFER *file)
...
uint8_t *path = malloc(file->name_length + 1);
...
if (settings.portable_mode) {
snprintf((char *)path, UTOX_FILE_NAME_LENGTH, "./tox/Tox_Auto_Accept/");
native_create_dir(path);
snprintf((char *)path, UTOX_FILE_NAME_LENGTH, "./tox/Tox_Auto_Accept/%.*s", (int)file->name_length, file->name);
Here file->name_length is less than UTOX_FILE_NAME_LENGTH, so any incoming file transfer will cause remote heap overflow, denial of service and, possibly, remote code execution.
Automatic file acceptance must be turned on to exploit these two vulnerabilities, but due to uTox peculiarities, this option is on among the majority of users already.
These peculiarities are that uTox users have only a few seconds to confirm file receiving, thus receiving a few files one by one quickly turns into hell.
Debug builds are not vulnerable to heap overflow, because AddressSanitizer is used.
Vulnerabilities reported to cve.org, but no entries were created hitherto.
Rare
