Thread: [PATCH] Add 2010, 2012 Security notices to SECURITY
Brought to you by:
xystrus
From: Spenser T. <tr...@eq...> - 2021-01-17 06:30:23
Attachments:
signature.asc
|
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: 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: Derek M. <co...@pi...> - 2021-01-22 05:09:02
Attachments:
signature.asc
|
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: 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 |