Bug 3397

Summary:	Make internal-sftp the default
Product:	Portable OpenSSH	Reporter:	MichaIng <micha>
Component:	sshd	Assignee:	Assigned to nobody <unassigned-bugs>
Status:	NEW ---
Severity:	enhancement	CC:	djm
Priority:	P5
Version:	8.9p1
Hardware:	All
OS:	Linux

Description MichaIng 2022-02-27 04:31:54 AEDT

Currently the standalone OpenSSH sftp-server is used as default SFTP subsystem. This implies a dependency on the standalone binary and means that every SFTP connection spawns a new external process, while sshd ships with the internal-sftp in-process SFTP server, which perform better especially when dealing with many short duration connections and simplifies the ChrootDirectory usage to not require any manual /dev node setup.

Legacy SSH1 clients pass an exact SFTP command, hence will still depend on any standalone SFTP server, also internal-sftp means that the login shell is skipped in the first place. But the need for both are edge cases IMHO, the use of SSH1 IMO worth to be actively discouraged, and the vast majority of OpenSSH SFTP server admins will benefit from this change, at least to not require a config change that is part of very most SFTP guides around the internet, reasonably.

Forgive me if this discussion was already done, but I couldn't find it within this bug tracker at least.

Reported first at the Debian bug tracker, and was reasonably redirected here as it is an upstream default: https://bugs.debian.org/1006171

Best regards,

Micha

Comment 1 Damien Miller 2022-03-18 14:10:55 AEDT

Using a separate binary means that the sftp-server process does not inherit a memory image of the privileged sshd process (as it would for a merely fork()ed internal-sftp). 

Inheriting the memory image carries the risk that an error in sftp-server's attack surface could yield an arbitrary memory read primitive, and this could be used to break ASLR and other protections on the parent process, as well as granting access to any otherwise private data left in the sshd process. Unfortunately the existence of private data in the sshd address space is hard to reason about, especially since PAM modules can do pretty much what they feel like.

Now, sftp-server _should_ be pretty free of bugs, but weird corner-cases that don't exist for other bits of sshd have yielded bad bugs there before (e.g. https://seclists.org/oss-sec/2014/q4/216)

For this reason, my preference is to keep it as-is