Release Notes
From Scponly wiki
Updates are listed in reverse chronological order below:
jun 2006 chrooted scponly cygwin HOWTO
by Roland Krystian Alberciak
jan 2006 scponly 4.6 release
MD5 (scponly-4.6.tgz) = 0425cb868cadd026851238452f1db907
- added missing semicolon
jan 2006 scponly 4.5 release
MD5 (scponly-4.5.tgz) = af4946662ca73913cd28078fbcb169d2
- minor fix to get HAVE_OPTRESET working (again)
jan 2006 scponly 4.4 release
MD5 (scponly-4.4.tgz) = 4b9373d1a5a641184989cc18bb8fceb3
- small getopt compilation fixes
- small setup_chroot.sh.in fixes
- UNISON environment fixes
dec 2005 scponly 4.3 release
MD5 (scponly-4.3.tgz) = 2cef26fe5ed740031a067f189c293e77
- Small fixes to 4.2 so that it "works". No feature changes.
dec 2005 scponly 4.2 release
MD5 (scponly-4.2.tgz) = 270dedc527d6fbc68b152b8bb3c8a864
VULNERABILITY FIX RELEASED DEC 21, 2005. ALL VERSIONS PRIOR TO 4.2 ARE VULNERABLE
SECURITY PROBLEM 1, reported by Max Vozeler
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
- if 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
If ANY the following conditions are true, administrators using scponly-4.1 or older may be at risk of remote scponly users circumventing the restricted shell and executing arbitrary programs. There is no privilege escalation and this vulnerability is post-authentication.
- 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. For example, the potentially malicious scp argument "-S program" would be detected but by combining it with the benevolent "-v" (yielding "-vS program") would not.
Fix:
The new release of scponly-4.2 has:
- getopt to process the arguments to scp and rsync.
- no support rsync or scp by default. henceforth, the recommended means to use scponly is via sftp
- other fixes and features
- fix for openbsd ldd in setup_chroot
- sftp-logging compatibility patch
- fix for autoconf AC_INIT macro
- patch for command line args to setup_chroot invocation
- patches to fix passw
