Summary
A path traversal vulnerability in uTox file transfers allows a Tox friend to cause arbitrary files to be written when the victim has automatic acceptance enabled. Depending on the victim's permissions and the targeted files, this may enable configuration tampering, code execution, or persistence.
A path traversal vulnerability in uTox file transfers allows a Tox friend to cause arbitrary files to be written when the victim has automatic acceptance enabled. Depending on the victim's permissions and the targeted files, this may enable configuration tampering, code execution, or persistence.
Affected context
The issue occurs in uTox versions through 0.18.1 when automatically accepted file transfers use attacker-controlled file names without sufficiently restricting their destination paths. Absolute paths and traversal sequences may escape the intended download directory, and specially crafted resume metadata may be processed in a way that creates additional risk.
The issue occurs in uTox versions through 0.18.1 when automatically accepted file transfers use attacker-controlled file names without sufficiently restricting their destination paths. Absolute paths and traversal sequences may escape the intended download directory, and specially crafted resume metadata may be processed in a way that creates additional risk.
Exploit preconditions
- Attack surface: Incoming uTox file transfers and transfer-resume processing
- Required access: Ability to communicate with the victim as a Tox friend
- Configuration requirement: Automatic file acceptance must be enabled, or another workflow must permit unattended writes
- Trigger point: Processing an incoming file name or resume record
- Why exploitation is possible: File names are insufficiently constrained to the intended directory, allowing attacker-controlled paths or metadata to influence file operations
- Attack surface: Incoming uTox file transfers and transfer-resume processing
- Required access: Ability to communicate with the victim as a Tox friend
- Configuration requirement: Automatic file acceptance must be enabled, or another workflow must permit unattended writes
- Trigger point: Processing an incoming file name or resume record
- Why exploitation is possible: File names are insufficiently constrained to the intended directory, allowing attacker-controlled paths or metadata to influence file operations
Why this happens
The vulnerability results from treating attacker-controlled transfer names as trusted filesystem paths. When path components are not canonicalized and constrained beneath an approved destination, absolute paths or parent-directory references can redirect writes outside the intended directory.
The affected resume-processing behavior also increases risk when crafted metadata is interpreted with unsafe assumptions about internal file handles. This is consistent with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, where input-controlled path data escapes its permitted filesystem boundary.
The vulnerability results from treating attacker-controlled transfer names as trusted filesystem paths. When path components are not canonicalized and constrained beneath an approved destination, absolute paths or parent-directory references can redirect writes outside the intended directory.
The affected resume-processing behavior also increases risk when crafted metadata is interpreted with unsafe assumptions about internal file handles. This is consistent with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, where input-controlled path data escapes its permitted filesystem boundary.
Potential impact
- An attacker may overwrite user or application files
- Shell startup files or other configuration files could be modified
- Crafted resume metadata could cause unsafe file operations
- Local code execution may occur under the victim process's privileges
- User data, application integrity, or persistence mechanisms could be compromised
- An attacker may overwrite user or application files
- Shell startup files or other configuration files could be modified
- Crafted resume metadata could cause unsafe file operations
- Local code execution may occur under the victim process's privileges
- User data, application integrity, or persistence mechanisms could be compromised
General mitigation guidance
Mitigation generally focuses on treating transfer names and resume metadata as untrusted input.
Common defensive patterns include:
- Restricting all accepted files to a dedicated, non-sensitive download directory
- Canonicalizing paths and verifying that the resolved destination remains within that directory
- Rejecting absolute paths, parent-directory components, symbolic-link escapes, and platform-specific alternate path forms
- Using safe-by-default manual acceptance instead of unattended writes
- Parsing resume records with strict schemas and avoiding attacker-controlled file-handle behavior
- Running the client with least-privilege filesystem permissions and avoiding write access to startup or system configuration files
- Separating downloaded content from executable or trusted configuration locations
Mitigation generally focuses on treating transfer names and resume metadata as untrusted input.
Common defensive patterns include:
- Restricting all accepted files to a dedicated, non-sensitive download directory
- Canonicalizing paths and verifying that the resolved destination remains within that directory
- Rejecting absolute paths, parent-directory components, symbolic-link escapes, and platform-specific alternate path forms
- Using safe-by-default manual acceptance instead of unattended writes
- Parsing resume records with strict schemas and avoiding attacker-controlled file-handle behavior
- Running the client with least-privilege filesystem permissions and avoiding write access to startup or system configuration files
- Separating downloaded content from executable or trusted configuration locations
How teams detect issues like this
Organizations can look for this weakness through:
- Static analysis rules that identify file writes using unsanitized transfer names
- Code review checks for missing canonicalization and directory-containment validation
- Tests covering absolute paths, parent-directory references, symbolic links, and platform-specific path formats
- Review of resume-file parsers for unsafe pointer, descriptor, or metadata handling
- Runtime monitoring for unexpected writes outside the configured download directory
- Policy enforcement requiring explicit approval for inbound file transfers and restricting client filesystem permissions
Automated security review tools may help identify path construction and untrusted file-write patterns, but behavioral testing remains important.
Organizations can look for this weakness through:
- Static analysis rules that identify file writes using unsanitized transfer names
- Code review checks for missing canonicalization and directory-containment validation
- Tests covering absolute paths, parent-directory references, symbolic links, and platform-specific path formats
- Review of resume-file parsers for unsafe pointer, descriptor, or metadata handling
- Runtime monitoring for unexpected writes outside the configured download directory
- Policy enforcement requiring explicit approval for inbound file transfers and restricting client filesystem permissions
Automated security review tools may help identify path construction and untrusted file-write patterns, but behavioral testing remains important.
