rssh-discuss Mailing List for rssh
Brought to you by:
xystrus
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
(1) |
Jul
(15) |
Aug
(33) |
Sep
(5) |
Oct
(15) |
Nov
(8) |
Dec
(4) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(5) |
Feb
|
Mar
(5) |
Apr
(4) |
May
(4) |
Jun
(15) |
Jul
(9) |
Aug
(11) |
Sep
(5) |
Oct
(2) |
Nov
|
Dec
(6) |
2005 |
Jan
(8) |
Feb
(6) |
Mar
(43) |
Apr
(2) |
May
(5) |
Jun
(6) |
Jul
(12) |
Aug
(22) |
Sep
(5) |
Oct
(7) |
Nov
(15) |
Dec
(5) |
2006 |
Jan
(60) |
Feb
(7) |
Mar
(12) |
Apr
(7) |
May
(5) |
Jun
(14) |
Jul
(19) |
Aug
(21) |
Sep
(16) |
Oct
(2) |
Nov
(15) |
Dec
(3) |
2007 |
Jan
|
Feb
|
Mar
|
Apr
(24) |
May
|
Jun
(26) |
Jul
(12) |
Aug
(1) |
Sep
(7) |
Oct
(2) |
Nov
|
Dec
(1) |
2008 |
Jan
(4) |
Feb
(6) |
Mar
(4) |
Apr
(4) |
May
(5) |
Jun
(4) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
(27) |
Mar
(20) |
Apr
(8) |
May
(1) |
Jun
(1) |
Jul
|
Aug
(3) |
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
2010 |
Jan
(3) |
Feb
(1) |
Mar
(3) |
Apr
|
May
|
Jun
(4) |
Jul
(7) |
Aug
(6) |
Sep
(7) |
Oct
(1) |
Nov
|
Dec
|
2011 |
Jan
|
Feb
(5) |
Mar
(5) |
Apr
(16) |
May
|
Jun
(6) |
Jul
(20) |
Aug
(10) |
Sep
(4) |
Oct
|
Nov
|
Dec
(7) |
2012 |
Jan
(5) |
Feb
|
Mar
(9) |
Apr
|
May
(6) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
(5) |
Dec
(6) |
2013 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(2) |
Sep
(3) |
Oct
(1) |
Nov
(1) |
Dec
|
2014 |
Jan
(5) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(7) |
Dec
|
2016 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(11) |
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2019 |
Jan
(8) |
Feb
(17) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2021 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: Logan P. <lo...@so...> - 2022-10-27 01:50:36
|
To those needing the functionality of rssh, I needed an sftp server which would *only* allow file access via sftp, and *only* to files within a virtual filesystem root. Not finding anything which easily satisfied my requirements, and knowing that trying to sufficiently blacklist a permissive-by-default system like openssh is futile, I wrote my own, on top of python's Twisted module. It requires whitelisting (and implementing) features that you want, with no ability to do things you don't give it (the public repo lacks any shell support, for example, though I have added one in some deployments), and quite primitive (silently ignores file attribute setting, doesn't support making symlinks or extensions), but it *does* work quite nicely for sftp / sshfs use. As it is implemented in pure python, the performance is somewhere around 10% of openssh, so don't expect it to handle heavy loads well. By default it only supports rsa keys, but I have used it with ecdsa. In general, twisted's protocol support is excellent, so with a bit of python knowledge you can adapt it to nearly anything you want. scp and rsync are probably out of easy reach, as they normally run a client program on the destination, which would either break the sandbox or have to be dummied within the python virtual filesystem. The latter is the *correct* approach, but is likely more work than is worth doing. I have used it with git by first mounting via sshfs; native git+ssh support is probably possible, but again would require a fair bit of work. Anyway, you can find the code at https://github.com/lp-programming/WorkflowUpload/ As the project name implies, I use it for uploading github build artifacts to offsite storage. Regards, Logan |
From: Spenser T. <tr...@eq...> - 2021-01-27 11:58:04
|
2021-01-21 20:56 GMT-08:00 "Derek Martin" <co...@pi...>: > Hi Spencer, > > As of January 28 of last year I announced that rssh is no longer > maintained. As Russ says, it's just not able to do its job > effectively for a host of reasons. I guess I neglected to update the > web site... I should do that soon. > I wasn't aware of this deprecation (or Russ's CVE) since I only browsed the site; did a source install. For the moment I will use some barebones POSIX shell like (d)ash in a chroot and be done with it. Thank you |
From: Derek M. <co...@pi...> - 2021-01-22 05:09:02
|
Hi Spencer, As of January 28 of last year I announced that rssh is no longer maintained. As Russ says, it's just not able to do its job effectively for a host of reasons. I guess I neglected to update the web site... I should do that soon. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D On Sat, Jan 16, 2021 at 09:50:50PM -0800, Spenser Truex wrote: > From website > http://pizzashack.org/rssh/security.shtml > --- > SECURITY | 16 ++++++++++++++-- > 1 file changed, 14 insertions(+), 2 deletions(-) > > diff --git a/SECURITY b/SECURITY > index 98c1e43..aede2e8 100644 > --- a/SECURITY > +++ b/SECURITY > @@ -8,0 +9,13 @@ have affected rssh since I started developing it. > +Nov 27, 2012 > +A couple of issues have been discovered with command line parsing and validation, which allow rssh to be bypassed. > + > + CVE-2012-3478: Improper filtering of environment variables > + CVE-2012-2252: Improper filtering of rsync command line > + > +August 1, 2010 > +Almost 5 years without a legitimate security issue reported. > + > +John Barber reported a problem where, if the system administrator misconfigures rssh by providing two few access bits in the configuration file, the user will be given default permissions (scp) to the entire system, potentially circumventing any configured chroot. Fixing this required a behavior change: In the past, using rssh without a config file would give all users default access to use scp on an unchrooted system. In order to correct the reported bug, this feature has been eliminated, and you must now have a valid configuration file. If no config file exists, all users will be locked out. > + > +Maarten van der Schrieck noticed a bug where, under conditions which are too far-fetched to describe, the rssh_chroot_helper could crash due to calling fgets with a null pointer. This can not occur with a normal, proper installation of rssh. The code path that causes this can only be reached if the system administrator deliberately installs rssh improperly, and the hoops through which one must jump to get it to occur are substantial, so the security impact here is basically nil. But it is a legitimate bug, so I fixed it nonetheless. > + > @@ -115 +128 @@ The 2.2.0 release of rssh fixed the problem in question, but was > -mistakenly released missing some code for parsing per-user options. > +mistakenly released missing some code for parsing per-user options. > @@ -198 +210,0 @@ with chroot jails. > - > -- > 2.30.0 > > -- > 7E7B 2078 A241 3205 F469 3B21 0AD4 8D58 F9FB DDC6 > Spenser Truex https://equwal.com > _______________________________________________ > rssh-discuss mailing list > rss...@li... > https://lists.sourceforge.net/lists/listinfo/rssh-discuss |
From: Russ A. <ea...@ey...> - 2021-01-17 22:34:41
|
Spenser Truex <tr...@eq...> writes: > From website > http://pizzashack.org/rssh/security.shtml More recently, you should also be aware of CVE-2019-1000018, CVE-2019-3464, and CVE-2019-3463. It turns out to be extremely difficult to do what rssh is attempting to do because the underlying software that it is trying to protect does not cooperate very well (and in some cases could be said to be actively hostile). New mechanisms of bypassing its intended restrictions keep cropping up. For example, I'm fairly sure the CVS support is not secure, although I have not put the effort into figuring out how to break it. You should probably consider rssh deprecated and think about alternatives. My attempts to clean up the last few rounds of problems produced a ton of collateral damage, and I've personally stopped trying to maintain rssh in Debian because I'm not confident that I can make it secure. Here are the most recent changelogs from the Debian package, which should provide a feel for the scope of the problem. This also includes other potential security issues that never received a CVE: rssh (2.3.4-12) unstable; urgency=high * The fix for the scp security vulnerability in 2.3.4-9 combined with the regression fix in 2.3.4-10 rejected the -pf and -pt options, which are sent by libssh2's scp support. Add support for those variants. (LP #1815935) -- Russ Allbery <rr...@de...> Mon, 18 Feb 2019 18:58:27 -0800 rssh (2.3.4-11) unstable; urgency=high * The fix for the scp security vulnerability in 2.3.4-9 introduced a regression that blocked scp of multiple files from a server using rssh. Based on further analysis of scp's command-line parsing, relax the check to require the server command contain -f or -t, which should deactivate scp's support for remote files. (Closes: #921655) -- Russ Allbery <rr...@de...> Sun, 10 Feb 2019 11:17:28 -0800 rssh (2.3.4-10) unstable; urgency=high * Also reject rsync --daemon and --config command-line options, which can be used to run arbitrary commands. Thanks, Nick Cleaton. (CVE-2019-3463) * Unset the HOME environment variable when running rsync to prevent popt (against which rsync is linked) from loading a ~/.popt configuration file, which can run arbitrary commands on the server or redefine command-line options to bypass argument checking. Thanks, Nick Cleaton. (CVE-2019-3464) * Do not stop checking the rsync command line at --, since this can be an argument to some other option and later arguments may still be interpreted as options. In the few cases where one needs to rsync to files named things like --rsh, the client can use ./--rsh instead. Thanks, Nick Cleaton. * Remove now-unused variables from the rsync validation patch. -- Russ Allbery <rr...@de...> Sat, 02 Feb 2019 10:59:47 -0800 rssh (2.3.4-9) unstable; urgency=high * Validate the allowed scp command line and only permit the flags used in server mode and only a single argument, to attempt to prevent use of ssh options to run arbitrary code on the server. This will break scp -3 to a system running rssh, which seems like an acceptable loss. (Closes: #919623, CVE-2019-1000018) * Tighten validation of the rsync command line to require --server be the first argument, which should prevent initiation of an outbound rsync command from the server, which in turn might allow execution of arbitrary code via ssh configuration similar to scp. * Add validation of the server command line after chroot when chroot is enabled. Prior to this change, dangerous argument filtering was not done when chroot was configured, allowing remote code execution inside the chroot in some configurations via the previous two bugs and via the mechanisms in CVE-2012-2251 and CVE-2012-2252. * Document that the cvs server-side dangerous option filtering is probably insufficient and should not be considered secure. -- Russ Allbery <rr...@de...> Mon, 28 Jan 2019 21:03:59 -0800 -- Russ Allbery (ea...@ey...) <https://www.eyrie.org/~eagle/> |
From: Spenser T. <tr...@eq...> - 2021-01-17 06:30:23
|
From website http://pizzashack.org/rssh/security.shtml --- SECURITY | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/SECURITY b/SECURITY index 98c1e43..aede2e8 100644 --- a/SECURITY +++ b/SECURITY @@ -8,0 +9,13 @@ have affected rssh since I started developing it. +Nov 27, 2012 +A couple of issues have been discovered with command line parsing and validation, which allow rssh to be bypassed. + + CVE-2012-3478: Improper filtering of environment variables + CVE-2012-2252: Improper filtering of rsync command line + +August 1, 2010 +Almost 5 years without a legitimate security issue reported. + +John Barber reported a problem where, if the system administrator misconfigures rssh by providing two few access bits in the configuration file, the user will be given default permissions (scp) to the entire system, potentially circumventing any configured chroot. Fixing this required a behavior change: In the past, using rssh without a config file would give all users default access to use scp on an unchrooted system. In order to correct the reported bug, this feature has been eliminated, and you must now have a valid configuration file. If no config file exists, all users will be locked out. + +Maarten van der Schrieck noticed a bug where, under conditions which are too far-fetched to describe, the rssh_chroot_helper could crash due to calling fgets with a null pointer. This can not occur with a normal, proper installation of rssh. The code path that causes this can only be reached if the system administrator deliberately installs rssh improperly, and the hoops through which one must jump to get it to occur are substantial, so the security impact here is basically nil. But it is a legitimate bug, so I fixed it nonetheless. + @@ -115 +128 @@ The 2.2.0 release of rssh fixed the problem in question, but was -mistakenly released missing some code for parsing per-user options. +mistakenly released missing some code for parsing per-user options. @@ -198 +210,0 @@ with chroot jails. - -- 2.30.0 -- 7E7B 2078 A241 3205 F469 3B21 0AD4 8D58 F9FB DDC6 Spenser Truex https://equwal.com |
From: JuanDavi E. <jd...@gm...> - 2020-11-24 23:04:57
|
Hi, I have a machine with freshly installed AWS linux 2. I installed the package rssh When I create a new user using rssh as its login shell, it allows me to connect using sftp, but not send files using scp, even when I have both allowscp allowsftp enabled in /etc/rssh.conf I get the message "This service allows sftp connections only." The strange thing is that if I disable allowsftp I'm still been allowed to use sftp Is there a way to enhance the logging details to see from where does rssh pick up the configuration? I only have one rssh and one rssh.conf on my system Any help will be welcomed Cheers JD PS: I'm not using chroot at all PSII: I can use scp on a normal account, sshd is not disabling it or anything $ cat /etc/rssh.conf > # This is the default rssh config file > > # set the log facility. "LOG_USER" and "user" are equivalent. > logfacility = LOG_USER > > # Leave these all commented out to make the default action for rssh to lock > # users out completely... > > allowscp > allowsftp > #allowcvs > #allowrdist > #allowrsync > # set the default umask > umask = 022 > > # If you want to chroot users, use this to set the directory where the > root of > # the chroot jail will be located. > # > # if you DO NOT want to chroot users, LEAVE THIS COMMENTED OUT. > # chrootpath = /usr/local/chroot > > # You can quote anywhere, but quotes not required unless the path contains > a > # space... as in this example. > #chrootpath = "/usr/local/my chroot" > $ rssh -v > > rssh 2.3.4 > Copyright 2002-2010 Derek D. Martin <rssh-discuss at lists dot sourceforge > dot net> > > rssh config file = /etc/rssh.conf > chroot helper path = /usr/libexec/rssh_chroot_helper > scp binary path = /usr/bin/scp > sftp server binary = /usr/libexec/openssh/sftp-server > cvs binary path = /usr/bin/cvs > rdist binary path = /usr/bin/rdist > rsync binary path = /usr/bin/rsync > |
From: Russ A. <ea...@ey...> - 2019-11-22 17:23:37
|
Russ Allbery <ea...@ey...> writes: > You unfortunately can't. I couldn't convince myself that --daemon was > safe in the rssh security model. I should also add: If you're only using --daemon, consider whether the arguments to rsync vary with each invocation. I suspect that they don't, in which case you could use SSH's force-command option for authorized_keys rather than rssh. This doesn't give you the chroot inherently, but you could write a tiny helper that does the chroot, or use user namespaces to achieve an equivalent end. -- Russ Allbery (ea...@ey...) <https://www.eyrie.org/~eagle/> |
From: Russ A. <ea...@ey...> - 2019-11-22 17:10:28
|
Alain D D Williams <ad...@ph...> writes: > A recent problem with a rsync/rssh setup that has worked since 2012. > This happened since update to rssh-2.3.4-15 a few days ago. Running on > a CentOS 6 machine. > The recent patch forbids the --daemon option - but I need this as I want > an instance of rsync (running over ssh) that exports two modules. The > files in the modules are not publicly visible - thus only available over > ssh as a particular user (public key authentication). > The patch contains the comment: > "Also scan the rsync command line for any --rsh, --config, or --daemon > option and reject it as well. This replaces and improves the upstream > strategy for rejecting that command-line option, taking advantage of > the parsing added to check the -e option. --config can be used to run > commands via "pre-xfer exec" when running as a daemon, plus the client > should not be able to spawn daemons." > So: how do I do this with this patch applied ? You unfortunately can't. I couldn't convince myself that --daemon was safe in the rssh security model. If you can convince yourself that it is, you can remove --daemon from the options that are blocked. Make sure that the configuration file isn't writable by the user via rsync, since otherwise this is trivial RCE, and be sure that other options like --address and --port don't allow someone to do something that you don't expect. -- Russ Allbery (ea...@ey...) <https://www.eyrie.org/~eagle/> |
From: Alain D D W. <ad...@ph...> - 2019-11-22 15:54:37
|
A recent problem with a rsync/rssh setup that has worked since 2012. This happened since update to rssh-2.3.4-15 a few days ago. Running on a CentOS 6 machine. The recent patch forbids the --daemon option - but I need this as I want an instance of rsync (running over ssh) that exports two modules. The files in the modules are not publicly visible - thus only available over ssh as a particular user (public key authentication). The patch contains the comment: "Also scan the rsync command line for any --rsh, --config, or --daemon option and reject it as well. This replaces and improves the upstream strategy for rejecting that command-line option, taking advantage of the parsing added to check the -e option. --config can be used to run commands via "pre-xfer exec" when running as a daemon, plus the client should not be able to spawn daemons." So: how do I do this with this patch applied ? Thanks in advance. Something from /var/log/messages: rssh[27171]: setting log facility to LOG_USER rssh[27171]: setting umask to 022 rssh[27171]: line 52: configuring user someuser rssh[27171]: setting someuser's umask to 0 rssh[27171]: allowing rsync to user someuser rssh[27171]: cmd 'rsync' approved rssh[27171]: cmd 'rsync' approved rssh[27171]: insecure rsync options in rsync command line! rssh[27171]: user someuser attempted to execute forbidden commands rssh[27171]: command: rsync --server --daemon . rssh[27177]: setting log facility to LOG_USER rssh[27177]: setting umask to 022 rssh[27177]: line 52: configuring user someuser rssh[27177]: setting someuser's umask to 0 rssh[27177]: allowing rsync to user someuser rssh[27177]: cmd 'rsync' approved rssh[27177]: cmd 'rsync' approved rssh[27177]: insecure rsync options in rsync command line! rssh[27177]: user someuser attempted to execute forbidden commands rssh[27177]: command: rsync --server --daemon . (Usename changed) /home/someuser/rsyncd.conf [maillist] comment = Maillist backup path = /var/spool/mailman/somemaillist read only = true use chroot = no [mailman] comment = Mailman programs path = /usr/local/mailman/somemaillist/ read only = true use chroot = no My remote user has told me: > ----------8<------------------------------- > insecure rsync options not allowed. > This account is restricted by rssh. > Allowed commands: rsync > > If you believe this is in error, please contact your system administrator. > > rsync: did not see server greeting > rsync error: error starting client-server protocol (code 5) at > main.c(1648) [Receiver=3.1.2] > ----------8<------------------------------- > > > command I'm running is: > > ----------8<------------------------------- > rsync -e ssh -av --delete rsync://som...@li.../somelist/backups/somelistlist/somelist/ > ----------8<------------------------------- > -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: https://www.phcomp.co.uk/Contact.html #include <std_disclaimer.h> |
From: Nick C. <ni...@cl...> - 2019-02-13 09:36:55
|
On Wed, 13 Feb 2019 at 09:00, Nick Cleaton <ni...@cl...> wrote: > > #!/bin/sh > exec nsjail -Mo -R /usr -W /var/spool/frob libcallfilt denyexec > /usr/bin/frob -- "$@" > Sorry, that should be: #!/bin/sh exec nsjail -Mo -R /usr -B /var/spool/frob -- libcallfilt denyexec /usr/bin/frob -- "$@" (nsjail takes -B not -W for a writable part of the filesystem, and I missed out a --) |
From: Nick C. <ni...@cl...> - 2019-02-13 09:00:53
|
On Tue, 12 Feb 2019 at 22:13, Derek Martin <co...@pi...> wrote: > On Fri, Feb 08, 2019 at 09:42:32AM +0000, Nick Cleaton wrote: > > > If the attacker is able to execute arbitrary system code, then they're > > already past the wall that this thing is intended to strengthen. > > Sure, but what I'm trying to point out is that there may be a variety > of ways that could happen that you're not thinking of, and that some > folks may imagine uses for this that you haven't, but which won't > actually be workable, but that won't stop them from blaming you (and > expecting you to do something about it). > That's a very good point, I need to be more clear in the docs about what this thing isn't trying to be. How do you imagine this filter program will be executed? There are a few ways. For example, if you're setting up sudo to allow an unprivileged user to run the frob command as root, and you don't expect frob to execute anything else or write any files outside /var/spool/frob or read any files outside /usr, you might set up a jailed-frob script something like: #!/bin/sh exec nsjail -Mo -R /usr -W /var/spool/frob libcallfilt denyexec /usr/bin/frob -- "$@" ... and allow users to run that via the sudoers file. So now you're protected against frob being tricked into reading or writing the wrong parts of the filesystem, or being tricked into running other commands. You can (and should) also limit the system calls available to frob via nsjail's seccomp support, but blocking execve() at the system call level is problematic because nsjail itself needs to call execve() after setting up the seccomp filters. Something like rssh that gets installed as the user's shell or something that gets installed as an ssh forced command and parses SSH_ORIGINAL_COMMAND (such as rsync's rrsync script) could use it similarly. I don't think rssh in its current form can be used with it, because as far as I can see there's no way to configure the path to the scp/rsync/etc programs that rssh will invoke. |
From: Russ A. <ea...@ey...> - 2019-02-13 02:02:41
|
Derek Martin <co...@pi...> writes: > I believe the patch fails to solve case #2 (the user specifies > PKCS11Provider in ~/.ssh/config), which I believe can only be mitigated > by preventing the user from uploading such a file, e.g. by providing a > "safe" one for the user which is owned by root, not writable by the > user, and having the parent (.ssh) directory also not owned by the user > and not writable by the user. This wouldn't surprise me, but could you explain more about why you say that? I don't see anything in scp that would pay attention to the PKCS11Provider configuration in ~/.ssh/config, so as long as scp doesn't run ssh, I'm not seeing the mechanism whereby this code would be loaded. The code to load it seems to only be in ssh.c. > Making sure that the user's ssh config files are not modifiable by the > user is a standard part of securing rssh, so if the above is done > correctly, IIUC rssh should not actually be vulnerable to this attack at > all. It is, as it has always been, the system administrator's > responsibility to make sure their system is properly configured to > prevent such breaches. I've always tried to offer guidance regarding > that, but I've also been very clear (i.e. in the man page) that it's the > sysadmin's responsibility to stay current with the various services that > are used with rssh, and to configure them properly to prevent bypassing > rssh. This is a fair point, and perhaps it's not worth the effort of trying to provide a security guarantee if the user can add files to .ssh or to the user's home directory. -- Russ Allbery (ea...@ey...) <http://www.eyrie.org/~eagle/> |
From: Derek M. <co...@pi...> - 2019-02-12 22:13:31
|
On Fri, Feb 08, 2019 at 09:42:32AM +0000, Nick Cleaton wrote: > On Fri, 8 Feb 2019 at 01:37, Derek Martin <co...@pi...> wrote: > > > > > [...], you need to know all of the possible ways to execute > > a program from system code on all of your target platforms. And you > > probably don't. And there are probably platform-dependent ways that > > it could be done using inline assembly that would be hard or > > impossible for you to block even if you did... > > > > If the attacker is able to execute arbitrary system code, then they're > already past the wall that this thing is intended to strengthen. Sure, but what I'm trying to point out is that there may be a variety of ways that could happen that you're not thinking of, and that some folks may imagine uses for this that you haven't, but which won't actually be workable, but that won't stop them from blaming you (and expecting you to do something about it). How do you imagine this filter program will be executed? It clearly can't be the user's shell, since a) it requires arguments to do anything useful, yet there is no way to pass them to the the shell when a user logs in, and b) the necessarily needs to be able to execute other programs (or else it must implement everything the user should be able to do internally, in some fashion). So that means typically, the user's shell must be some other program (perhaps some fork of rssh, for example) which has been taught to use the filter. But there's no guarantee that program will use it correctly, or that some flaw in that program or changes to OpenSSH or some system feature won't allow the complete bypass of whatever that program is (as we've seen repeatedly with rssh), or that the user can find a way to insert some other preload library before yours comes into play, preventing it from coming into play (e.g. the PKCS11Provider we've been talking about in regard to rssh). Unless you can predict all the ways that can happen, now and forever, and can ensure that they will always be under your control--which I'm fairly sure you can't--you have created for yourself a very hard task. That is where rssh finds itself. I'm not trying to discourage you, or to suggest it's not worth trying, I'm just trying to give you some perspective on what you may be signing up for by authoring such software. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Derek M. <co...@pi...> - 2019-02-12 21:19:36
|
On Thu, Jan 17, 2019 at 07:00:21PM -0800, Russ Allbery wrote: > Here is a COMPLETELY UNTESTED patch that might fix this problem. If I can > find the time, I'll try to do some testing and patch the Debian package. > > If anyone else who is still using rssh has a chance to look at this, test, > do code review, etc., that would be much appreciated. This is based on > looking at the source code of OpenSSH 7.9p1, so it's entirely possible > that other versions need to pass other arguments that aren't accepted > here. I believe the patch fails to solve case #2 (the user specifies PKCS11Provider in ~/.ssh/config), which I believe can only be mitigated by preventing the user from uploading such a file, e.g. by providing a "safe" one for the user which is owned by root, not writable by the user, and having the parent (.ssh) directory also not owned by the user and not writable by the user. Another way to mitigate this, I believe, is to specify the system's correct PKCS11Provider (or, I believe, a completely bogus one) in the user's authorized_keys file, in the options field of every authorized key, which overrides whatever the user asked for. Again, the file must not be modifiable by the user. Making sure that the user's ssh config files are not modifiable by the user is a standard part of securing rssh, so if the above is done correctly, IIUC rssh should not actually be vulnerable to this attack at all. It is, as it has always been, the system administrator's responsibility to make sure their system is properly configured to prevent such breaches. I've always tried to offer guidance regarding that, but I've also been very clear (i.e. in the man page) that it's the sysadmin's responsibility to stay current with the various services that are used with rssh, and to configure them properly to prevent bypassing rssh. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Russ A. <ea...@ey...> - 2019-02-08 21:37:52
|
Nick Cleaton <ni...@cl...> writes: > No, with --server and --daemon (as opposed to just --daemon) you get an > rsync daemon connection over an ssh transport, it doesn't listen on a > tcp port. Oh! I had no idea that was a thing. Thank you. -- Russ Allbery (ea...@ey...) <http://www.eyrie.org/~eagle/> |
From: Nick C. <ni...@cl...> - 2019-02-08 21:24:01
|
On Fri, 8 Feb 2019 at 17:50, Russ Allbery <ea...@ey...> wrote: > Nick Cleaton <ni...@cl...> writes: > > > rsync -av -e ssh /my/thing us...@rs...::backups/ > > Don't you lose SSH authentication this way? You're spawning a separate > daemon that I think is now using the built-in rsync authentication, which > is just password (or nothing), so an attacker can then just connect > directly to the daemon that you've spawned. > No, with --server and --daemon (as opposed to just --daemon) you get an rsync daemon connection over an ssh transport, it doesn't listen on a tcp port. http://man7.org/linux/man-pages/man1/rsync.1.html#USING_RSYNC-DAEMON_FEATURES_VIA_A_REMOTE-SHELL_CONNECTION I was wrong about being able to use the user@server syntax though, apparently you have to use -e "ssh -l $username" instead. > -- > Russ Allbery (ea...@ey...) <http://www.eyrie.org/~eagle/> > > |
From: Russ A. <ea...@ey...> - 2019-02-08 17:50:48
|
Nick Cleaton <ni...@cl...> writes: > If you really want the rsync protocol then a forced command of "${things > such as nsjail and libcallfilt go here} rsync --server --daemon --config > /etc/some-rsyncd.conf ." is probably about as solid as you can get it: > rsync in daemon mode is designed to interact with an untrusted user, and > you get to set which parts of the filesystem are readable and writable > in /etc/some-rsyncd.conf. > You do have to adapt the rsync client command though, to work in terms of > modules defined in your rsyncd.conf rather than file paths: > rsync -av -e ssh /my/thing us...@rs...::backups/ Don't you lose SSH authentication this way? You're spawning a separate daemon that I think is now using the built-in rsync authentication, which is just password (or nothing), so an attacker can then just connect directly to the daemon that you've spawned. -- Russ Allbery (ea...@ey...) <http://www.eyrie.org/~eagle/> |
From: Nick C. <ni...@cl...> - 2019-02-08 09:42:57
|
On Fri, 8 Feb 2019 at 01:37, Derek Martin <co...@pi...> wrote: > > [...], you need to know all of the possible ways to execute > a program from system code on all of your target platforms. And you > probably don't. And there are probably platform-dependent ways that > it could be done using inline assembly that would be hard or > impossible for you to block even if you did... > If the attacker is able to execute arbitrary system code, then they're already past the wall that this thing is intended to strengthen. It's value is in preventing them from getting to that point in the first place via tricky options that lead commands to exec attacker-controlled things. Also, I have heard rumours of commands that helpfully fire up an editor on error, which is exactly what you don't want when trying to restrict a user. This would be mitigated by blocking exec()s, and maybe other insane behaviours that none of us yet know of would also be trapped. [snip code review] > Thanks for taking the time to do that, you make several good points which I'll incorporate. |
From: Nick C. <ni...@cl...> - 2019-02-08 09:22:38
|
On Fri, 8 Feb 2019 at 02:37, Russ Allbery <ea...@ey...> wrote: > Derek Martin <co...@pi...> writes: > > It may also be worth noting that this wouldn't have blocked the recent > security vulnerability around SSH config handling, where scp on the server > side could be tricked into reading an uploaded SSH config file that > specifies an uploaded shared object to dynamically load and execute as a > PKCS#11 provider. :( > Yes and no. If you were intentionally allowing scp in client mode to make outgoing connections from your server then you couldn't use libcallfilt with it in its current form anyway, as you'd have to allow scp to exec ssh to function. However if you only wanted to allow scp so that people can scp things to and from your server then libcallfilt would prevent it from exec-ing ssh even if you failed at restricting the options to enforce server mode. Even my idea presented earlier on the list of forcing a specific rsync > command line on the server side (which could then be implemented with SSH > force-command) *still* is exploitable if the home directory of the user is > writable because of rsync popt support loading ~/.popt. Writable $HOME seems pretty risky in general for command restriction, I suspect the ~/.popt thing is just one of many. sftp is probably closer to the "correct" solution to this problem. The > Subsystem facility that it uses avoids passing things through shells, and > it can be used with ChrootDirectory to enforce a file namespace. And it > won't have "features" like loading popt configuration files. > A restricted view of the filesystem is certainly good, if not using a command built into ssh it would make sense to nsjail/firejail/bubblewrap the executed command to get seccomp filters and filesystem limiting. If you really want the rsync protocol then a forced command of "${things such as nsjail and libcallfilt go here} rsync --server --daemon --config /etc/some-rsyncd.conf ." is probably about as solid as you can get it: rsync in daemon mode is designed to interact with an untrusted user, and you get to set which parts of the filesystem are readable and writable in /etc/some-rsyncd.conf. You do have to adapt the rsync client command though, to work in terms of modules defined in your rsyncd.conf rather than file paths: rsync -av -e ssh /my/thing us...@rs...::backups/ |
From: Nick C. <ni...@cl...> - 2019-02-08 08:29:12
|
On Thu, 7 Feb 2019 at 19:19, Russ Allbery <ea...@ey...> wrote: > > BTW, you probably want to add posix_spawn, posix_spawnp, and execveat. > Thanks, I'll add those. |
From: Russ A. <ea...@ey...> - 2019-02-08 02:37:24
|
Derek Martin <co...@pi...> writes: > This seems potentially useful, but I'm concerned this is just another > example of something that seems like a good idea in principle (like > rssh), but perhaps depending on the exact use cases, is hard to do in > practice, and Russ hints at some of the why. If someone is serious > about bypassing your access restrictions, they're not going to stick to > doing what a well-behaved program might do. To get this right, in the > general case, you need to know all of the possible ways to execute a > program from system code on all of your target platforms. And you > probably don't. And there are probably platform-dependent ways that it > could be done using inline assembly that would be hard or impossible for > you to block even if you did... It may also be worth noting that this wouldn't have blocked the recent security vulnerability around SSH config handling, where scp on the server side could be tricked into reading an uploaded SSH config file that specifies an uploaded shared object to dynamically load and execute as a PKCS#11 provider. :( Even my idea presented earlier on the list of forcing a specific rsync command line on the server side (which could then be implemented with SSH force-command) *still* is exploitable if the home directory of the user is writable because of rsync popt support loading ~/.popt. One can block exec from there with something like this wrapper as well, but it still allows aliasing command line options and thus changing the effective rsync command being executed to some other command with different options, such as --daemon. It's harder to get to code execution with exec blocked, but spawning a daemon on the server listening on the rsync port is at least not great and may well have some other exploit path. sftp is probably closer to the "correct" solution to this problem. The Subsystem facility that it uses avoids passing things through shells, and it can be used with ChrootDirectory to enforce a file namespace. And it won't have "features" like loading popt configuration files. -- Russ Allbery (ea...@ey...) <http://www.eyrie.org/~eagle/> |
From: Derek M. <co...@pi...> - 2019-02-08 01:38:33
|
Hey... On Thu, Feb 07, 2019 at 11:19:26AM -0800, Russ Allbery wrote: > Nick Cleaton <ni...@cl...> writes: > > https://github.com/ncleaton/libcallfilt > > > It provides a second line of defense if you've tried to block all of the > > options that could exec arbitrary things but you may have missed > > something. > > Thank you -- that's an interesting option! > > BTW, you probably want to add posix_spawn, posix_spawnp, and execveat. > (Although a nice property of this approach is that it doesn't rely on > finding every possible system call, only covering the ones that the > legitimate program you're trying to spawn might use.) ...assuming the program is legitimate, and hasn't been replaced somehow by a more nefarious version... This seems potentially useful, but I'm concerned this is just another example of something that seems like a good idea in principle (like rssh), but perhaps depending on the exact use cases, is hard to do in practice, and Russ hints at some of the why. If someone is serious about bypassing your access restrictions, they're not going to stick to doing what a well-behaved program might do. To get this right, in the general case, you need to know all of the possible ways to execute a program from system code on all of your target platforms. And you probably don't. And there are probably platform-dependent ways that it could be done using inline assembly that would be hard or impossible for you to block even if you did... As a quick example, in Linux most system calls can be called indirectly via the syscall() system call, which AFAICT would bypass your filter. I'm not sure it's practical to block syscall() as glibc probably uses it directly, and while it would be uncommon, some system utilities you might want to use may use it also (I personally have written code that calls it). There's probably something equivalent on some other platforms, and it's probably called something other than syscall()... You also have to think very hard about what is being executed, and whether it provides any means for an attacker to upload/execute arbitrary program code. Having been through that, I can tell you there are some pretty obscure features of SSH, and of the underlying OS and its utilities, that make that task very difficult. And new ones get added over time. So no matter how simple the task might seem when you start, it's not, and it's never finished. As for your code... [Some of this will be nit-picky, some will definitely not be. I think being nit-picky in security contexts is REQUIRED.] At a quick glance, I note that you use EACCES, but FWIW I think the more appropriate errno here would be EPERM. EACCES is usually used for things like "you don't have appropriate ACL bits to do that" whereas EPERM is usually more like "Letting you do that could be dangerous, so I'm not gonna." I suppose it's a judgement call, and TBH we probably didn't need both to begin with. Also I note you don't check the return value of setenv(), which could result in complete bypass of the filter. You also do not check the return value from your snprintf() calls. It doesn't look exploitable, but if LD_PRELOAD was already set to something long, and you actually needed that, it would likely break. That'd be rare and unlikely to be an issue for most installations, but nevertheless it's an unnecessary limitation caused by a bug. And you don't cast the return value of malloc(). Not in and of itself a problem, but you should always compile security-sensitive programs with -Wall -Werror, so you don't miss anything stupid, and if you do that I believe this will fail to compile. I think the better approach would be: ... /* don't do expensive malloc unless we need to. Usually we don't need to. */ char buf[48]; // Use a macro... char *mem = buf; int size = snprintf(buf, 48, ...); // Use the macro, Luke! if (size > 48){ // Use the macro, Luke! mem = (char *)malloc(++size); int s = snprintf(mem, size, ...); /* impossible, but sometimes impossible things happen! */ if (s > size) { explode(); } } if (setenv(var, mem ...) == -1) explode(); // either don't bother with free(), or set some flag so you know you // need to. Since you're about to execvp(), it's superfluous. ... Obviously for brevity, I left out a few of the details you already included. Some bits of the above (e.g. ++size) might feel more clever than clear; if so rewrite accordingly. Hopefully it's clear that explode() is shorthand for "something went wrong; don't continue to do what the user asked for..." One last point: I generally recommend(ed) that people use rssh in a chroot, statically linked, unless they had a good reason not to. One reason for static linking in security-sensitive applications is to prevent LD_PRELOAD and similar from being an attack vector, but making use of that fact also eliminates the potential usefulness of a filter like this entirely. To that point: If your attackers had any sort of ability to control what was being executed--intentionally or not--they could simply execute a statically-linked version that bypasses your filter. Security is hard... :( -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Russ A. <ea...@ey...> - 2019-02-07 19:19:37
|
Nick Cleaton <ni...@cl...> writes: > I made this, it might be interesting to anyone looking to implement > something like rssh, or to un-retire rssh itself: it allows you to > execute a program but trap any calls to libc exec* syscall wrappers that > the program might make: > https://github.com/ncleaton/libcallfilt > It provides a second line of defense if you've tried to block all of the > options that could exec arbitrary things but you may have missed > something. Thank you -- that's an interesting option! BTW, you probably want to add posix_spawn, posix_spawnp, and execveat. (Although a nice property of this approach is that it doesn't rely on finding every possible system call, only covering the ones that the legitimate program you're trying to spawn might use.) -- Russ Allbery (ea...@ey...) <http://www.eyrie.org/~eagle/> |
From: Nick C. <ni...@cl...> - 2019-02-07 14:05:24
|
I made this, it might be interesting to anyone looking to implement something like rssh, or to un-retire rssh itself: it allows you to execute a program but trap any calls to libc exec* syscall wrappers that the program might make: https://github.com/ncleaton/libcallfilt It provides a second line of defense if you've tried to block all of the options that could exec arbitrary things but you may have missed something. |
From: Russ A. <ea...@ey...> - 2019-02-02 19:21:58
|
Hi all, We've just released another security update for the rssh package in Debian, this time for vulnerabilities in the rsync support. These bugs will also affect most other installations of rssh if rsync is enabled. Both problems were discovered by Nick Cleaton. CVE-2019-3463 The client could send the --daemon and --config options to the server and they would be passed through by rssh. Not only does this allow the client to start a daemon listening on the normal rsync port, which is probably not desirable, but various options set in the daemon configuration file specified with --config allow arbitrary code execution. (The most obvious is pre-xfer exec.) CVE-2019-3463 If rsync is built with popt (as it is in Debian), the popt library will attempt to open and parse ~/.popt on the server and interpret it as configuration for command line option parsing. If the client can rsync a .popt file to the home directory of the user protected with rssh, this allows arbitrary code execution on the server via several paths. The most obvious is via the popt exec feature which execs an arbitrary program as an external option filter, but a more sneaky approach is through the popt alias feature which allows one to alias a benign option (such as --server) to one that will run arbitrary code (such as --rsh). The second vulnerability is an excellent example of how hard this problem is and how the tools that rssh is attempting to provide are working directly against its security model. I personally had no idea that popt even existed, having missed it in the rsync man page (which is rather long) and not deeply investigated the shared library dependencies of rsync. But even if I'd known it existed, the exec feature is rather inobvious and unexpected, as is the interaction with aliases. The workaround for this popt issue is to unset the HOME environment variable, which disables popt's attempt to load ~/.popt in at least the version currently in Debian. Note that this is fragile: if the popt developers ever decide to fall back on getpwnam to find the home directory, this will stop working. A safer approach (which can't easily be done in rssh itself) is to ensure that the home directory of an rssh user is not writable by that user. Attached is an updated patch for the rsync support that incorporates fixes for these two problems, as well as a separate problem where one could hide insecure options from rssh by passing "--" as the *argument* to some other option that takes an argument, causing rssh to stop parsing for options but rsync to continue parsing options. This means that -- can no longer be used to stop rssh's option analysis, but other normal workarounds can be used, such as prepending ./ to paths that start with -. As mentioned previously, I think the takeaway is that we all need to stop using rssh and find a more robust solution. But I'll continue to provide security support for the Debian stable package over the lifetime of Debian stretch if possible, since that was the commitment I made when I uploaded the package to Debian. -- Russ Allbery (ea...@ey...) <http://www.eyrie.org/~eagle/> |