Fix significant security holes with "use chroot = no" in an rsync daemon:
1. The file paths being sent and received were not "sanitized" to ensure that there weren't any ".." components that would escape the top level directory. This can't happen with the standard rsync client, but it could be exploited on both read and write if someone modified an rsync client. This fix sanitizes all incoming and outgoing paths when "use chroot = no". 2. If a module is also "read only = no", clients could have created symbolic links with ".." components that would allow writing outside of the module. This could happen with the standard rsync client. This fix sanitizes all incoming symbolic link targets when "use chroot = no". Previously, only top-level paths (anything passed in command line arguments) were sanitized. Sorry, I didn't think about the individual file paths before now.
Showing
Please register or sign in to comment