Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rsync vulnerabilities

openwall.com

Post reply on HN
Print view View original

11–20 of 27 posts

Re: Rsync vulnerabilities

#11

Post by crest »

chasil wrote: post #8

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/

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.

Re: Rsync vulnerabilities

#12

Post by crest »

jmclnx wrote: post #2

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.

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.

Re: Rsync vulnerabilities

#14

Post by ducktective »

jmclnx wrote: post #2

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.

Debian issued a security update too:

  rsync (3.2.7-1+deb12u1) bookworm-security; urgency=high

Re: Rsync vulnerabilities

#15

Post by kees99 »

bell-cot wrote: post #5
concerndc1tizen wrote: post #3

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?

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.

> 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.

Re: Rsync vulnerabilities

#16

Post by nrdvana »

kees99 wrote: post #15
bell-cot wrote: post #5

Earlier quoted context omitted.

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.

> 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.

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.

Re: Rsync vulnerabilities

#18

Post by somat »

jmclnx wrote: post #2

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.

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

Re: Rsync vulnerabilities

#19

Post by SOLAR_FIELDS »

samueloph wrote: post #13

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),

Fix was merged an hour ago, roughly an hour after you made this comment (at which time they were still working on it)
Post reply on HN