[scponly] scponly 4.2 released (IMPORTANT SECURITY FIXES)

[Kaleb Pederson]

Joe,

Thanks for your constant efforts to improve scponly!  It's a valuable tool 
used by many.

--Kaleb

On Wednesday 21 December 2005 4:49 pm, wby oblyr wrote:
> 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
>
>
>
>
>
>
>
> _______________________________________________
> scponly mailing list
> scponly at lists.ccs.neu.edu
> https://lists.ccs.neu.edu/bin/listinfo/scponly
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : https://lists.ccs.neu.edu/pipermail/scponly/attachments/20051222/0e997610/attachment.bin