7 ms·

Rsync client-side arbitrary file write vulnerability

135 points by jwilk 4y ago

blueflow 4y ago
Wasn't this kind of bug part of the reasoning to make scp use stfp in the background, instead of using its own scp protocol?
- water8 4y ago
  Scp does not use sftp in the background. Scp is generally faster than sftp but lacks many capabilities like remote dir listing
  - blueflow 4y ago
    It does since recently, check the -O option in the manpage.
    - water8 4y ago
      No it doesn’t SCP has no support for directory listing. The -o flag only controls the security layer which is openSSL just like SFTP. So you established the S’s are the same, But the P’s (protocol) are different. A protocol is like get post put… Totally separate from security
      - blueflow 4y ago
        https://www.openssh.com/txt/release-9.0 https://www.openssh.com/txt/release-9.0 : > This release switches scp(1) from using the legacy scp/rcp protocol to using the SFTP protocol by default. From the scp(1) manpage: > -O: Use the original SCP protocol for file transfers instead of the SFTP protocol. Forcing the use of the SCP protocol may be necessary for servers that do not implement SFTP, for backwards-compatibility for particular filename wildcard patterns and for expanding paths with a ‘~’ prefix for older SFTP servers. This mode is the default.
develatio 4y ago
It looks like this was reported 8 days ago and was patched 2 days ago[0]. It was then packaged in v3.2.5pre1 12 hours ago[1] It's always conforming to see such a fast response time :) [0] - https://github.com/WayneD/rsync/commit/b7231c7d02cfb65d291af74ff66e7d8c507ee871 https://github.com/WayneD/rsync/commit/b7231c7d02cfb65d291af... [1] - https://github.com/WayneD/rsync/releases/tag/v3.2.5pre1 https://github.com/WayneD/rsync/releases/tag/v3.2.5pre1
ollien 4y ago
Maybe my sleuthing skills are lacking this morning, but is there a reported minimum affected version?
- ksbrooksjr 4y ago
  It looks like versions prior to 3.2.5 are affected [1]. If you're using the version of rsync bundled with MacOS, then it's affected. If you're not connecting to random malicious servers then this might not be a part of your threat model though. As long as your private keys are secure, and you've verified the public keys in your known_hosts file, then this exploit would be hard to take advantage of by a man in the middle attack. Basically, all of the normal security rules of the underlying SSH protocol apply here. [1] https://nvd.nist.gov/vuln/detail/CVE-2022-29154 https://nvd.nist.gov/vuln/detail/CVE-2022-29154
NelsonMinar 4y ago
I'm struck by how big the code fix is; 200 line diff, at least 100 lines of code with new logic.
phoe-krk 4y ago
https://github.com/WayneD/rsync/commit/b7231c7d02cfb65d291af74ff66e7d8c507ee871#diff-a2ece3bcd75598be3f1c0a517c320f593557a5867f93382bcd2dfd850f5250b3 https://github.com/WayneD/rsync/commit/b7231c7d02cfb65d291af... This newly added function, add_implied_include, which was committed as a part of the patch gives me the creeps. I do not claim to be competent enough to work with a utility as important as rsync, but looking at C code written like that makes me grateful for that fact.
- testplzignore 4y ago
  I'm glad I'm not the only one who thinks this. Clever parsing code, multiple commits to get it right (https://github.com/WayneD/rsync/commit/2f7c583143bc6e80902139c23d9d7283f88fbc6a https://github.com/WayneD/rsync/commit/2f7c583143bc6e8090213..., https://github.com/WayneD/rsync/commit/3d7015afa223494e3318495c2f5de9cb49229da9 https://github.com/WayneD/rsync/commit/3d7015afa223494e33184...), no tests, seemingly no code review. Not an attack on the maintainer of rsync - this pattern is typical for security patches. Within a few days, tools like Twistlock are going to alert on the CVE, and companies across the world will blindly upgrade without reviewing the change. Rinse and repeat thousands of times per year. Our industry continues to not take security seriously while pretending that it does.
  - kbenson 4y ago
    My guess (hope) is that orgs like Red Hat will vet it a bit before putting it out, since they'll have to dive into the code and apply or reimplements it for multiple past versions of rsync. That actually covers a lot of companies using it. Paying (or at least relying on) another company to take care of that for you is what most places do. Honestly, that's better than tens of thousands of people wasting time on the same thing IMO.
  - fsflover 4y ago
    If you care about security, you should not rely on a perfect code. Consider compartmentalization instead: https://qubes-os.org https://qubes-os.org. Works for me (or so I hope).
Koenvh 4y ago
Funny, I reported something similar on the rsync mailing list a couple of months ago: https://www.mail-archive.com/rsync@lists.samba.org/msg33452.html https://www.mail-archive.com/rsync@lists.samba.org/msg33452.... Good to see that it will be fixed. Still, rsync is not the right tool for the job if you do not trust the server.
- bragr 4y ago
  >rsync is not the right tool for the job if you do not trust the server Why would you ever trust the server not to do bad things?
  - Koenvh 4y ago
    I do trust my own server not to misbehave, but I probably would not trust some random server on the internet.
    - bragr 4y ago
      I've had personal servers compromised. I don't unconditionally trust them either.
    - ksbrooksjr 4y ago
      Exactly. I'm usually worried about the opposite scenario (the client infecting the server). If you're copying files from a personal computer it might have all sorts of random software running on it that's accumulated over the years. Whereas on a remote server you tend to have a better security posture, and aren't installing random software and apps. Admittedly, that might just be my personal use case though.
  - deleted 4y ago
    [deleted]
- jwilk 4y ago
  Or if you can't stand mail-archive.com: https://lists.samba.org/archive/rsync/2022-March/032769.html https://lists.samba.org/archive/rsync/2022-March/032769.html
theonemind 4y ago
Seems like a good time to plug https://github.com/kristapsdz/openrsync https://github.com/kristapsdz/openrsync , especially on OpenBSD. You wouldn't get complete arbitrary file write vulnerability, only where unveil(2)ed.
GoblinSlayer 4y ago
> a malicious rysnc server (or Man-in-The-Middle attacker) can overwrite arbitrary files in the rsync client target directory and subdirectories Do I read it right? You rsync to a malicious server and bother you get bogus files from it?

135 points by jwilk 4y ago

Wasn't this kind of bug part of the reasoning to make scp use stfp in the background, instead of using its own scp protocol?

water8 4y ago
Scp does not use sftp in the background. Scp is generally faster than sftp but lacks many capabilities like remote dir listing
- blueflow 4y ago
  It does since recently, check the -O option in the manpage.
  - water8 4y ago
    No it doesn’t SCP has no support for directory listing. The -o flag only controls the security layer which is openSSL just like SFTP. So you established the S’s are the same, But the P’s (protocol) are different. A protocol is like get post put… Totally separate from security
    - blueflow 4y ago
      https://www.openssh.com/txt/release-9.0 https://www.openssh.com/txt/release-9.0 : > This release switches scp(1) from using the legacy scp/rcp protocol to using the SFTP protocol by default. From the scp(1) manpage: > -O: Use the original SCP protocol for file transfers instead of the SFTP protocol. Forcing the use of the SCP protocol may be necessary for servers that do not implement SFTP, for backwards-compatibility for particular filename wildcard patterns and for expanding paths with a ‘~’ prefix for older SFTP servers. This mode is the default.

develatio 4y ago

It looks like this was reported 8 days ago and was patched 2 days ago[0]. It was then packaged in v3.2.5pre1 12 hours ago[1] It's always conforming to see such a fast response time :) [0] - https://github.com/WayneD/rsync/commit/b7231c7d02cfb65d291af74ff66e7d8c507ee871 https://github.com/WayneD/rsync/commit/b7231c7d02cfb65d291af... [1] - https://github.com/WayneD/rsync/releases/tag/v3.2.5pre1 https://github.com/WayneD/rsync/releases/tag/v3.2.5pre1

ollien 4y ago

Maybe my sleuthing skills are lacking this morning, but is there a reported minimum affected version?

ksbrooksjr 4y ago
It looks like versions prior to 3.2.5 are affected [1]. If you're using the version of rsync bundled with MacOS, then it's affected. If you're not connecting to random malicious servers then this might not be a part of your threat model though. As long as your private keys are secure, and you've verified the public keys in your known_hosts file, then this exploit would be hard to take advantage of by a man in the middle attack. Basically, all of the normal security rules of the underlying SSH protocol apply here. [1] https://nvd.nist.gov/vuln/detail/CVE-2022-29154 https://nvd.nist.gov/vuln/detail/CVE-2022-29154

NelsonMinar 4y ago

I'm struck by how big the code fix is; 200 line diff, at least 100 lines of code with new logic.

phoe-krk 4y ago

https://github.com/WayneD/rsync/commit/b7231c7d02cfb65d291af74ff66e7d8c507ee871#diff-a2ece3bcd75598be3f1c0a517c320f593557a5867f93382bcd2dfd850f5250b3 https://github.com/WayneD/rsync/commit/b7231c7d02cfb65d291af... This newly added function, add_implied_include, which was committed as a part of the patch gives me the creeps. I do not claim to be competent enough to work with a utility as important as rsync, but looking at C code written like that makes me grateful for that fact.

testplzignore 4y ago
I'm glad I'm not the only one who thinks this. Clever parsing code, multiple commits to get it right (https://github.com/WayneD/rsync/commit/2f7c583143bc6e80902139c23d9d7283f88fbc6a https://github.com/WayneD/rsync/commit/2f7c583143bc6e8090213..., https://github.com/WayneD/rsync/commit/3d7015afa223494e3318495c2f5de9cb49229da9 https://github.com/WayneD/rsync/commit/3d7015afa223494e33184...), no tests, seemingly no code review. Not an attack on the maintainer of rsync - this pattern is typical for security patches. Within a few days, tools like Twistlock are going to alert on the CVE, and companies across the world will blindly upgrade without reviewing the change. Rinse and repeat thousands of times per year. Our industry continues to not take security seriously while pretending that it does.
- kbenson 4y ago
  My guess (hope) is that orgs like Red Hat will vet it a bit before putting it out, since they'll have to dive into the code and apply or reimplements it for multiple past versions of rsync. That actually covers a lot of companies using it. Paying (or at least relying on) another company to take care of that for you is what most places do. Honestly, that's better than tens of thousands of people wasting time on the same thing IMO.
- fsflover 4y ago
  If you care about security, you should not rely on a perfect code. Consider compartmentalization instead: https://qubes-os.org https://qubes-os.org. Works for me (or so I hope).

Koenvh 4y ago

Funny, I reported something similar on the rsync mailing list a couple of months ago: https://www.mail-archive.com/rsync@lists.samba.org/msg33452.html https://www.mail-archive.com/rsync@lists.samba.org/msg33452.... Good to see that it will be fixed. Still, rsync is not the right tool for the job if you do not trust the server.

bragr 4y ago
>rsync is not the right tool for the job if you do not trust the server Why would you ever trust the server not to do bad things?
- Koenvh 4y ago
  I do trust my own server not to misbehave, but I probably would not trust some random server on the internet.
  - bragr 4y ago
    I've had personal servers compromised. I don't unconditionally trust them either.
  - ksbrooksjr 4y ago
    Exactly. I'm usually worried about the opposite scenario (the client infecting the server). If you're copying files from a personal computer it might have all sorts of random software running on it that's accumulated over the years. Whereas on a remote server you tend to have a better security posture, and aren't installing random software and apps. Admittedly, that might just be my personal use case though.
- deleted 4y ago
  [deleted]
jwilk 4y ago
Or if you can't stand mail-archive.com: https://lists.samba.org/archive/rsync/2022-March/032769.html https://lists.samba.org/archive/rsync/2022-March/032769.html

theonemind 4y ago

Seems like a good time to plug https://github.com/kristapsdz/openrsync https://github.com/kristapsdz/openrsync , especially on OpenBSD. You wouldn't get complete arbitrary file write vulnerability, only where unveil(2)ed.

GoblinSlayer 4y ago

> a malicious rysnc server (or Man-in-The-Middle attacker) can overwrite arbitrary files in the rsync client target directory and subdirectories Do I read it right? You rsync to a malicious server and bother you get bogus files from it?