[HN Gopher] Rsync vulnerabilities
       ___________________________________________________________________
        
       Rsync vulnerabilities
        
       Author : pavodive
       Score  : 114 points
       Date   : 2025-01-15 02:45 UTC (20 hours ago)
        
 (HTM) web link (www.openwall.com)
 (TXT) w3m dump (www.openwall.com)
        
       | jmclnx wrote:
       | Slackware sent a fixed version of rsync out yesterday.
       | 
       | But I wonder of OpenBSD's openrsync has the same issue ? Or did
       | that version avoid the issues when it was created ?
       | 
       | If it was avoided, seems OpenBSD was ahead of the curve again.
        
         | cf100clunk wrote:
         | I'm running several Linux distros and package updates to rsync
         | version 3.2.7 have showed up on all of them already. I can't
         | comment on openrsync.
        
         | crest wrote:
         | Given the more permissive license openrsync would be in a
         | pickle if they stole the vulnerable GPL code and claimed to
         | redistribute it under BSD license instead of reimplementing the
         | protocol.
        
         | ducktective wrote:
         | Debian issued a security update too:                 rsync
         | (3.2.7-1+deb12u1) bookworm-security; urgency=high
        
         | somat wrote:
         | openrsync is a neat story, it was made because they wanted to
         | use rsync in the rpki system, but the standards body balked,
         | saying they should not be using something where the standard
         | was the implementation, so the openbsd folk(specifically
         | Kristaps Dzonsons) stepped up and made a second rsync
         | implementation so that the standards body could accept the
         | protocol.
         | 
         | http://man.openbsd.org/rpki-client
        
       | concerndc1tizen wrote:
       | Do I read correctly that this is related to "rsync daemon"
       | (rsyncd), and therefore has minimal impact on people who just use
       | rsync over ssh?
        
         | bell-cot wrote:
         | My read (not an expert) is that you are safe if your rsync is
         | only via secure connections, to & from systems where untrusted
         | parties can neither run rsync, nor play clever games with the
         | files which rsync is accessing.
         | 
         | Which (in my paranoid opinion) is pretty much the only secure
         | use case anyway, for code like rsync.
        
           | kees99 wrote:
           | > you are safe if your rsync is only via secure connections
           | 
           | Not quite. If server has "command=rsync ..." in
           | ~/.ssh/authorized_keys file, for some ssh key (to allow rsync
           | access, but deny shell access), this vulnerability will allow
           | attacker in possession of that ssh key to go around that
           | restriction, and get shell nonetheless.
        
             | nrdvana wrote:
             | He said where untrusted parties aren't able to run rsync.
             | 
             | If I was running an rsync daemon facing the public, it
             | would be in a chroot with dropped privileges.
        
         | mhw wrote:
         | My reading is that the first two CVEs are with rsync daemon,
         | but the others are more general - I think "rsync server" is
         | meaning the remote rsync process that is started when you use
         | ssh to connect to the remote. Some of them suggest the rsync
         | client (running on your machine) can be coerced to write to
         | unexpected locations by a malicious rsync server specifically
         | crafted to exploit these CVEs. One suggests a malicious rsync
         | server might be able to reconstruct the contents of arbitrary
         | files on the client using requests sent via the rsync protocol.
         | 
         | I guess the main takeaway is to be careful using rsync
         | connections to machines that you don't trust.
        
         | formerly_proven wrote:
         | Every rsync operation (even locally) involves an rsync client
         | and a separate rsync server process.
        
         | crest wrote:
         | It's the same protocol and code implementing it just proxied
         | over SSH instead of a local pipe or unix socket pair. It's a
         | real world issue unless you trust the remote rsync process and
         | the connection with your local user. So basically only SSH
         | between your single-user desktop and same single-user laptop is
         | unimpacted.
        
       | chasil wrote:
       | Does this apply to the GPL or BSD codebase?
       | 
       | There are (now) two rsync codebases.
       | 
       | GPL: https://rsync.samba.org/
       | 
       | BSD: https://www.openrsync.org/
        
         | crest wrote:
         | It applies to only to rsync and to not the (Open)BSD rewrite
         | openrsync. openrsync intentionally doesn't reimplement all
         | features so it's not always a drop in replacement.
        
       | samueloph wrote:
       | There's a serious regression in the fixes:
       | https://github.com/RsyncProject/rsync/issues/702
       | 
       | It impacts those who need to use `-r` (recursive) together with
       | `-H` (preserve hardlinks),
        
         | SOLAR_FIELDS wrote:
         | Fix was merged an hour ago, roughly an hour after you made this
         | comment (at which time they were still working on it)
        
       | ThatGuyRaion wrote:
       | Are these applicable to the openrsync project?
        
       | captainbland wrote:
       | > Anonymous read access to a rsync server... such as on a public
       | mirror
       | 
       | I did not know people did that.
        
       ___________________________________________________________________
       (page generated 2025-01-15 23:02 UTC)