rssh-discuss Mailing List for rssh (Page 2)
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: Derek M. <co...@pi...> - 2019-02-01 20:24:31
|
On Mon, Jan 28, 2019 at 09:50:36PM -0800, Russ Allbery wrote: > I may write some really stripped-down version of the same basic idea for > my own use that ignores the command sent by the client and just always > runs rsync --server with a bunch of standard options. That is obviously the best possible approach, but also obviously gives up all measure of flexibility. Still, it should suffice for the majority of use cases. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Russ A. <ea...@ey...> - 2019-01-29 16:35:29
|
"Thomas Kurschel" <to...@gm...> writes: > In FreeBSD 12.0, basename(3) was changed to be POSIX compliant. This > implies that the function can possibly write to the passed > string. Actually, basename always writes to the passed string under > FreeBSD 12.0. > rssh passes a const string, so it always crashes on invocation. > Attached is a patch that makes a copy of the string first and passes it > instead. > Could you please apply it? Hi Thomas, rssh is no longer maintained. The blacklist approach that it uses to unsafe arguments to the various commands it tries to protect has proven too fragile in practice, and even crafting a whitelist is quite challenging given how complicated, and undocumented, the server mode for many commands is. On top of that, OpenSSH tends to add new features that cause other security problems. I'm going to be pulling it from Debian before the next stable release, and would recommend that others who use it move away from it. Sadly, there isn't a great replacement -- the problem that it's trying to solve is quite hard. -- Russ Allbery (ea...@ey...) <http://www.eyrie.org/~eagle/> |
From: Thomas K. <to...@gm...> - 2019-01-29 09:21:16
|
In FreeBSD 12.0, basename(3) was changed to be POSIX compliant. This implies that the function can possibly write to the passed string. Actually, basename always writes to the passed string under FreeBSD 12.0. rssh passes a const string, so it always crashes on invocation. Attached is a patch that makes a copy of the string first and passes it instead. Could you please apply it? Thank you |
From: Russ A. <ea...@ey...> - 2019-01-29 05:50:50
|
Derek Martin <co...@pi...> writes: > Yes, although given how hard solving this problem actually is, I don't > think there exists any workable solution (for the general case--see > below). By the way, AFAICT, the only reasonable alternative to RSSH I > know of is scponly, and it looks like it was last updated less recently > than RSSH was. I can't speak to how good a job it does at closing up > all the holes as I've not tried to evaluate that since circa 2003. rush showed up a little while ago in Debian: http://puszcza.gnu.org.ua/software/rush/ I looked through the documentation a bit, but haven't really examined it. It has a rather complex configuration language that lets you write various rules specifying what to allow and deny, but I'm pretty dubious that it's possible to write good enough rules to make this safe. rsync comes with a script called rrsync that provides rssh-like functionality only for the server side of rsync. It fully parses the command line and tries to make sure that people don't rsync outside of a particular path, and apparently processes rsync source code to figure out what options to allow. It *might* be safe? > The task wass complicated further by people continually asking for > support for additional programs or features (which pretty much > universally were very obviously not securable, FWIW), and my own caving > to some of those requests (CVS, rsync in particular) when I should've > known better... As Russ says, these things keep cropping up, as OS > features, OpenSSH features, or features of the other tools RSSH is meant > to safeguard, evolve. Yeah, there were a ton more requests for new programs in both Debian and Ubuntu, and I said yes to one of them (svnserve) and then learned my lesson and said no to all the rest. People really want some sort of safe remote restricted shell for various commands, but doing this as a very simple general wrapper is extremely hard. > For serious security applications, RSSH should be considered > insecurable, and unmaintained, from this point on. One of these days, I > should really get around to updating the website to reflect that... > My thanks to Russ for his efforts with the Debian package, and for > providing some level of support when I was not paying much attention, > for so long. Thank you for providing a really useful tool! I've made a lot of use of it over the years as defense in depth where the other end is semi-privileged, so I'm not super-worried, but I'd still rather limit the blast radius if something goes wrong. (Mostly for internal backups via rsync, to be honest.) It's been a good run. :) Alas, security is really hard. I may write some really stripped-down version of the same basic idea for my own use that ignores the command sent by the client and just always runs rsync --server with a bunch of standard options. -- Russ Allbery (ea...@ey...) <http://www.eyrie.org/~eagle/> |
From: Russ A. <ea...@ey...> - 2019-01-29 05:39:58
|
Russ Allbery <ea...@ey...> writes: > I suspect that the rsync protocol is also vulnerable to a version of > this same bug if .ssh/config is writable and is used as the ssh client > path and the ssh binary is available on the server side, by sending an > rsync command that tries to copy a file to localhost: similar to your > second attack example. I believe tightening rssh's check that the rsync > command line starts with --server would address that, since I think (but > haven't confirmed) that will disable remote copies. > It seems likely that there's some way of abusing cvs as well, given its > huge command surface. Hi all, I finally had a chance to dig into this a little more, since I owe rssh users in Debian stable some security support. The short version is that I think I've patched up the obvious ways to exploit this cluster of vulnerabilities via rsync or scp, but I'm not at all convinced that I've found all the other routes in (and I think it's quite likely there's some lingering way in via the cvs support, since the attack surface for cvs is just so large). Attached are three patches: the first adds argument checking for scp, the second is an update of the earlier rsync patch that tightens its argument checking and requires rsync be put into server mode (which looks like it will prevent initiation of outbound ssh connections, which would be another route to this same exploit), and the third applies argument checking to commands run inside a chroot. It turns out that rssh was never checking arguments if run via a chroot, and I didn't notice because I personally use it as a mild defense in depth where a chroot didn't feel important. (This last was pointed out to me by another list member in private email. I'm not naming you explicitly since I wasn't sure if you wanted to be mentioned on-list, but feel free to claim credit -- that was a great catch!) I've uploaded a new version of the Debian package to unstable with these fixes and will work with the Debian security team on a stable fix. However, once the new Debian package propagates to testing, I expect to request that it be removed (in advance of our upcoming new Debian stable release), so it will not be in the next release of Debian. I think it's time; we know the security model isn't the greatest, and I suspect we'll uncover more problems like this and I don't want to provide security support through another release cycle. -- Russ Allbery (ea...@ey...) <http://www.eyrie.org/~eagle/> |
From: Derek M. <co...@pi...> - 2019-01-23 21:21:21
|
On Thu, Jan 17, 2019 at 07:00:21PM -0800, Russ Allbery wrote: > Honestly, those of us still using this program should probably abandon it > and find some other solution. Yes, although given how hard solving this problem actually is, I don't think there exists any workable solution (for the general case--see below). By the way, AFAICT, the only reasonable alternative to RSSH I know of is scponly, and it looks like it was last updated less recently than RSSH was. I can't speak to how good a job it does at closing up all the holes as I've not tried to evaluate that since circa 2003. > The programs it tries to support are rather ill-behaved and make > this sort of security model almost impossible to maintain, as > witness by the fact that things like this keep coming up. You have no idea. Well, OK, *YOU* have some idea. =8^) The task wass complicated further by people continually asking for support for additional programs or features (which pretty much universally were very obviously not securable, FWIW), and my own caving to some of those requests (CVS, rsync in particular) when I should've known better... As Russ says, these things keep cropping up, as OS features, OpenSSH features, or features of the other tools RSSH is meant to safeguard, evolve. A robust solution would really require the OpenSSH folks to take this problem seriously and build in support to their own tools. Trying to provide a generalized solution is too complicated, and I've long since lost interest in solving the problem. [OpenSSH sort of does this now, since I believe OpenSSH 4.9, including chroot, but AFAIK only for sftp--another reason I "deprioritized" working on RSSH.] For serious security applications, RSSH should be considered insecurable, and unmaintained, from this point on. One of these days, I should really get around to updating the website to reflect that... My thanks to Russ for his efforts with the Debian package, and for providing some level of support when I was not paying much attention, for so long. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Russ A. <ea...@ey...> - 2019-01-18 03:48:35
|
Russ Allbery <ea...@ey...> writes: > + for ( ; vec && *vec; vec++ ){ At least one bug: this needs to be for ( vec++; vec && *vec; vec++ ){ since the first argument is "scp". I suspect that the rsync protocol is also vulnerable to a version of this same bug if .ssh/config is writable and is used as the ssh client path and the ssh binary is available on the server side, by sending an rsync command that tries to copy a file to localhost: similar to your second attack example. I believe tightening rssh's check that the rsync command line starts with --server would address that, since I think (but haven't confirmed) that will disable remote copies. It seems likely that there's some way of abusing cvs as well, given its huge command surface. -- Russ Allbery (ea...@ey...) <http://www.eyrie.org/~eagle/> |
From: Russ A. <ea...@ey...> - 2019-01-18 03:17:24
|
Vlad Grigorescu <vl...@es...> writes: > I'd like to make you aware of the following issue we discovered in rssh. > (Most recent version available at: > https://esnet-security.github.io/vulnerabilities/20190115_rssh) Thank you for the notice! > Our setup for these commands is: >> scp bad.so rssh_user@host: > 1. From the command line: >> ssh rssh_user@host 'scp -o PKCS11Provider=./bad.so 1 localhost:' > 2. Using the default .ssh/config file (uploaded to the server first): >> ssh rssh_user@host 'scp 1 localhost:' > 3. By specifying our own ssh_config file (uploaded to the server first): >> ssh rssh_user@host 'scp -F rssh.config 1 localhost:' Yeah, this is the typical rssh problem, which is that a blacklist isn't at all sufficient and the server side of these programs support way too many features. Honestly, those of us still using this program should probably abandon it and find some other solution. The programs it tries to support are rather ill-behaved and make this sort of security model almost impossible to maintain, as witness by the fact that things like this keep coming up. But in the name of keeping things limping forward for those of us who haven't migrated yet, I took a quick look at this. 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. -- Russ Allbery (ea...@ey...) <http://www.eyrie.org/~eagle/> |
From: Vlad G. <vl...@es...> - 2019-01-16 22:09:42
|
Greetings, I'd like to make you aware of the following issue we discovered in rssh. (Most recent version available at: https://esnet-security.github.io/vulnerabilities/20190115_rssh) Regards, --ESnet Security team Issue: -------- We discovered a vulnerability in rssh where users could bypass the "allowscp" restriction and have arbitrary command execution. Background: ----------------- >From the rssh home page[1]: rssh is a restricted shell for use with OpenSSH, allowing only scp and/or > sftp. It now also includes support for rdist, rsync, and cvs. For example, > if you have a server which you only want to allow users to copy files off > of via scp, without providing shell access, you can use rssh to do that. The "allowscp" option is intended to restrict users to only being able to scp files to or from the server, and not be able to run commands on the server. When a user runs scp on their client, an scp command is also run on the server. This runs through rssh (the restricted user's shell), which attempts to verify the arguments are "secure." We can control exactly which scp command is run on the server by supplying it as an argument to ssh. If rssh considers our invocation secure, it will execute that command. Exploit: ---------- The verification that rssh attempts on the scp command is incomplete. The PKCS11Provider option will cause scp to load an arbitrary shared object file. By uploading a malicious .so file which will execute code when loaded, and then setting the PKCS11Provider option to that file, our scp command will execute the code. This option can be invoked one of three ways. In each of these methods, we're using scp to copy a file to localhost over ssh, which causes ssh to be invoked, loading and executing our malicious .so file. Our setup for these commands is: > scp bad.so rssh_user@host: 1. From the command line: > ssh rssh_user@host 'scp -o PKCS11Provider=./bad.so 1 localhost:' 2. Using the default .ssh/config file (uploaded to the server first): > ssh rssh_user@host 'scp 1 localhost:' 3. By specifying our own ssh_config file (uploaded to the server first): > ssh rssh_user@host 'scp -F rssh.config 1 localhost:' With a config file, it's contents should be: > PKCS11Provider ./bad.so Discovery: -------------- For a detailed write-up of how we discovered this issue, see our SANS 2018 Holiday Hack report[2]. Remediation: ----------------- Unknown. The author of rssh replied to our report saying that the software is no longer maintained. Disclosure & Timeline: ----------------------------- Jan 7, 2019: rssh author notified Jan 9, 2019: rssh author replied, saying "RSSH is no longer maintained." Jan 14, 2019: SANS notified Jan 16, 2019: Publication, CVE requested through [Distributed Weakness Filing](https://iwantacve.org), e-mailed rssh-discuss list Credit: --------- This issue was discovered by the ESnet Security Team. It was discovered as part of our participation in the SANS 2018 Holiday Hack Challenge[3]. References: ---------------- [1] - rssh homepage: <http://www.pizzashack.org/rssh/> [2] - ESnet Holiday Hack report: < https://software.es.net/sans-holiday-hack-2018/#org55a074b> [3] - SANS Holiday Hack: <https://www.holidayhackchallenge.com/2018/> |
From: Éric P. <Eri...@cc...> - 2018-12-18 19:49:21
|
Classification: UNCLASSIFIED Which protocol did you try? There’s an rssh config file to enforce certain protocol, also check the passwd file and make sure the user is pointed to rssh logon. Based on the config you can allow ssh traffic for example and block SFTP, it kind of micro manages the access methodology and was great for CHROOT purposes. From the looks of it, you attempted to login to the server via a protocol you didn’t allow. Honestly, would not use this anymore, it hasn’t been supported in years AFAIK. Éric Périard Laboratory Administrator | Administrateur du laboratoire Canadian Centre for Cyber Security | Centre canadien pour la cybersécurité Email | Courriel: Eri...@cy...<mailto:Eri...@cy...> Website | Site Web: https://www.cyber.gc.ca/ Government of Canada | Gouvernement du Canada [Description: cid:image001.png@01D45A34.EFE3A5E0] NOTICE: This message and accompanying attachments contain information that is intended only for the use of the individual or entity to which it is addressed. Any dissemination, distribution, copying or action taken in reliance on the contents of this communication by anyone other than the intended recipient is strictly prohibited. If you have received this communication in error, please notify the sender immediately at the above address and delete the e-mail. AVIS : Le présent message et toutes les pièces jointes qui l'accompagnent contiennent de l'information destinée uniquement à la personne ou à l'entité à laquelle elle est adressée. Toute diffusion, distribution ou copie de son contenu par une autre personne que son destinataire est strictement interdite. Si vous avez reçu ce message par erreur, veuillez informer immédiatement l’expéditeur à l’adresse ci-dessus puis l’effacer. From: keith stone <kei...@gm...> Sent: December 18, 2018 2:29 PM To: rss...@li... Subject: Rssh on rhel7 Hi. I just installed rssh v2. 3.4 When I run the shell I get This account is restricted by rssh. This user is locked out. If you believe this is in error, please contact your system administrator. But the account is not locked out.. Any ideas? |
From: keith s. <kei...@gm...> - 2018-12-18 19:28:51
|
Hi. I just installed rssh v2. 3.4 When I run the shell I get This account is restricted by rssh. This user is locked out. If you believe this is in error, please contact your system administrator. But the account is not locked out.. Any ideas? |
From: Nico Kadel-G. <nk...@gm...> - 2016-10-11 01:25:56
|
On Mon, Oct 10, 2016 at 1:56 PM, Derek Martin <co...@pi...> wrote: > On Sat, Oct 08, 2016 at 07:15:09PM -0400, Nico Kadel-Garcia wrote: >> If it's going to be unmaintained and left that way, then please >> disable it and consider dropping in a reference to my tool, especially >> rather than leaving an executable in place that fails without error >> message. It's confusing to anyone who sees your old source code. > > We've already discussed this at length Nico, I'm not going to repeat > myself. If you need a reminder the discussion is in the list > archives. It's been a while, and I'm asking again with different details. I'm specifically asking you, now, to delete or *disable* the old tool as out of date and unmaintained, not to accept my offered patches. |
From: Derek M. <co...@pi...> - 2016-10-10 17:57:14
|
On Sat, Oct 08, 2016 at 07:15:09PM -0400, Nico Kadel-Garcia wrote: > If it's going to be unmaintained and left that way, then please > disable it and consider dropping in a reference to my tool, especially > rather than leaving an executable in place that fails without error > message. It's confusing to anyone who sees your old source code. We've already discussed this at length Nico, I'm not going to repeat myself. If you need a reminder the discussion is in the list archives. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Nico Kadel-G. <nk...@gm...> - 2016-10-08 23:15:18
|
On Sat, Oct 8, 2016 at 6:52 PM, Derek Martin <co...@pi...> wrote: > On Wed, Oct 05, 2016 at 09:00:59AM -0400, Nico Kadel-Garcia wrote: >> > The mkchroot.sh script in the distribution does an okay job for Linux >> > systems but is probably missing a ton of stuff for FreeBSD. There's a >> > bunch more details in the CHROOT file. >> >> It's pretty seriously out of date. I've published a much more recent >> one, at https://github.com/nkadel/rssh-chroot-tools I've offered it >> before. > > The thing is, the script was never really meant to solve the > problem... I only created it because I needed to set up chroot jails > in order to test chroot. I provided it since I'd already done the > work, and saw no reason not to; but I only ever meant it to serve as > a guide, to illustrate the kinds of things you need to do. It is > therefore not maintained, and was never meant to be. If it's going to be unmaintained and left that way, then please disable it and consider dropping in a reference to my tool, especially rather than leaving an executable in place that fails without error message. It's confusing to anyone who sees your old source code. Nico Kadel-Garcia > -- > Derek D. Martin > http://www.pizzashack.org/ > GPG Key ID: 0x81CFE75D > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > rssh-discuss mailing list > rss...@li... > https://lists.sourceforge.net/lists/listinfo/rssh-discuss > |
From: Derek M. <co...@pi...> - 2016-10-08 22:52:41
|
On Wed, Oct 05, 2016 at 09:00:59AM -0400, Nico Kadel-Garcia wrote: > > The mkchroot.sh script in the distribution does an okay job for Linux > > systems but is probably missing a ton of stuff for FreeBSD. There's a > > bunch more details in the CHROOT file. > > It's pretty seriously out of date. I've published a much more recent > one, at https://github.com/nkadel/rssh-chroot-tools I've offered it > before. The thing is, the script was never really meant to solve the problem... I only created it because I needed to set up chroot jails in order to test chroot. I provided it since I'd already done the work, and saw no reason not to; but I only ever meant it to serve as a guide, to illustrate the kinds of things you need to do. It is therefore not maintained, and was never meant to be. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Nico Kadel-G. <nk...@gm...> - 2016-10-05 13:01:11
|
On Tue, Oct 4, 2016 at 11:30 PM, Russ Allbery <ea...@ey...> wrote: > Adam Jensen <ha...@ri...> writes: >> On 10/04/2016 11:09 PM, Russ Allbery wrote: > >>> I'll bet that /bin/sh in your chroot is not the same as /bin/sh outside >>> your chroot, it's not recognizing this shell built-in, and libc is >>> incorrectly interpreting this as a syntax error. > >> This is an interesting statement. There isn't anything inside the >> chrootpath directory. That is, > >> pwd >> /usr/local/chroot > >> ls >> banks/ > >> Should there be a '/usr/local/chroot/bin/sh'? If so, what else needs to >> be in the chrootpath? > > Yeah, sadly you need a bunch of stuff in the chroot because you have to > execute the server end of scp or whatever in the chroot. So it needs all > of its libraries and so forth. > > The mkchroot.sh script in the distribution does an okay job for Linux > systems but is probably missing a ton of stuff for FreeBSD. There's a > bunch more details in the CHROOT file. It's pretty seriously out of date. I've published a much more recent one, at https://github.com/nkadel/rssh-chroot-tools I've offered it before. |
From: Derek M. <co...@pi...> - 2016-10-05 04:53:54
|
On Tue, Oct 04, 2016 at 11:50:39PM -0400, Adam Jensen wrote: > On 10/04/2016 11:30 PM, Russ Allbery wrote: > > The mkchroot.sh script in the distribution does an okay job for Linux > > systems but is probably missing a ton of stuff for FreeBSD. There's a > > bunch more details in the CHROOT file. [...] > Thanks for help. The response was awesome! (I'm thoroughly impressed). Me too... I don't even remember writing most of that. =8^) -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Adam J. <ha...@ri...> - 2016-10-05 03:50:48
|
On 10/04/2016 11:30 PM, Russ Allbery wrote: > Yeah, sadly you need a bunch of stuff in the chroot because you have to > execute the server end of scp or whatever in the chroot. So it needs all > of its libraries and so forth. > > The mkchroot.sh script in the distribution does an okay job for Linux > systems but is probably missing a ton of stuff for FreeBSD. There's a > bunch more details in the CHROOT file. > [snip] > Also, I feel obligated to warn that rssh may be inherently insecure on > FreeBSD given this statement in the wordexp(3) manual page: > [snip] > This is exactly what rssh does and has to do, so if there are indeed such > flaws, they would allow an authenticated attacker to bypass all of the > command restrictions (although, at least in theory, not the chroot). > That is immensely helpful. I naively installed rssh from the FreeBSD package system assuming, well... I'm looking through the rssh source directory now; I'm not sure how I will proceed. Thanks for help. The response was awesome! (I'm thoroughly impressed). |
From: Russ A. <ea...@ey...> - 2016-10-05 03:30:58
|
Adam Jensen <ha...@ri...> writes: > On 10/04/2016 11:09 PM, Russ Allbery wrote: >> I'll bet that /bin/sh in your chroot is not the same as /bin/sh outside >> your chroot, it's not recognizing this shell built-in, and libc is >> incorrectly interpreting this as a syntax error. > This is an interesting statement. There isn't anything inside the > chrootpath directory. That is, > pwd > /usr/local/chroot > ls > banks/ > Should there be a '/usr/local/chroot/bin/sh'? If so, what else needs to > be in the chrootpath? Yeah, sadly you need a bunch of stuff in the chroot because you have to execute the server end of scp or whatever in the chroot. So it needs all of its libraries and so forth. The mkchroot.sh script in the distribution does an okay job for Linux systems but is probably missing a ton of stuff for FreeBSD. There's a bunch more details in the CHROOT file. BTW, the wordexp thing is also discussed there: IMPORTANT NOTE ABOUT wordexp() IMPLEMENTATIONS: rssh requires a working implementation of the wordexp() library function, specified by POSIX.2 (or whatever they're calling it these days). A number of vendors ship a version of wordexp() that execvp()'s the system shell in order to expand the arguments. This means that if you are using such a platform, you'll need to copy their system shell into the chroot jail, along with all the other necessary files. The symptoms of this problem are: 1. When a user logs in, they immediately get "Connection closed." 2. In the system logs, rssh reports "error expanding arguments for user ..." For Solaris 9, the required shell is /bin/ksh. For AIX 5.2, you need /usr/bin/ksh93. FreeBSD also has this problem, but I don't know what the default system shell is on FreeBSD. Other platforms will probably also experience this problem. If you need help determining which shell to include, try running rssh with strace or truss, whichever your system has. See the relevant manpages for details. Also, I feel obligated to warn that rssh may be inherently insecure on FreeBSD given this statement in the wordexp(3) manual page: Do not pass untrusted user data to wordexp(), regardless of whether the WRDE_NOCMD flag is set. The wordexp() function attempts to detect input that would cause commands to be executed before passing it to the shell but it does not use the same parser so it may be fooled. This is exactly what rssh does and has to do, so if there are indeed such flaws, they would allow an authenticated attacker to bypass all of the command restrictions (although, at least in theory, not the chroot). -- Russ Allbery (ea...@ey...) <http://www.eyrie.org/~eagle/> |
From: Russ A. <ea...@ey...> - 2016-10-05 03:27:48
|
Adam Jensen <ha...@ri...> writes: > But when I test it with: > scp blah ba...@mi...:/ > Password for ba...@mi...: > rssh_chroot_helper: wordexp() bad syntax > lost connection This error message means that: wordexp(str, &result, WRDE_NOCMD|WRDE_DOOFFS) is returning WRDE_SYNTAX on your system. According to wordexp(3), this means: WRDE_SYNTAX Shell syntax error, such as unbalanced parentheses or unmatched quotes. wordexp here is being used to parse the command that ssh is sending under the hood when you scp. Apparently there's something about that FreeBSD wordexp doesn't like, or somehow the command line is being parsed incorrectly. My bet on why this is succeeding outside the chroot and not succeeding inside the chroot is this tantalizing statement in the FreeBSD wordexp(3) man page: The wordexp() function is implemented as a wrapper around the undocumented wordexp shell built-in command. I'll bet that /bin/sh in your chroot is not the same as /bin/sh outside your chroot, it's not recognizing this shell built-in, and libc is incorrectly interpreting this as a syntax error. -- Russ Allbery (ea...@ey...) <http://www.eyrie.org/~eagle/> |
From: Adam J. <ha...@ri...> - 2016-10-05 03:17:50
|
On 10/04/2016 11:09 PM, Russ Allbery wrote: > I'll bet that /bin/sh in your chroot is not the same as /bin/sh outside > your chroot, it's not recognizing this shell built-in, and libc is > incorrectly interpreting this as a syntax error. This is an interesting statement. There isn't anything inside the chrootpath directory. That is, pwd /usr/local/chroot ls banks/ Should there be a '/usr/local/chroot/bin/sh'? If so, what else needs to be in the chrootpath? |
From: Adam J. <ha...@ri...> - 2016-10-05 02:58:51
|
My step-by-step process is posted here - https://forums.freebsd.org/threads/57935/ Basically, I do this: sudo pkg install rssh sudo pw groupadd -n rsshuser sudo chown root:rsshuser /usr/local/bin/rssh sudo chown root:rsshuser /usr/local/libexec/rssh_chroot_helper sudo chmod 4550 /usr/local/libexec/rssh_chroot_helper sudo pw useradd -n banks -d /usr/local/chroot/banks -g rsshuser \ -s /usr/local/bin/rssh sudo mkdir -p /usr/local/chroot/banks sudo chown banks:rsshuser /usr/local/chroot/banks sudo passwd banks sudo vi /usr/local/etc/rssh.conf logfacility=LOG_USER umask=022 chrootpath=/usr/local/chroot user=banks:022:10011:/usr/local/chroot/banks But when I test it with: scp blah ba...@mi...:/ Password for ba...@mi...: rssh_chroot_helper: wordexp() bad syntax lost connection The same thing also happen for: scp blah ba...@is...:/banks/ scp blah ba...@is...:~ scp blah ba...@is...:/usr/local/chroot/banks/ Curiously, with this modification to /usr/local/etc/rssh.conf logfacility=LOG_USER umask=022 chrootpath=/usr/local/chroot user=banks:022:10011: #user=banks:022:10011:/usr/local/chroot/banks Then, scp blah ba...@is...:/banks/ Password for ba...@mi...: scp: /banks/: Permission denied scp blah ba...@is...:/usr/local/chroot/banks/ Password for ba...@mi...: blah 100% 17 0.0KB/s 00:00 That copied the file but the chroot facility isn't working. If Filezilla is used to sftp into ba...@mi..., the entire file system can be viewed. Any ideas? |
From: Russ A. <ea...@ey...> - 2016-03-18 04:40:19
|
Marc Berthoud <mg...@co...> writes: > Possible solution to the getting "Connection Closed" problem: Make sure > the /usr/lib/rssh/rssh_chroot_helper has setuid permissions i.e. > -rwsr-xr-x and not -rwxr-xr-x. > Details: I had that problem on a new debian install (Ubuntu Server > 15.10). Took a annoyingly long time to dig up this solution online after > looking through the system logs. I assume that you have your debconf prompt level turned way up so that you didn't see the prompt about this during installation? If you try: dpkg-reconfigure rssh you should get a prompt asking you whether you are planning on using the chroot functionality and want to make that binary setuid root. -- Russ Allbery (ea...@ey...) <http://www.eyrie.org/~eagle/> |
From: Marc B. <mg...@co...> - 2016-03-17 16:58:31
|
Hi All, Possible solution to the getting "Connection Closed" problem: Make sure the /usr/lib/rssh/rssh_chroot_helper has setuid permissions i.e. -rwsr-xr-x and not -rwxr-xr-x. Details: I had that problem on a new debian install (Ubuntu Server 15.10). Took a annoyingly long time to dig up this solution online after looking through the system logs. To avoid frustrating future rssh users, would it be possible to add a comment to the FAQ at http://www.pizzashack.org/rssh/faq.shtml under the "Connection Closed" question? Maybe something along the lines of "Make sure the setuid permission is set for rssh_chroot_helper." Thanks Marc PS: My apologies if this solution has already been posted to this list. If it is then why is the solution not on the FAQ? |
From: Derek M. <co...@pi...> - 2016-03-08 19:24:45
|
On Tue, Mar 08, 2016 at 05:29:45PM +0100, kaazoo wrote: > I would be very nice if you could include it in a future release. No future release is planned. But also the config file format was not really designed to be extensible; if I were to include all the things that people wanted included, it would really require redesigning the config file format and parser. Not happening. :) -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |