Erlang OTP SSH SFTP Chroot Bypass Vulnerability Allowing Unauthorized File Attribute Modification

A path traversal vulnerability has been identified in the SSH SFTP server component of Erlang OTP. This vulnerability allows authenticated SFTP users to modify file attributes outside of the designated chroot directory. The issue arises because the SFTP daemon (ssh_sftpd) records the original, user-provided file paths in handles, rather than paths adjusted for chroot. As a result, when the SSH_FXP_FSETSTAT command is used, file attributes such as permissions, ownership, and timestamps are changed on the actual filesystem, completely bypassing the chroot restriction. This vulnerability only affects versions of Erlang OTP from 17.0 up to 28.4.3, as well as specific 27 and 26 versions. If the SSH daemon is running as root, this vulnerability can be exploited to escalate privileges by allowing an attacker to manipulate sensitive files or binaries.

Impact

Exploitation of this vulnerability can lead to unauthorized modification of file attributes, such as permissions and ownership, on paths outside the intended chroot confinement. This could be particularly damaging if the SSH daemon is running as root, as it would enable an attacker to escalate privileges by, for example, setting the setuid bit on executables or altering the ownership of critical system files.

Reproduction

To reproduce this vulnerability, an authenticated SFTP user must first create a file within the chroot directory that the SFTP server is configured to use. Once this file is in place, the user can upload a file to the same relative path on the real filesystem outside the chroot. Afterward, the user can issue the SSH_FXP_FSETSTAT command on the handle corresponding to the file outside the chroot, which will then modify the attributes of the original file, effectively bypassing the chroot restriction.

Remediation

Users can mitigate this vulnerability by not using the 'root' option in the SFTP subsystem configuration, and instead relying on OS-level chroot or container isolation. Additionally, the Erlang VM should be run as an unprivileged user to limit the potential impact of any attribute modifications.