Re: Rsync-daemon security advisories for writable daemons
On Mon, Dec 10, 2007 at 04:30:55PM -0500, Matt McCutchen wrote: The current development rsync ignores all errors, but errors other than ENOSYS might be significant. Yeah, good idea. I've changed the dev version to only ignore ENOSYS. ..wayne.. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Bug#455194: Rsync-daemon security advisories for writable daemons
On Mon 10 Dec 2007, Matt McCutchen wrote: On Mon, 2007-12-10 at 21:20 +0100, Paul Slootman wrote: It seems that people running the Debian 2.6.9-5.1 version which has this patch applied. are running into problems where rsync wants to set permissions on symlinks. In the report rsync seems to want to set mtimes, not permissions. Oops, I was too much in a hurry... The bug report and extra info is at http://bugs.debian.org/455194 . I can't dig into this until tomorrow, so if someone wants to have a look in the meantime... My guess is that the problem has nothing to do with the munge-symlinks patch itself and it is just that the 2.6.9-5.1 package was built on a newer system. Specifically: A lutimes function to set symlink mtimes was recently added to glibc, and the underlying utimensat system call was added to Linux 2.6.22. Rsync's configure script checks whether the build Ah, that must be it. I've now built a version with the git patch to ignore the return code. Thanks for figuring this out! Paul Slootman -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Rsync-daemon security advisories for writable daemons
On Tue 27 Nov 2007, Wayne Davison wrote: Starting with the 3.0.0-pre6 release, there will be a new daemon option available: munge symlinks. This will allow an rsync daemon to accept symlinks and return them intact (with even a leading slash still there, which is new for a non-chroot daemon), but will not allow the symlinks to be used while they are in the daemon's hierarchy. For those running 2.6.9, there is a patch to enable this option: http://rsync.samba.org/ftp/rsync/munge-symlinks-2.6.9.diff It seems that people running the Debian 2.6.9-5.1 version which has this patch applied. are running into problems where rsync wants to set permissions on symlinks. The bug report and extra info is at http://bugs.debian.org/455194 . I can't dig into this until tomorrow, so if someone wants to have a look in the meantime... Paul Slootman -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Rsync-daemon security advisories for writable daemons
On Mon, 2007-12-10 at 21:20 +0100, Paul Slootman wrote: It seems that people running the Debian 2.6.9-5.1 version which has this patch applied. are running into problems where rsync wants to set permissions on symlinks. In the report rsync seems to want to set mtimes, not permissions. The bug report and extra info is at http://bugs.debian.org/455194 . I can't dig into this until tomorrow, so if someone wants to have a look in the meantime... My guess is that the problem has nothing to do with the munge-symlinks patch itself and it is just that the 2.6.9-5.1 package was built on a newer system. Specifically: A lutimes function to set symlink mtimes was recently added to glibc, and the underlying utimensat system call was added to Linux 2.6.22. Rsync's configure script checks whether the build machine's glibc advertises a non-stub lutimes function; if so, the built executable tries to set symlink mtimes. If a copy of rsync built on a machine with lutimes runs on a machine without it (e.g., kernel before 2.6.22), rsync will try and fail to set symlink mtimes. Thus, if the Debian build machine were upgraded to support lutimes between the building of the 2.6.9-5 and 2.6.9-5.1 packages, that would explain what users are seeing. Rsync 3.0.0 has been changed to ignore errors in lutimes calls to avoid harassing users in situations like this: http://git.samba.org/?p=rsync.git;a=commit;h=149a78e33f1632c8a3bdd00e10aecf69c8d5608d Debian could adopt this change or disable lutimes again for everybody by passing ac_cv_func_lutimes=no to the configure script. Matt -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Rsync-daemon security advisories for writable daemons
Le lundi 10 décembre 2007, Matt McCutchen a écrit : On Mon, 2007-12-10 at 21:20 +0100, Paul Slootman wrote: It seems that people running the Debian 2.6.9-5.1 version which has this patch applied. are running into problems where rsync wants to set permissions on symlinks. In the report rsync seems to want to set mtimes, not permissions. The bug report and extra info is at http://bugs.debian.org/455194 . I can't dig into this until tomorrow, so if someone wants to have a look in the meantime... My guess is that the problem has nothing to do with the munge-symlinks patch itself and it is just that the 2.6.9-5.1 package was built on a newer system. Specifically: A lutimes function to set symlink mtimes was recently added to glibc, and the underlying utimensat system call was added to Linux 2.6.22. Rsync's configure script checks whether the build machine's glibc advertises a non-stub lutimes function; if so, the built executable tries to set symlink mtimes. If a copy of rsync built on a machine with lutimes runs on a machine without it (e.g., kernel before 2.6.22), rsync will try and fail to set symlink mtimes. Thus, if the Debian build machine were upgraded to support lutimes between the building of the 2.6.9-5 and 2.6.9-5.1 packages, that would explain what users are seeing. I had the same issue on some mandriva system, to avoid the issue I did: perl -pi -e 's:^#define HAVE_LUTIMES 1$:/* #undef HAVE_LUTIMES */:' config.h This issue exists also in rsync 2.6.9. I don't how to really fix into rsync, except checking uname to get the running kernel's version. Regards. signature.asc Description: This is a digitally signed message part. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Rsync-daemon security advisories for writable daemons
On Mon, 2007-12-10 at 22:20 +0100, Olivier Thauvin wrote: I don't how to really fix into rsync, except checking uname to get the running kernel's version. It would seem much more direct to simply attempt the lutimes and ignore an error of ENOSYS (Function not implemented). I don't think it's important for performance to make rsync not attempt lutimes again after an ENOSYS because IIRC, glibc's lutimes wrapper already does this. The current development rsync ignores all errors, but errors other than ENOSYS might be significant. For example, if the machine supports lutimes but the symlink belongs to another user, lutimes could fail with EPERM, and I would want to know about that just like for a regular file. Matt -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Rsync-daemon security advisories for writable daemons
There are two security advisories for people who run a writable rsync daemon. One affects only those with use chroot = no (which is not a very safe combination in general), and one affects a daemon that has daemon-excluded files that are being hidden in a module's hierarchy. Included are simple config-change suggestions that should help you to avoid the security issues. These advisories affect all rsync versions. Advisory #1: If you are running a writable rsync daemon with use chroot = no, there is at least one way for someone to trick rsync into creating a symlink that points outside of the module's hierarchy. This means that if you are allowing access from users who you don't trust, that you should either figure out a way to turn on use chroot, or configure the daemon to refuse the --links option (see refuse options in the rsyncd.conf manpage) which will disable the ability of the rsync module to receive symlinks. After doing so, you should also check that any existing symlinks in the daemon hierarchy are safe. Starting with the 3.0.0-pre6 release, there will be a new daemon option available: munge symlinks. This will allow an rsync daemon to accept symlinks and return them intact (with even a leading slash still there, which is new for a non-chroot daemon), but will not allow the symlinks to be used while they are in the daemon's hierarchy. For those running 2.6.9, there is a patch to enable this option: http://rsync.samba.org/ftp/rsync/munge-symlinks-2.6.9.diff Any admin applying that patch should read the munge symlinks section of the modified rsyncd.conf manpage for more information. You can also read about this option in the latest manpage from the dev version: http://rsync.samba.org/ftp/rsync/nightly/rsyncd.conf.html Advisory #2: If you are running a writable rsync daemon that is using one of the exclude, exclude from, or filter options in the rsyncd.conf file to hide data from your users, you should be aware that there are tricks that a user can play with symlinks and/or certain options that can allow a user that knows the name of a hidden file to access it or overwrite it (if file permissions allow that). You can avoid the symlink problem using the suggestions for Advisory #1. You can avoid the problems with other options by putting the following refuse options setting into your rsyncd.conf file: refuse options = --*-dest --partial-dir --backup-dir An upcoming release of rsync 3.0.0 will hopefully fix the daemon-exclude validation of these options to make this unnecessary, but this has not yet been implemented. If you combine the above refuse options with the prior suggestion to refuse --links, that would give you this list of options (included here for easier copy/pasting): refuse options = --links --*-dest --partial-dir --backup-dir Finally, a big thank you to Matt McCutchen for his security work in discovering and reporting these problems, suggesting avoidance options, and helping me to test my munge-symlinks patch. ..wayne.. signature.asc Description: Digital signature -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
