[scponly] scponly 4.2 released (IMPORTANT SECURITY FIXES)

[wby oblyr]

Hi all,

I'm disappointed to report that there are TWO security fixes in the latest version of scponly.  Descriptions and 
solutions are discussed below.  (they are also described in detail at http://sublimation.org/scponly/#relnotes )

Some other features have made it into the release as well, though not nearly as many as I had hoped.  Given the 
nature of the security fixes, I did not want to wait.

To get 4.2, visit http://sublimation.org/scponly

MD5 (scponly-4.2.tgz) = 270dedc527d6fbc68b152b8bb3c8a864

For the programmers on the list, I'd appreciate some scrutiny on the fixes I have implemented for these problems.  
As usual, your collective testing and validation is very valuable to the project.

joe




SECURITY PROBLEM 1, reported by Max Vozeler:

Problem Description:
If ALL the following conditions are true, administrators using scponly-4.1 or older may be at risk of a local 
privilege escalation exploit:                                                                                          
                                                                                                                        
 - the chrooted setuid scponlyc binary is installed                                                                     
 - regular non-scponly users have interactive shell access to the box
 - a user executable dynamically linked setuid binary (such as ping) exists on the same file system mount as the 
user's home directory
 - the operating system supports an LD_PRELOAD style mechanism to overload dynamic library loading

Exploit:                                                                                                                        
To exploit this vulnerability, a non-root user could:                                                                   
 - log in via an interactive shell                                                                                      
 - create an ad-hoc chroot directory structure in their home directory (with bin, lib, etc directories)                                            
 - create a hardlink to a system setuid program, such as ping (which is setuid), effectively placing a setuid 
binary in their chroot.  (this is why the setuid binary has to be on the same mount point, as hardlinks cannot 
traverse file systems and softlinks cannot traverse outside the chroot)                                                                                               
 - stage a malicious ld preload configuration to overload a call from the setuid (such as getuid()) with one that 
does something malicious                                                                                                                         
- users invoke scponlyc (the setuid chrooting scponly binary), which then chroots into their malicious chroot 
environment, call the setuid program (ping), which then calls the overridden function (getuid), doing whatever it 
is they wrote into their custom library

Fix:
The new release of scponly-4.2 disallows chrooting to any directory that:                                               
        - is owned by someone other than the superuser (UID 0)                                                          
        - is writeable by group or other                                                                                

This assures that every chroot scponly uses was created/approved by the system administrator and thus is assumed 
to not contain malicious ld.preload.conf files.
                                                      
SECURITY PROBLEM 2, reported by Pekka Pessi:

Problem Description:
If ANY the following conditions are true, administrators using scponly-4.1 or older may be at risk of a local 
privilege escalation exploit:                                                                                          
                                                                                                                        
 - scp compatibility is enabled
 - rsync compatibility is enabled
                  
Exploit:                                                                      
To exploit this vulnerability, a remote scponly user could:
 - construct a malicious command line argument to either the rsync or scp..  Athough scponly does check for 
arguments that allow the user to specify a program to run, it does not use getopt() style processing to locate 
these potentially malicious arguments.  As such "scp -vS some_executable file1 file2" would get past the malicious 
argument detection.

Fix:
The new release of scponly-4.2:
 - uses getopt to process the arguments to scp and rsync.
 - does not support rsync or scp by default