rssh-discuss Mailing List for rssh (Page 5)
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: Russ A. <rr...@st...> - 2012-11-28 00:27:15
|
Derek Martin <co...@pi...> writes: > This was CVE-2012-3478, for which I had originally only posted a patch > to the rssh mailing list. It is now fixed in the new release. > The new issue is CVE-2012-2252, which involves improper filtering of the > rsync command line, when rsync support is configured. This may be > somewhat of a non-issue for recent stock rssh installations, as stock > rssh does not support newer rsync binaries which use -e to specify the > rsync protocol; thus if you're using rssh with a recent istallation, > rsync does not work for you anyway, and you therefore most likely have > it disabled by config. Nevertheless, it is a legitimate security > concern if you have rsync enabled in the configuration. This also is > fixed in 2.3.4. > This release also includes some mostly trivial updates for the build > and a bit of minor code clean-up. > For people using rssh packages from Debian, Red Hat, or one of their > derivatives, a third vulnerability was recently discovered, assigned > CVE-2012-2251. This issue exists only in a third-party patch to make > rssh work with newer rsync binaries. Stock rssh *is not vulnerable* to > this issue. However if you are relying on your vendor to package rssh, > this likely affects you. Attached is the updated version of the patch used in Debian to permit the rsync reuse of the -e option to convey protocol information, for those who may be applying this patch to their own builds. This has not yet been updated to be based on the 2.3.4 release and is still based on 2.3.3. I'll be updating the Debian packaging to the new 2.3.4 release in the coming months. -- Russ Allbery (rr...@st...) <http://www.eyrie.org/~eagle/> |
From: Sandeep D. स. द. <san...@gm...> - 2012-11-01 05:39:58
|
Hi Rehan, I worked very little on rssh and I had similar problems of not logging into system; mine was RHEL5.5. The workaround I used is that the folder which was jail rooted (in your case /volume1/backup) should have some of the system libraries to be copied from the same system For example: In my case - jail root folder is - "*/opt/xfer/public/*" it has following structure - *#root# ls - l **/opt/xfer/public/* drwxrwxr-x 2 root root 4096 Sep 7 16:03 bin drwxrwxr-x 2 root root 4096 Sep 7 16:03 dev drwxrwxr-x 3 root root 4096 Sep 18 17:12 etc drwxrwxr-x 3 root root 4096 Sep 7 16:03 home drwxrwxr-x 2 root root 4096 Sep 7 16:03 lib drwxrwxr-x 5 root root 4096 Sep 7 16:03 usr *#root# ls -l **/opt/xfer/public/** bin: total 0 dev: total 0 crw-rw-rw- 1 root root 1, 3 Sep 7 16:03 null etc: total 48 -rw-r--r-- 1 root root 914 Sep 7 16:03 group -rw-r--r-- 1 root root 68 Sep 7 16:03 hosts -rw-r--r-- 1 root root 25437 Sep 7 16:03 ld.so.cache -rw-r--r-- 1 root root 28 Sep 7 16:03 ld.so.conf drwxr-xr-x 2 root root 4096 Aug 14 22:09 ld.so.conf.d -rw-r--r-- 1 root root 2619 Sep 18 17:12 passwd home: total 4 drwxrwxr-x 2 root other 4096 Sep 7 16:03 ftpusers lib: total 4060 -rwxr-xr-x 1 root root 129504 Sep 7 16:03 ld-linux.so.2 -rwxr-xr-x 1 root root 1710828 Sep 7 16:03 libc.so.6 -rwxr-xr-x 1 root root 6300 Sep 7 16:03 libcom_err.so.2 -rwxr-xr-x 1 root root 47712 Sep 7 16:03 libcrypt.so.1 -rwxr-xr-x 1 root root 1316736 Sep 7 16:03 libcrypto.so.6 -rwxr-xr-x 1 root root 18812 Sep 7 16:03 libdl.so.2 -rwxr-xr-x 1 root root 6596 Sep 7 16:03 libkeyutils.so.1 -rwxr-xr-x 1 root root 107924 Sep 7 16:03 libnsl.so.1 -rwxr-xr-x 1 root root 36416 Sep 7 16:03 libnss_compat-2.5.so -rwxr-xr-x 1 root root 36416 Sep 7 16:03 libnss_compat.so.2 -rwxr-xr-x 1 root root 50848 Sep 7 16:03 libnss_files-2.5.so -rwxr-xr-x 1 root root 50848 Sep 7 16:03 libnss_files.so.2 -rwxr-xr-x 1 root root 131540 Sep 7 16:03 libpthread.so.0 -rwxr-xr-x 1 root root 83088 Sep 7 16:03 libresolv.so.2 -rwxr-xr-x 1 root root 91892 Sep 7 16:03 libselinux.so.1 -rwxr-xr-x 1 root root 243928 Sep 7 16:03 libsepol.so.1 -rwxr-xr-x 1 root root 13492 Sep 7 16:03 libutil.so.1 usr: total 12 drwxrwxr-x 2 root root 4096 Sep 7 16:03 bin drwxrwxr-x 2 root root 4096 Sep 7 16:03 lib drwxrwxr-x 3 root root 4096 Sep 7 16:03 libexec *#root# ls -l /opt/xfer/public/usr/** bin: total 108 -rwxr-xr-x 1 root root 18988 Sep 7 16:03 rssh -rwxr-xr-x 1 root root 84620 Sep 7 16:03 sftp lib: total 2624 -rwxr-xr-x 1 root root 184812 Sep 7 16:03 libgssapi_krb5.so.2 -rwxr-xr-x 1 root root 155640 Sep 7 16:03 libk5crypto.so.3 -rwxr-xr-x 1 root root 611948 Sep 7 16:03 libkrb5.so.3 -rwxr-xr-x 1 root root 32312 Sep 7 16:03 libkrb5support.so.0 -rwxr-xr-x 1 root root 230640 Sep 7 16:03 libnspr4.so -rwxr-xr-x 1 root root 1203700 Sep 7 16:03 libnss3.so -rwxr-xr-x 1 root root 119748 Sep 7 16:03 libnssutil3.so -rwxr-xr-x 1 root root 14008 Sep 7 16:03 libplc4.so -rwxr-xr-x 1 root root 9976 Sep 7 16:03 libplds4.so -rwxr-xr-x 1 root root 73836 Sep 7 16:03 libz.so.1 libexec: total 52 drwxrwxr-x 2 root root 4096 Sep 7 16:03 openssh -rwsr-xr-x 1 root root 47783 Sep 7 16:03 rssh_chroot_helper *#root# ls -l /opt/xfer/public/usr/libexec/openssh/** -rwxr-xr-x 1 root root 50432 Sep 7 16:03 libexec/openssh/sftp-server Additional changes are - 1. Add ftp user entry to the jail root folder's passwd file i.e. in my case *ftpuser* is added to file */opt/xfer/public/etc/passwd* *$ getent passwd ftpuser* ftpuser:x:2010:502:ftpuser user:/opt/xfer/public:/usr/bin/rssh *$ id ftpuser* uid=2010(ftpuser) gid=502(other) groups=502(other) 2. Also modify the home directory of ftpuser to "*/volume1/backup*" 3. Add "*chrootpath = /volume1/backup*" to rssh.conf file, if not already added. I hope this may resolve your problem. -- ----------- Thanks and Regards, Sandeep Chandrakant Dudam ( संदीप चंद्रकांत दुडम ) Google Talk ID: sandeep.dudam Linked-In Profile: http://in.linkedin.com/pub/sandeep-dudam/20/652/812 Facebook: http://www.facebook.com/people/Sandeep-Dudam/100001905343252 On Fri, Oct 26, 2012 at 4:54 AM, Rehan S. Alvi <reh...@gm...> wrote: > Hello everyone, > > I'm new to this list so please forgive me if I make any errors. I am > trying to setup rssh to work on my Synology DS1512+ NAS running BusyBox > v1.16.1. My objective is to allow a user that I created (ftpuser) to be > able to login and only have access to sftp and scp. > > I have my Synology bootstrapped and am using ipkg to install rssh (ipkg > install rssh). This also installs openSSH, openssl, openssh-sftp-server and > zlib. I then edit my user (ftpuser) setting in /etc/passwd and change the > ftpuser's line to the following: ftpuser:x:1042:100:FTP > User:/var/services/homes/ftpuser:/opt/bin/rssh > > I then edited my /etc/ssh/sshd_config and comment out the existing line > of: Subsystem sftp internal-sftp -f DAEMON -u 000 > and add: Subsystem sftp /opt/libexec/sftp-server > > I also edit /opt/etc/rssh.conf and uncomment allowscp and allowsftp. > I then edit /etc/shells and add /opt/bin/rssh to the file and save it. > > I then restart my NAS box and try to login via FileZilla. I want ftpuser > to only have access to /volume1/backup. I login with filezilla but instead > of going to /volume1/backup it takes me to '/' instead. So I edit > /opt/etc/rssh.conf and add the following > line: user=ftpuser:011:00011:/volume1/backup > > Now I am unable to login at all. I have two questions: > > 1) How can I make it so that ftpuser can only access /volume1/backup? > 2) Is there a way that I can use the existing SSH that is already a part > of the NAS' built-in software instead of using OpenSSH? The reason I ask is > because when I seem to use the OpenSSH package that is installed with rssh, > I no longer have the ability to toggle the SSH via the web GUI, and I am > wondering if there isn't a way to have rssh work with the existing package. > > Thank you for taking the time to read this. I am grateful for any help > that you may be able to provide. > > > -- > Rehan S. Alvi > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > rssh-discuss mailing list > rss...@li... > https://lists.sourceforge.net/lists/listinfo/rssh-discuss > > |
From: Rehan S. A. <reh...@gm...> - 2012-10-25 23:24:35
|
Hello everyone, I'm new to this list so please forgive me if I make any errors. I am trying to setup rssh to work on my Synology DS1512+ NAS running BusyBox v1.16.1. My objective is to allow a user that I created (ftpuser) to be able to login and only have access to sftp and scp. I have my Synology bootstrapped and am using ipkg to install rssh (ipkg install rssh). This also installs openSSH, openssl, openssh-sftp-server and zlib. I then edit my user (ftpuser) setting in /etc/passwd and change the ftpuser's line to the following: ftpuser:x:1042:100:FTP User:/var/services/homes/ftpuser:/opt/bin/rssh I then edited my /etc/ssh/sshd_config and comment out the existing line of: Subsystem sftp internal-sftp -f DAEMON -u 000 and add: Subsystem sftp /opt/libexec/sftp-server I also edit /opt/etc/rssh.conf and uncomment allowscp and allowsftp. I then edit /etc/shells and add /opt/bin/rssh to the file and save it. I then restart my NAS box and try to login via FileZilla. I want ftpuser to only have access to /volume1/backup. I login with filezilla but instead of going to /volume1/backup it takes me to '/' instead. So I edit /opt/etc/rssh.conf and add the following line: user=ftpuser:011:00011:/volume1/backup Now I am unable to login at all. I have two questions: 1) How can I make it so that ftpuser can only access /volume1/backup? 2) Is there a way that I can use the existing SSH that is already a part of the NAS' built-in software instead of using OpenSSH? The reason I ask is because when I seem to use the OpenSSH package that is installed with rssh, I no longer have the ability to toggle the SSH via the web GUI, and I am wondering if there isn't a way to have rssh work with the existing package. Thank you for taking the time to read this. I am grateful for any help that you may be able to provide. -- Rehan S. Alvi |
From: Derek M. <co...@pi...> - 2012-07-10 22:57:46
|
On Fri, Jun 29, 2012 at 06:43:25PM -0700, Zippy Zeppoli wrote: > I am trying to use rssh to restrict a single user to their home > directory, and sftp. I don't quite understand, does rssh have > to be used in conjunction with chroot for the restriction to work? Yes. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Zippy Z. <zip...@gm...> - 2012-06-30 01:43:32
|
Hi All, I am trying to use rssh to restrict a single user to their home directory, and sftp. I don't quite understand, does rssh have to be used in conjunction with chroot for the restriction to work? I just get a connection closed now when I use rssh with the following settings: # 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" ########################################## # EXAMPLES of configuring per-user options #user=rudy:077:00010: # the path can simply be left out to not chroot #user=rudy:077:00010 # the ending colon is optional #user=rudy:011:00100: # cvs, with no chroot #user=rudy:011:01000: # rdist, with no chroot #user=rudy:011:10000: # rsync, with no chroot #user="rudy:011:00001:/usr/local/chroot" # whole user string can be quoted #user=rudy:01"1:00001:/usr/local/chroot" # or somewhere in the middle, freak! user=doofus:'011:00010:/home/doofus' # single quotes too user=doofus:011:00010: # single quotes too # if your chroot_path contains spaces, it must be quoted... # In the following examples, the chroot_path is "/usr/local/my chroot" #user=rudy:011:00001:"/usr/local/my chroot" # scp with chroot #user=rudy:011:00010:"/usr/local/my chroot" # sftp with chroot #user=rudy:011:00011:"/usr/local/my chroot" # both with chroot # Spaces before or after the '=' are fine, but spaces in chrootpath need # quotes. #user = "rudy:011:00001:/usr/local/my chroot" #user = "rudy:011:00001:/usr/local/my chroot" # neither do comments at line end |
From: Derek M. <co...@pi...> - 2012-06-05 23:29:28
|
On Tue, May 15, 2012 at 10:46:04AM -0500, Derek Martin wrote: > On Tue, May 08, 2012 at 12:24:52PM -0500, Derek Martin wrote: > > Henrik Erkkonen has discovered that, through clever manipulation of > > environment variables on the ssh command line, it is possible to > > circumvent rssh. As far as I can tell, there is no way to effect a > > root compromise, except of course if the root account is the one > > you're attempting to protect with rssh... > > > > This project is old, and I have no interest in continuing to maintain > > it. > > Actually, I have a patch for this. I'll be publishing it later this > week, when I can find some time to do it. I haven't had the time to work up a proper release for this issue, but I do have a patch, which is attatched. Hopefully I'll get some time to do a release this weekend. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Derek M. <co...@pi...> - 2012-06-05 23:01:03
|
On Tue, May 15, 2012 at 10:46:04AM -0500, Derek Martin wrote: > On Tue, May 08, 2012 at 12:24:52PM -0500, Derek Martin wrote: > > Henrik Erkkonen has discovered that, through clever manipulation of > > environment variables on the ssh command line, it is possible to > > circumvent rssh. As far as I can tell, there is no way to effect a > > root compromise, except of course if the root account is the one > > you're attempting to protect with rssh... > > > > Actually, I have a patch for this. I'll be publishing it later this > week, when I can find some time to do it. I haven't had the time to work up a proper release for this issue, but I do have a patch, which is attatched. Hopefully I'll get some time to do a release this weekend. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Russ A. <rr...@st...> - 2012-05-20 00:25:46
|
Michael F Lense <mic...@co...> writes: > I am running Red Hat Version 5.8, and have Openssh installed > at Version: > # rpm -qa |grep -i openssh > openssh-askpass-4.3p2-82.el5 > openssh-server-4.3p2-82.el5 > openssh-4.3p2-82.el5 > openssh-clients-4.3p2-82.el5 > # > And installed rssh at: > # rpm -qa |grep -i rssh > rssh-2.3.3-1.el5.rf > # > I am trying to have all files uploaded to server with permissions of: "664" umask sets maximum permissions, not minimum permissions. That's why it's a "mask"; it specifies what permissions to remove from the permissions given by the client. You won't be able to increase the permissions via umask. You have to get the user to upload the file with broader permissions, use a cron job to change permissions, use file ACLs instead, or something similar. -- Russ Allbery (rr...@st...) <http://www.eyrie.org/~eagle/> |
From: Michael F L. <mic...@co...> - 2012-05-20 00:20:42
|
I am running Red Hat Version 5.8, and have Openssh installed at Version: # rpm -qa |grep -i openssh openssh-askpass-4.3p2-82.el5 openssh-server-4.3p2-82.el5 openssh-4.3p2-82.el5 openssh-clients-4.3p2-82.el5 # And installed rssh at: # rpm -qa |grep -i rssh rssh-2.3.3-1.el5.rf # I am trying to have all files uploaded to server with permissions of: "664" I've coded the rssh.conf file with: umask = 002 allowsftp chrootpath = "/home/sftponly" user=logftp0:002:00010:"/home/sftponly" user=logftp1:002:00010:"/home/sftponly" user=logftp2:002:00010:"/home/sftponly" user=logftp3:002:00010:"/home/sftponly" user=logftp4:002:00010:"/home/sftponly" user=logftp5:002:00010:"/home/sftponly" user=logftp6:002:00010:"/home/sftponly" user=logftp7:002:00010:"/home/sftponly" user=logftp8:002:00010:"/home/sftponly" user=logftp9:002:00010:"/home/sftponly" and the /etc/passwd file is set up as: logftp0:x:700:700:SFTP Admin Account - logftp0:/home/sftponly/logftp0:/usr/bin/rssh logftp1:x:701:701:SFTP Admin Account - logftp1:/home/sftponly/logftp1:/usr/bin/rssh logftp2:x:702:702:SFTP Admin Account - logftp2:/home/sftponly/logftp2:/usr/bin/rssh logftp3:x:703:703:SFTP Admin Account - logftp3:/home/sftponly/logftp3:/usr/bin/rssh logftp4:x:704:704:SFTP Admin Account - logftp4:/home/sftponly/logftp4:/usr/bin/rssh logftp5:x:705:705:SFTP Admin Account - logftp5:/home/sftponly/logftp5:/usr/bin/rssh logftp6:x:706:706:SFTP Admin Account - logftp6:/home/sftponly/logftp6:/usr/bin/rssh logftp7:x:707:707:SFTP Admin Account - logftp7:/home/sftponly/logftp7:/usr/bin/rssh logftp8:x:708:708:SFTP Admin Account - logftp8:/home/sftponly/logftp8:/usr/bin/rssh logftp9:x:709:709:SFTP Admin Account - logftp9:/home/sftponly/logftp9:/usr/bin/rssh But when a user sftp's a file into this server, the permissions on the file are not set to "664" as expected: -> sftp logftp0@apsclog1 Connecting to apsclog1... sftp> cd ./inbound sftp> pwd Remote working directory: /logftp0/inbound sftp> put SYSINF Uploading SYSINF to /logftp0/inbound/SYSINF SYSINF 100% 32 0.0KB/s 00:00 sftp> ls -al drwxrwxr-- 2 logftp0 logftp0 4096 May 19 23:41 . drwxr-x--- 9 logftp0 logftp0 4096 May 17 22:44 .. -rw-r--r-- 1 logftp0 logftp0 32 May 19 23:41 SYSINF sftp> rm SYSINF Removing /logftp0/inbound/SYSINF sftp> ls -al drwxrwxr-- 2 logftp0 logftp0 4096 May 19 23:41 . drwxr-x--- 9 logftp0 logftp0 4096 May 17 22:44 .. sftp> cd You must specify a path after a cd command. sftp> exit [19:41:58] /home/smonitor -> ________________________________ NOTICE: The information contained in this electronic mail transmission is intended by Convergys Corporation for the use of the named individual or entity to which it is directed and may contain information that is privileged or otherwise confidential. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email or by telephone (collect), so that the sender's address records can be corrected. |
From: Russ A. <rr...@st...> - 2012-05-09 17:44:07
|
Derek Martin <co...@pi...> writes: > On Tue, May 08, 2012 at 08:50:11PM -0400, Nico Kadel-Garcia wrote: >> Is it still a problem with OpenSSH version 6, which was >> recently published? > Yes. The flaw is in how rssh parses command lines, irrespective of what > SSH implementation is used. I've been a bit vague about the details for > the moment; I'm hoping that the announcement will generate some interest > in taking over the maintenance of the project. I'd like to have some > sense of what will happen next before the full details are disclosed. > If someone wants to step forward, it would be good to give them a chance > to fix it before that happens. I can't realistically offer to take over upstream development, as I have too much else on my plate, but I plan on continuing to maintain the Debian package for rssh unless the security situation is untenable, and I'm happy to help at least with merging the current Debian patches and trying to review other changes. Particularly if the source ended up on Github or some other public Git hosting facility that's a little less annoying than Sourceforge, but I can deal with Sourceforge if that's what people really want to use. So if someone else is willing to step up, I can at least offer to have you not be alone. :) -- Russ Allbery (rr...@st...) <http://www.eyrie.org/~eagle/> |
From: Derek M. <co...@pi...> - 2012-05-09 17:37:08
|
On Tue, May 08, 2012 at 08:50:11PM -0400, Nico Kadel-Garcia wrote: > Is it still a problem with OpenSSH version 6, which was > recently published? Yes. The flaw is in how rssh parses command lines, irrespective of what SSH implementation is used. I've been a bit vague about the details for the moment; I'm hoping that the announcement will generate some interest in taking over the maintenance of the project. I'd like to have some sense of what will happen next before the full details are disclosed. If someone wants to step forward, it would be good to give them a chance to fix it before that happens. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Nico Kadel-G. <nk...@gm...> - 2012-05-09 00:50:18
|
On Tue, May 8, 2012 at 2:14 PM, Derek Martin <co...@pi...> wrote: > [Resent to correct recpients; moderators, please approve THIS > message.] > > rssh is a shell for restricting SSH access to a machine to only scp, > sftp, or a small set of similar applications. > > http://www.pizzashack.org/rssh/ > > Henrik Erkkonen has discovered that, through clever manipulation of > environment variables on the ssh command line, it is possible to > circumvent rssh. As far as I can tell, there is no way to effect a > root compromise, except of course if the root account is the one > you're attempting to protect with rssh... > That..... is a big, big problem. I've occasionally used it for root access for backup operations and remote init script management or various "trap" events from bug reporting. > This project is old, and I have no interest in continuing to maintain > it. I looked for easy solutions to the problem, but in discussing > them with Henrik, none which we found satisfactorily address the > problem. Fixing this properly will require more work than I want to > put into it. > > Note in particular that ensuring that the AcceptEnv sshd configuration > option need not be turned on for this exploit to work. > Is it still a problem with OpenSSH version 6, which was recently published? |
From: Derek M. <co...@pi...> - 2012-05-08 18:29:27
|
[Resent to correct recpients; moderators, please approve THIS message.] rssh is a shell for restricting SSH access to a machine to only scp, sftp, or a small set of similar applications. http://www.pizzashack.org/rssh/ Henrik Erkkonen has discovered that, through clever manipulation of environment variables on the ssh command line, it is possible to circumvent rssh. As far as I can tell, there is no way to effect a root compromise, except of course if the root account is the one you're attempting to protect with rssh... This project is old, and I have no interest in continuing to maintain it. I looked for easy solutions to the problem, but in discussing them with Henrik, none which we found satisfactorily address the problem. Fixing this properly will require more work than I want to put into it. Note in particular that ensuring that the AcceptEnv sshd configuration option need not be turned on for this exploit to work. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Derek M. <co...@pi...> - 2012-03-18 00:29:23
|
On Thu, Mar 08, 2012 at 08:55:56PM -0500, Ben Walton wrote: > Excerpts from Noel Butler's message of Thu Mar 08 19:46:22 -0500 2012: > > > Just remember, if an upstream does not use an offered patch, there > > is likely a very, VERY, good reason. > > There are lots of reasons that upstreams won't take good and valid > patches. Arrogance and ignorance are two that I've seen several > times. (Neither in this case.) Not all dropped patches are bad. :) There are three reasons I haven't incorporated any patches, FWIW. The first is because some of them are for systems I don't have, so I can't test them. The second is that it would necessitate a new release, and I really have no interest in doing a new release (as you appear to be aware) unless there's a really, really good reason. The last is explained in the docs: Since the details of setting up a jail are really very platform-dependent, that script is more documentation than tool. It's meant to illustrate the sorts of things you'll need to do get it working, not do the job for you. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Loveparteek T. <lt...@va...> - 2012-03-09 10:24:31
|
Remove Regards, Loveparteek Tiwana | System Administrator | Varicent Software Incorporated Phone: 416.987.7082 lt...@va...<mailto:lt...@va...> Sent from my iPhone |
From: Ben W. <bw...@ar...> - 2012-03-09 01:56:02
|
Excerpts from Noel Butler's message of Thu Mar 08 19:46:22 -0500 2012: > Just remember, if an upstream does not use an offered patch, there > is likely a very, VERY, good reason. There are lots of reasons that upstreams won't take good and valid patches. Arrogance and ignorance are two that I've seen several times. (Neither in this case.) Not all dropped patches are bad. :) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 |
From: Noel B. <noe...@au...> - 2012-03-09 01:03:27
|
On Thu, 2012-03-08 at 14:04 -0500, Ben Walton wrote: > > Good to know. Thanks for curating it nicely! I understand the > time/effort it takes[1] and I hope you didn't take my comments as > negative criticism...I hadn't looked at Debian's package at all. I > was only trying to express that I felt the patches were useful and if > not slipped in upstream, at least the 'vendors' could include them. > Beware of vendor patches that upstreams do not incorporate! We all remember the screwup debian caused a great deal of the internet with its SSL mess a few years ago, that not only affected debian servers, but all servers using certificates generated on a debian machine, and not to be biased, RedHat has made some messes before as well, tis why we no longer use either of their distro's nor their slightly flavoured different cousins. I wont say which Linux we only use to avoid OS wars :) Just remember, if an upstream does not use an offered patch, there is likely a very, VERY, good reason. |
From: Russ A. <rr...@st...> - 2012-03-08 21:18:52
|
Ben Walton <bw...@ar...> writes: > Excerpts from Russ Allbery's message of Thu Mar 08 13:49:09 -0500 2012: >> I incorporate things like that as I see them (and have time) into the >> Debian packages if they're relevant to Debian. Most of your patch set, >> as I recall, had already been fixed in Debian by other people for some >> time. I don't recall if there were further tweaks that I pulled in. > Good to know. Thanks for curating it nicely! I understand the > time/effort it takes[1] and I hope you didn't take my comments as > negative criticism...I hadn't looked at Debian's package at all. I was > only trying to express that I felt the patches were useful and if not > slipped in upstream, at least the 'vendors' could include them. Oh, sure, no, I understand. I was just filling in details, not taking anything as critical. :) -- Russ Allbery (rr...@st...) <http://www.eyrie.org/~eagle/> |
From: Ben W. <bw...@ar...> - 2012-03-08 19:04:32
|
Excerpts from Russ Allbery's message of Thu Mar 08 13:49:09 -0500 2012: Hi Russ, > I incorporate things like that as I see them (and have time) into > the Debian packages if they're relevant to Debian. Most of your > patch set, as I recall, had already been fixed in Debian by other > people for some time. I don't recall if there were further tweaks > that I pulled in. Good to know. Thanks for curating it nicely! I understand the time/effort it takes[1] and I hope you didn't take my comments as negative criticism...I hadn't looked at Debian's package at all. I was only trying to express that I felt the patches were useful and if not slipped in upstream, at least the 'vendors' could include them. > Its mkchroot also doesn't try to set up rsync. Ideally, there > should probably be some arguments to mkchroot to say what programs > you actually want to run. Or maybe figure it out dynamically from > the configuration. This would be a good idea. Thanks -Ben [1] http://opencsw.org/m/bwalton -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 |
From: Russ A. <rr...@st...> - 2012-03-08 18:49:20
|
Ben Walton <bw...@ar...> writes: > I submitted a patch series[1] a while back that addressed some other > issues with mkchroot.sh too. I didn't get any feedback at the time. I > know that future releases aren't likely unless a security is found, but > it would be cool of the rpm/deb maintainers to incorporate these types > of fix ups for the downstream folks! :) I incorporate things like that as I see them (and have time) into the Debian packages if they're relevant to Debian. Most of your patch set, as I recall, had already been fixed in Debian by other people for some time. I don't recall if there were further tweaks that I pulled in. You can see the current Debian patch set at: http://patch-tracker.debian.org/package/rssh/2.3.3-3 fixes/mkchroot.diff is the relevant patch set. Note that it doesn't attempt to deal with /lib64 for nsswitch modules since neither Debian nor Ubuntu use that layout, but it does deal with Debian and Ubuntu multiarch. Its mkchroot also doesn't try to set up rsync. Ideally, there should probably be some arguments to mkchroot to say what programs you actually want to run. Or maybe figure it out dynamically from the configuration. -- Russ Allbery (rr...@st...) <http://www.eyrie.org/~eagle/> |
From: Ben W. <bw...@ar...> - 2012-03-08 14:25:52
|
Excerpts from Charles Galpin's message of Thu Mar 08 08:53:43 -0500 2012: Hi Charles, > I thought I'd share a few problems I ran into while setting up rssh > 2.3.3 on centos 5.6 (64 bit) for sftp and rsync with a chrooted env > in case it helps someone else (as your prvious posts helped > me). They really all have to do with using a jailed/chrooted env. Nice. Thanks for sharing this. > 1. mkchroot.sh didn't come bundled with the rpm. It would be nice if > it did. +1 for that. > 1. The mkchroot.sh does not setup rsync. Since everything else seems > to cater to rsync this looks like a bit of an ommission, but it's > easy to add to the script if needed by just looking what is done for > $sftp_server_path and adding the same for $rsync_path I hadn't noticed that but my needs didn't include rsync. Nice catch. > 2. The mkchroot.sh doesn't appear to be 64 bit aware. This mainly > got me on the name service resolution libraries so I added the > following to the script > cp /lib64/libnss_{files,ldap}* "$jail_dir/lib64" This is good. Ultimately, the script should detect the arch and use the right paths. I submitted a patch series[1] a while back that addressed some other issues with mkchroot.sh too. I didn't get any feedback at the time. I know that future releases aren't likely unless a security is found, but it would be cool of the rpm/deb maintainers to incorporate these types of fix ups for the downstream folks! :) Thanks -Ben [1] http://sourceforge.net/mailarchive/forum.php?thread_name=1310563577-13406-1-git-send-email-bwalton%40artsci.utoronto.ca&forum_name=rssh-discuss -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 |
From: Charles G. <cg...@lh...> - 2012-03-08 13:54:00
|
Hi there and thanks for a tremendous tool. I thought I'd share a few problems I ran into while setting up rssh 2.3.3 on centos 5.6 (64 bit) for sftp and rsync with a chrooted env in case it helps someone else (as your prvious posts helped me). They really all have to do with using a jailed/chrooted env. 1. mkchroot.sh didn't come bundled with the rpm. It would be nice if it did. 1. The mkchroot.sh does not setup rsync. Since everything else seems to cater to rsync this looks like a bit of an ommission, but it's easy to add to the script if needed by just looking what is done for $sftp_server_path and adding the same for $rsync_path 2. The mkchroot.sh doesn't appear to be 64 bit aware. This mainly got me on the name service resolution libraries so I added the following to the script cp /lib64/libnss_{files,ldap}* "$jail_dir/lib64" The main reason this was a hassle was that I got no indication of these libraries were missing in the logs and sftp just failed silently. At least with rsync I could see libs were missing. Anyway, I hope this helps someone with similar issues, and thanks again for rssh. charles |
From: Nico Kadel-G. <nk...@gm...> - 2012-01-17 03:44:35
|
On Sun, Jan 15, 2012 at 3:12 PM, Derek Martin <co...@pi...> wrote: > Hi Noel, > > On Sun, Jan 15, 2012 at 12:39:08PM +1000, Noel Butler wrote: >> Last night I updated two machines that use rssh. >> >> make install, on both boxes, over-wrote the existing customised >> rssh.conf files > > Yep, confirmed, it does that. But it always did, unless autoconf > dealt with it. I believe if you install it using your system's > package manager, it will not do that. I recommend doing that... most > major distributions now have rssh in their package repositories. RPM preserves the old rssh.conf file. > That said, it's annoying behavior. However it's not a security bug, > and I'm not really fixing anything else at this point. I'll flag this > though so that if I ever do need to release a new version, I'll fix > this too. > > The good news is 2.3.3 is a year and a half old, and it seems pretty > unlikely at this point that I'll release another version, so you'll > probably never have to worry about this ever again. If you need to > update other systems, just save your config file aside first. > > > Thanks > > -- > Derek D. Martin > http://www.pizzashack.org/ > GPG Key ID: 0x81CFE75D > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Mar 27 - Feb 2 > Save $400 by Jan. 27 > Register now! > http://p.sf.net/sfu/rsa-sfdev2dev2 > _______________________________________________ > rssh-discuss mailing list > rss...@li... > https://lists.sourceforge.net/lists/listinfo/rssh-discuss > |
From: Derek M. <co...@pi...> - 2012-01-15 20:12:23
|
Hi Noel, On Sun, Jan 15, 2012 at 12:39:08PM +1000, Noel Butler wrote: > Last night I updated two machines that use rssh. > > make install, on both boxes, over-wrote the existing customised > rssh.conf files Yep, confirmed, it does that. But it always did, unless autoconf dealt with it. I believe if you install it using your system's package manager, it will not do that. I recommend doing that... most major distributions now have rssh in their package repositories. That said, it's annoying behavior. However it's not a security bug, and I'm not really fixing anything else at this point. I'll flag this though so that if I ever do need to release a new version, I'll fix this too. The good news is 2.3.3 is a year and a half old, and it seems pretty unlikely at this point that I'll release another version, so you'll probably never have to worry about this ever again. If you need to update other systems, just save your config file aside first. Thanks -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Noel B. <noe...@au...> - 2012-01-15 02:39:18
|
Last night I updated two machines that use rssh. make install, on both boxes, over-wrote the existing customised rssh.conf files I can not recall it ever doing this before, but don't have a copy of an older version lying around to test. Appears install does not check for existing config file and just puts it in place regardless. Thanks |