Bugzilla – Bug 1201840
VUL-0: CVE-2022-29154: rsync: arbitrary file write vulnerability via do_server_recv function
Last modified: 2022-10-24 18:48:41 UTC
Public via oss-security: Date reported : July 25, 2022 CVE identifiers : CVE-2022-29154. ------------------------------------------------------------------------ Rsync client-side arbitrary file write vulnerability. (CVE-2022-29154) ------------------------------------------------------------------------ We have discovered a critical arbitrary file write vulnerability in the rsync utility that allows malicious remote servers to write arbitrary files inside the directories of connecting peers. The server chooses which files/directories are sent to the client. Due to the insufficient controls inside the [do_server_recv](https://github.com/WayneD/rsync/blob/85c56b2603d97c225889175797ffff6745a4d305/main.c#L1118) function, a malicious rysnc server (or Man-in-The-Middle attacker) can overwrite arbitrary files in the rsync client target directory and subdirectories. An attacker abusing this vulnerability can overwrite critical files under the target rsync directory and subdirectories (for example, to overwrite the .ssh/authorized_keys file). This issue is very similar with the [CVE-2019-6111](https://www.youtube.com/watch?v=fcesKgfSPq4). Best regards, Ege BALCI, Taha HAMAD. The vulnerability was addressed with the developer of the rsync project and necessary patches are made. Related commit and details can be found in the following links, - https://download.samba.org/pub/rsync/NEWS - https://download.samba.org/pub/rsync/rsync.1#MULTI-HOST_SECURITY - https://github.com/WayneD/rsync/commit/b7231c7d02cfb65d291af74ff66e7d8c507ee871 We recommend updating to the latest stable versions of rsync.
While stable version 3.2.5 is published, I patched 3.2.4 in Factory: Codestream Vers. Request ---------------------------------------------------------------------- openSUSE:Factory 3.2.4 https://build.opensuse.org/request/show/992350 https://build.opensuse.org/request/show/992351
SUSE-SU-2022:2825-1: An update that fixes one vulnerability is now available. Category: security (important) Bug References: 1201840 CVE References: CVE-2022-29154 JIRA References: Sources used: openSUSE Leap 15.4 (src): rsync-3.2.3-150400.3.3.1 SUSE Linux Enterprise Module for Basesystem 15-SP4 (src): rsync-3.2.3-150400.3.3.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
hi ... this update changes the behaviour of rsync incompatibly and broke the repo pushing to our other offices. While I agree the new behaviour can make sense, has the change been properly documented and customers have a chance of getting aware of this when installing the update ? rsync -avRH --timeout=7200 --fuzzy -e ssh -i $KEYFILE --no-group --exclude nosrc --exclude *-nosrc-*Media[0-9]* --exclude src --exclude *-src-*Media[0-9]* --exclude repoparts --exclude *-repoparts-*Media[0-9]* --exclude s390 --exclude *-s390-*Media[0-9]* --exclude s390x --exclude *-s390x-*Media[0-9]* --exclude ia64 --exclude *-ia64-*Media[0-9]* --exclude ppc --exclude *-ppc-*Media[0-9]* --exclude ppc64 --exclude *-ppc64-*Media[0-9]* --exclude ppc64le --exclude *-ppc64le-*Media[0-9]* --exclude aarch64 --exclude *-aarch64-*Media[0-9]* --exclude aarch64_ilp32 --exclude *-aarch64_ilp32-*Media[0-9]* --delete /mounts/dist/./ibs/SUSE/Updates/SLE-Module-Basesystem/15-SP4/s390x/update/ $USER@$DESTINATION:$DESTINATIONBASE sending incremental file list ERROR: rejecting excluded file-list name: ibs/SUSE/Updates/SLE-Module-Basesystem/15-SP4/s390x this just used to omit the directories with non-x86 rpms for the update repos before, now it refuses to sync the whole repo if one of the other archs matches the base path.
SUSE-SU-2022:2858-1: An update that fixes one vulnerability is now available. Category: security (important) Bug References: 1201840 CVE References: CVE-2022-29154 JIRA References: Sources used: SUSE Linux Enterprise Server 12-SP5 (src): rsync-3.1.3-3.9.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
SUSE-SU-2022:2859-1: An update that fixes one vulnerability is now available. Category: security (important) Bug References: 1201840 CVE References: CVE-2022-29154 JIRA References: Sources used: SUSE OpenStack Cloud Crowbar 9 (src): rsync-3.1.0-13.19.1 SUSE OpenStack Cloud 9 (src): rsync-3.1.0-13.19.1 SUSE Linux Enterprise Server for SAP 12-SP4 (src): rsync-3.1.0-13.19.1 SUSE Linux Enterprise Server 12-SP4-LTSS (src): rsync-3.1.0-13.19.1 SUSE Linux Enterprise Server 12-SP3-BCL (src): rsync-3.1.0-13.19.1 SUSE Linux Enterprise Server 12-SP2-BCL (src): rsync-3.1.0-13.19.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
SUSE-SU-2022:2959-1: An update that fixes one vulnerability is now available. Category: security (important) Bug References: 1201840 CVE References: CVE-2022-29154 JIRA References: Sources used: openSUSE Leap 15.3 (src): rsync-3.1.3-150000.4.13.1 SUSE Manager Server 4.1 (src): rsync-3.1.3-150000.4.13.1 SUSE Manager Retail Branch Server 4.1 (src): rsync-3.1.3-150000.4.13.1 SUSE Manager Proxy 4.1 (src): rsync-3.1.3-150000.4.13.1 SUSE Linux Enterprise Server for SAP 15-SP2 (src): rsync-3.1.3-150000.4.13.1 SUSE Linux Enterprise Server for SAP 15-SP1 (src): rsync-3.1.3-150000.4.13.1 SUSE Linux Enterprise Server for SAP 15 (src): rsync-3.1.3-150000.4.13.1 SUSE Linux Enterprise Server 15-SP2-LTSS (src): rsync-3.1.3-150000.4.13.1 SUSE Linux Enterprise Server 15-SP2-BCL (src): rsync-3.1.3-150000.4.13.1 SUSE Linux Enterprise Server 15-SP1-LTSS (src): rsync-3.1.3-150000.4.13.1 SUSE Linux Enterprise Server 15-SP1-BCL (src): rsync-3.1.3-150000.4.13.1 SUSE Linux Enterprise Server 15-LTSS (src): rsync-3.1.3-150000.4.13.1 SUSE Linux Enterprise Module for Basesystem 15-SP3 (src): rsync-3.1.3-150000.4.13.1 SUSE Linux Enterprise Micro 5.2 (src): rsync-3.1.3-150000.4.13.1 SUSE Linux Enterprise Micro 5.1 (src): rsync-3.1.3-150000.4.13.1 SUSE Linux Enterprise High Performance Computing 15-SP2-LTSS (src): rsync-3.1.3-150000.4.13.1 SUSE Linux Enterprise High Performance Computing 15-SP2-ESPOS (src): rsync-3.1.3-150000.4.13.1 SUSE Linux Enterprise High Performance Computing 15-SP1-LTSS (src): rsync-3.1.3-150000.4.13.1 SUSE Linux Enterprise High Performance Computing 15-SP1-ESPOS (src): rsync-3.1.3-150000.4.13.1 SUSE Linux Enterprise High Performance Computing 15-LTSS (src): rsync-3.1.3-150000.4.13.1 SUSE Linux Enterprise High Performance Computing 15-ESPOS (src): rsync-3.1.3-150000.4.13.1 SUSE Enterprise Storage 7 (src): rsync-3.1.3-150000.4.13.1 SUSE Enterprise Storage 6 (src): rsync-3.1.3-150000.4.13.1 SUSE CaaS Platform 4.0 (src): rsync-3.1.3-150000.4.13.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
SUSE-SU-2022:2959-2: An update that fixes one vulnerability is now available. Category: security (important) Bug References: 1201840 CVE References: CVE-2022-29154 JIRA References: Sources used: openSUSE Leap Micro 5.2 (src): rsync-3.1.3-150000.4.13.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
done, closing
we are currently evaluating to use the trust-sender submission for SP4 on our infrastructure. while reviewing the patch we noticed that the default value for trust-sender is 1? and as such always bypasses the security fix. Is this intended? We are looking at this chunk ``` @@ -780,6 +783,7 @@ static struct poptOption long_options[] {"protect-args", 's', POPT_ARG_VAL, &protect_args, 1, 0, 0}, {"no-protect-args", 0, POPT_ARG_VAL, &protect_args, 0, 0, 0}, {"no-s", 0, POPT_ARG_VAL, &protect_args, 0, 0, 0}, + {"trust-sender", 0, POPT_ARG_VAL, &trust_sender, 1, 0, 0}, {"numeric-ids", 0, POPT_ARG_VAL, &numeric_ids, 1, 0, 0 }, {"no-numeric-ids", 0, POPT_ARG_VAL, &numeric_ids, 0, 0, 0 }, {"usermap", 0, POPT_ARG_STRING, 0, OPT_USERMAP, 0, 0 }, ``` our understanding is that the `1` after `&trust_sender` is the default value.
Thanks for the review, Marcus. Gabrielle: * Do I resend the patch to all codestreams setting it to 0 as default? * Do we want to track this as a different bug?
Hi David, There's nothing to do, actually: The snippet in comment 28 refers to an internal structure (poptOption, [0]) that contains data used by rsync own option parsing code (popt.c). That code will set the pointed variable (&trust_sender) to the specified value (1) - or 1 if unspecified - only if the flag is passed as argument ([1]). If not, the variable is left untouched. Now, trust_sender is 0 by default ([2]), so it will be set to 1 only if the `--trust-sender` option is specified. Changing that field to 0 will make the `--trust-sender` flag a noop and rsync will not trust the sender ever. You can check the behavior with gdb, for example setting a breakpoint at the end of the option parse code ([3]): (gdb) b options.c:2477 Breakpoint 1 at 0x431052: file options.c, line 2477. (gdb) r a b Starting program: /root/host/rsync a b Breakpoint 1, parse_arguments (argc_p=argc_p@entry=0x7fffffffc54c, argv_p=argv_p@entry=0x7fffffffc540) at options.c:2477 2477 am_starting_up = 0; (gdb) p trust_sender $1 = 0 (gdb) r --trust-sender a b Starting program: /root/host/rsync --trust-sender a b Breakpoint 1, parse_arguments (argc_p=argc_p@entry=0x7fffffffc53c, argv_p=argv_p@entry=0x7fffffffc530) at options.c:2477 2477 am_starting_up = 0; (gdb) p trust_sender $2 = 1 [0] https://github.com/WayneD/rsync/blob/v3.2.5/popt/popt.h#L115 [1] https://github.com/WayneD/rsync/blob/v3.2.5/popt/popt.c#L872 [2] https://github.com/WayneD/rsync/blob/v3.2.5/options.c#L69 [3] https://github.com/WayneD/rsync/blob/v3.2.5/options.c#L2477
(In reply to Gabriele Sonnu from comment #30) > Hi David, > There's nothing to do, actually: > (...) Thanks Gabriele! A really good explanation. I understand this answers Marcus question in comment #28.
well, my point was (I was on this with Marcus Rückert) that we installed the patched version on a machine and it changed the behaviour from rejecting a rsync to accepting it again. This is why we assumed the default was changed by the option data, it might also be something else ...