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