TUCoPS :: Unix :: General :: unix5649.htm

COMMAND
	
		scponly rights circumvention
	
	
SYSTEMS AFFECTED
	
		?
	
	
PROBLEM
	
		Derek D. Martin [ddm@pizzashack.org] posted :
		
		scponly makes no effort to verify the path to the scp or sftp-server
		executables before it executes them, and uses system() to do so.
		
		If the server administrator makes no effort to restrict access to the
		user's .ssh directory, the user can upload a file with a custom
		environment to $HOME/.ssh/environment. Subsequently, the user can
		upload a script or program to run arbitrary commands, such as to change
		their login shell, or what have you.
		
		For example, the user could scp the following to
		$HOME/.ssh/environment:
		
		 # ssh environment
		 PATH=/home/myhomedir/:/usr/bin:/bin
		 #end
		
		Subsequently, the user could upload the following file to their home
		directory, and call it scp:
		
		 #!/bin/sh
		 
		 echo "I'm a bad boy"> /tmp/exploit
		 /usr/bin/scp $@
		
		 # end
		
		When they next scp a file:
		
		 [root@restricted /tmp]
		 # ls -l
		 total 24
		 -rw-r--r-- 1 bonehead bonehead 14 Aug 19 22:46 exploit
		 [root@restricted /tmp]
		 # cat exploit
		 I'mv a bad boy
		
		Provided they're careful about output of their command, with the above
		script the file still gets copied and anyone watching over their
		shoulder is none the wiser. Obviously this could be replaced with any
		arbitrary command; this provides the user with a means of running
		arbitrary commands by simply uploading a file. Another neat trick is:
		
		 echo "mypassword" | chsh -s /bin/bash
		
		Now the user can log in with ssh, assuming chsh allows users to change
		their own shells.
		
		Tested and verified on Red Hat 7.1, but should work on any system
		running the OpenSSH sshd server.
		
		Additionally, some versions of the OpenSSH sshd(8) man page claim that
		at start-up, sshd will execute commands in $HOME/.ssh/rc using /bin/sh,
		rather than with the user's shell as listed in /etc/passwd. The man
		page on my system says this, even though in practice the version of
		sshd I have installed actually does use the user's shell. However, if
		this is *NOT* the case, the user could execute arbitrary commands by
		uploading a file to $HOME/.ssh/rc.
		
		Finally, though effort is made to remove shell metacharacters from the
		input, scponly uses system() to execute commands. Also wildcards are
		allowed. In some environments, it may be possible to exploit this
		situation. No verified exploit.
		
		
	
	
SOLUTION
	
		 Workaround
		 ==========
		
		The ability of the user to circumvent scponly is dependent upon their
		ability to manipulate their environment, by uploading files to specific
		locations in their .ssh directory.
		
		The system administrator can prevent this by making the user's home
		directory non-writable to the user. In order to provide file upload to
		the user, a user-writable directory must be provided for that purpose.
		
		Some may feel this is too restrictive; some may feel that creating
		.ssh/ and making it unwritable to the user is sufficient. It isn't. If
		the user has write access to their home directory, the user can log in
		via sftp, and simply remove the .ssh directory if it is empty, or
		rename it if it is not, regardless of who owns it or what its
		permissions are. The only way to prevent them from doing this is to
		make their home directory non-writable.
		
		This will prevent the user from being able to modify their environment
		files, preventing the exploit.
		
		Depending on how the call to system() can be exploited, if it can be at
		all, this may or may not solve that problem.
		
		The author's update involves documenting the problem, and updating the
		installation to include some chown commands. The author does intend to
		remove the call to system() in the immediate future; but with no threat
		of a known exploit which was not fixable in doing the above, was not
		concerned that I wait to release this vulnerability before having the