1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
|
SECURITY
--------
Please note: The man page now has detailed information about security concerns
and some tips for setting up rssh securely. If you haven't read these, please
do so now. What follows is mostly a summary of specific security issues which
have affected rssh since I started developing it.
Nov 27, 2005
Max Vozeler reported a scary problem whereby rssh_chroot_helper can be
exploited to chroot to arbitrary directories and thereby gain root access.
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, which hopefully the sysadmin has set
up securely), and users who are listed will be chrooted to the directories
where they are supposed to go only.
Numerous people reported a problem with the way I used va_start/va_end in
log.c which causes a segfault on 64-bit Linux platforms. I don't know if this
is exploitable, but it's fixed. Given the previously mentioned root
compromise, this probably doesn't matter much... ;-)
Dec 3, 2004
Jason Wies has reported a problem whereby rssh can be bypassed in conjunction
with scp, rdist, and rsync. The source of the problem is that these commands
have command-line options which trigger execution of arbitrary programs.
The 2.2.3 release of rssh fixes this problem, by parsing the command line
passed to the exec()'d program, making sure it does not contain command line
options which allow arbitrary execution of programs.
Oct 23, 2004
Florian Schilhabel has identified a format string bug which can allow an
attacker to run arbitrary code from an account configured to use rssh. In
general the risk is low, as in most cases the user can only compromise their
own account. The risk is mittigated by the fact that before this bug can be
exploited, the user must log in successfully through ssh. This means that
either the user is known, or that the system is already compromised.
However, on some older systems with broken implementations of the setuid()
family of functions, a root compromise may be possible with certain
configurations of rssh. Specifically, if rssh is configured to use a chroot
jail, it will exec() rssh_chroot_helper, which must be setuid root in order to
call chroot(). Normally, rssh_chroot_helper calls setuid(getuid()) and drops
privileges before any of the logging functions are called, making a root
compromise impossible on most systems. However, some older systems which
handle saved UIDs improperly may be vulnerable to a root compromise. Linux in
particular is not vulnerable to this, nor should modern POSIX-compliant Unix
variants be. POSIX defines that the setuid() system call will set all UIDs
(UID, saved UID, and effective UID) the specified UID if it is called with
root privileges. Therefore in general, a root compromise is not possible, and
I am not specifically aware of any systems on which one is possible.
The 2.2.2 release of rssh fixes this string format vulnerability. I have also
gone over the code to make sure that no other such vulnerabilities exist. In
addition to fixing this problem, rssh contains some new code to help identify
certain problems for debugging problems when rssh fails. Additional logging
of error conditions is performed.
May 22, 2004
There is a bug in rssh 2.0 - 2.1.x which allows a user to gather
information outside of a chrooted jail unintentionally. It was reported by
William McCaw, to whom I am thankful. The latest release of rssh fixes this
problem, and also improves support for some non-openssh sftp clients.
Additionally, it extends rssh by allowing cvs, rsync, and rdist.
The cause of the problem identified by Mr. McCaw is that rssh expanded
command-line arguments prior to entering the chroot jail. This bug
DOES NOT allow a user to access any of the files outside the jail, but
can allow them to discover what files are in a directory which is
outside the jail, if their credentials on the server would normally
allow them read/execute access in the specified directory.
For example (from William's bug report), if a user has an account on a
server machine which restricts them into a jail using rssh, the
user can use the following command to access the server and see what
files exist in the /etc directory:
scp target:/etc/* .
The results of this command will look something like this:
scp: /etc/DIR_COLORS: No such file or directory
scp: /etc/HOSTNAME: No such file or directory
scp: /etc/X11: No such file or directory
scp: /etc/adjtime: No such file or directory
[ ... ]
ld.so.cache 100% 675 0.0KB/s 00:00
ld.so.conf 100% 0 0.0KB/s 00:00
[ ... ]
passwd 100% 51 0.0KB/s 00:00
[ ... ]
scp: /etc/termcap-Linux: No such file or directory
scp: /etc/updatedb.conf: No such file or directory
scp: /etc/warnquota.conf-sample: No such file or directory
scp: /etc/xml: No such file or directory
The files which succeed in copying exist inside the chroot jail, and
thus should be harmless. All of the files which produce an error
message exist in the system's /etc directory, but do not exist inside
the chroot jail. The user is placed in the jail before access to any
of these files is attempted, so again, it is not possible to access
them. For many sites, this is not a serious issue. However if it is
important at your site that users not be able to know about any files
which exist outside the chroot jail, then you should upgrade as soon
as possible.
The 2.2.0 release of rssh fixed the problem in question, but was
mistakenly released missing some code for parsing per-user options.
The 2.2.1 release corrects that problem, and should be the final
release of rssh. No further development is planned.
Aug 22 2002
1. Summary
2. Details
Summary
-------
If you are using OpenSSH >= 3.5, you can edit sshd_config to be sure that
PermitUserEnvironment=no appears in the file and is not commented out, and
then ignore the rest of this file (well, read it anyway, so you understand the
issues). This option did not exist prior to OpenSSH 3.5, so if you're using
and older version, the rest of this definitely applies to you!
The details of the problem, including a description of how a user might
exploit the problem, are discussed below. It is currently not completely
possible to prevent users from circumventing rssh to gain access to the
restricted system, unless one of two precautions is taken:
* the rssh binary is compiled statically
* efforts are made to prevent the restricted users' environment files from
being user-modifiable
In practice, the latter means that an rssh user's home directory must not be
writable to the user, nor must their .ssh directory (if it exists) be
writable. It is not sufficient to limit the .ssh directory, as users could use
sftp to remove or rename the .ssh directory, and create a new one which is
writable by them. Note that this means they can not own their home directory
either, as if they do they can use sftp to chmod it. Alternately on Linux
systems using file systems which support the chattr command, you could chattr
+i the .ssh directory.
For this reason, as of rssh v0.9.3, the binary is compiled statically by
default. Note that this results in a very large binary (>400k), unlike when
rssh is compiled and linked dynamically. You can override static compilation
by removing the -static flag from the CFLAGS macro in Makefile (after
configure is run); however this is only recommended for sites who basically
trust their users, or aren't concerned about the possibility of advanced users
gaining shell access to the host on which access has been restricted via rssh.
Future versions of rssh will include an option to configure to enable/disable
static compilation explicitly, so editing the makefile will not be necessary.
Details
-------
Please note, the flaw is not in rssh itself. The problem is that the OpenSSH
Project's sshd reads $HOME/.ssh/environment when a user first connects
(regardless of whether it's via ssh, scp, or sftp), allowing users to set
variables in their environment. A user could scp a file to that location
containing a line that sets variables such as LD_LIBRARY_PATH and/or
LD_PRELOAD, allowing the user to cause binaries exec()'d by the sshd daemon to
be dynamically linked against libraries of their choosing. This means that
users can cause rssh itself to execute arbitrary code, and the only thing that
you can do to prevent this attack is to control users' environments, and make
absolutely sure they can not write to their .ssh directory.
In OpenSSH 3.4 and before, there is no way to prevent user environment files
from being sourced. As of 3.5, sshd has the option PermitUserEnvironment,
which should be set to no.
Additionally, according to the sshd(8) man page from at least some releases of
OpenSSH, the commands listed in the $HOME/.ssh/rc file are executed with
/bin/sh instead of the user's defined shell. This appears not to be the case
on systems I had available to test on, despite the man page; commands were
executed using the user's configured shell (rssh), which did not allow the
execution. However if it is true on your system, then a malicious user may be
able to circumvent rssh by uploading a file to $HOME/.ssh/rc which will be
executed by /bin/sh on that system.
I recommend that you upgrade to OpenSSH 3.5 as soon as it becomes available,
if you wish to use rssh without restricting ownerships and permissions of
users' home directories, and/or compiling statically.
rssh is a small shell whose purpose is to restrict users to using scp
or sftp, and also provides the facilities to place users in a chroot
jail. It can also be used to lock users out of a system completely.
William F. McCaw identified a minor security flaw in rssh when used
with chroot jails.
|
