REDHAT-BUG-2526466: Medium severity Gnome gvfs vulnerability
A flaw was found in the SFTP backend in gvfs. When mounting a share, a malicious SFTP server can cause readstring() to allocate a buffer with a certain length but the function does not verify that the buffer is completely filled, leaving the remainder of the buffer containing uninitialized heap contents. If the server sends a short FXPHANDLE reply, these uninitialized bytes are taken as the file handle. The client will then echo these uninitialized bytes back to the server on all subsequent requests using that handle. With a length of 128 bytes, this issue allows the malicious server to deterministically read uninitialized heap memory from the gvfsd-sftp process, leaking its heap base and the load address of the libgio library, resulting in a deterministic defeat of Address Space Layout Randomization (ASLR). This vulnerability affects gvfs versions 1.10.0 and newer and is fixed in version 1.60.2.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
gvfsto a version that resolves this vulnerability.Fixed in 1.60.2 - Compensating control
When mounting SFTP shares, avoid connecting to untrusted/malicious SFTP servers until gvfs is upgraded to 1.60.2.
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker operating a malicious SFTP server can exploit it when a client mounts a share from that server. The issue is in the gvfs SFTP backend and affects the gvfsd-sftp process.
What does the malicious server need to send?
The server must send a short FXP_HANDLE reply while the share is being mounted. The client then uses uninitialized heap bytes as the handle and sends those bytes back in subsequent requests.
What is the impact of successful exploitation?
A malicious server can deterministically read uninitialized heap memory from gvfsd-sftp. With a 128-byte handle length, the leak can reveal the heap base and libgio load address, defeating ASLR.
How can I determine whether a system is affected, and what version fixes it?
Systems running gvfs 1.10.0 or newer are affected according to the provided information. The issue is fixed in gvfs version 1.60.2.