full-disclosure - rssh: root privilege escalation flaw

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20051230164536.GD5740@sophic.org>
Date: Fri Dec 30 17:46:18 2005
From: code at pizzashack.org (Derek Martin)
Subject: rssh: root privilege escalation flaw

Affected Software:	rssh - all versions prior to 2.3.0
Vulnerability:		local user privilege escalation
Severity:		*CRITICAL*
Impact:			local users can gain root access  
Solution:		Please upgrade to v2.3.1

Summary
-------

rssh is a restricted shell which allows a system administrator to
limit users' access to a system via SSH to scp, sftp, rsync, rdist,
and cvs.  It also allows the system administrator the ability to
chroot users to a configurable location.

* PLEASE NOTE *
This problem was fixed in 2.3.0, but there is another small bug (not
security-related) in that version which prompted me to release 2.3.1
today.  I will announce that separately in appropriate channels.
Please upgrade to the 2.3.1 release, not the 2.3.0 release.

Max Vozeler reported a flaw in the design of rssh_chroot_helper
whereby it can be exploited to chroot to arbitrary directories and
thereby gain root access.  If rssh is installed on a system, and
non-trusted users on that system have access which is not protected by
rssh (i.e. they have full shell access), then they can use
rssh_chroot_helper to chroot to arbitrary locations in the file system,
and thereby gain root access.  

Workaround
----------

By careful configuration of file system mounts, it is possible to
avoid this problem; but doing so requires a fair amount of contortion
which will be difficult to re-engineer after an existing installation
has already been configured.  The exploit requires the user to be able
to write executables in the directory they are chrooting to, and
create hard links to SUID binaries within that directory structure, so
by preventing either of these two things, the exploit will be foiled.
System administrators can accomplish this by careful configuration of
filesystem permissions, mount points, and mount options (such as
no_exec, no_suid, etc.).  I will not go into details since the far
better solution is to upgrade.

Fix
---

The 2.3.0 release of rssh fixes this problem by forcing the chroot
helper program to re-parse the config file instead of allowing the
chroot home to be specified on the command line.  Thus users not
listed can not use it to chroot (or will chroot to the default
location specified by the sysadmin), and users who are listed will be
chrooted to the directories where they are supposed to go only.

This version also fixes an unrelated bug which causes
rssh_chroot_helper to crash on the ia64 architecture (and possibly
others).  Numerous people reported a problem with the way 
va_start/va_end was used in log.c, which causes a segfault on 64-bit
Linux platforms.  It is believed that this bug is not exploitable,
since no code in this module is ever executed with root privileges.
However this is also fixed in this release.

Thanks

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051230/d7923020/attachment.bin