Debian-LTS has issued an advisory on November 18: https://www.debian.org/lts/security/2021/dla-2822 Mageia 8 is also affected.
Whiteboard: (none) => MGA8TOOStatus comment: (none) => Patches available from Debian
Suggested advisory: ======================== The updated packages fix security vulnerabilities: In NetKit through 0.17, rcp.c in the rcp client allows remote rsh servers to bypass intended access restrictions via the filename of . or an empty filename. The impact is modifying the permissions of the target directory on the client side. This is similar to CVE-2018-20685. (CVE-2019-7282) An issue was discovered in rcp in NetKit through 0.17. For an rcp operation, the server chooses which files/directories are sent to the client. However, the rcp client only performs cursory validation of the object name returned. A malicious rsh server (or Man-in-The-Middle attacker) can overwrite arbitrary files in a directory on the rcp client machine. This is similar to CVE-2019-6111. (CVE-2019-7283) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7282 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7283 https://www.debian.org/lts/security/2021/dla-2822 ======================== Updated packages in core/updates_testing: ======================== rsh-server-0.17-36.1.mga8 rsh-0.17-36.1.mga8 from SRPM: rsh-0.17-36.1.mga8.src.rpm
Whiteboard: MGA8TOO => (none)CVE: (none) => CVE-2019-7282, CVE-2019-7283Status comment: Patches available from Debian => (none)Status: NEW => ASSIGNEDCC: (none) => nicolas.salgueroAssignee: bugsquad => qa-bugsVersion: Cauldron => 8
MGA8-64 Plasma on Lenovo B50 At installation had a message saying some pakage had to be removed (did not note the name, sorry), but accepting that, the installaion went OK. No wikior previous updates, so googled and found pages like https://www.unix.com/red-hat/150438-how-enable-test-rsh-rcp-rhel-5-3-a.html and https://www.unix.com/red-hat/150438-how-enable-test-rsh-rcp-rhel-5-3-a.html Did the recommended changes (opened port 543 in firewall). But after restarting xinetd # systemctl -l status xinetd ● xinetd.service - Xinetd A Powerful Replacement For Inetd Loaded: loaded (/usr/lib/systemd/system/xinetd.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2021-11-22 12:00:38 CET; 3s ago Docs: man:xinetd man:xinetd.conf man:xinetd.log Main PID: 12045 (xinetd) Tasks: 1 (limit: 9402) Memory: 756.0K CPU: 304ms CGroup: /system.slice/xinetd.service └─12045 /usr/sbin/xinetd -stayalive -dontfork nov 22 12:00:38 mach5.hviaene.thuis systemd[1]: Started Xinetd A Powerful Replacement For Inetd. nov 22 12:00:39 mach5.hviaene.thuis xinetd[12045]: Reading included configuration file: /etc/xinetd.d/rexec [file=/etc/xinetd.conf] [line=60] nov 22 12:00:39 mach5.hviaene.thuis xinetd[12045]: Reading included configuration file: /etc/xinetd.d/rlogin [file=/etc/xinetd.d/rlogin] [line=14] nov 22 12:00:39 mach5.hviaene.thuis xinetd[12045]: Reading included configuration file: /etc/xinetd.d/rsh [file=/etc/xinetd.d/rsh] [line=14] nov 22 12:00:39 mach5.hviaene.thuis xinetd[12045]: Reading included configuration file: /etc/xinetd.d/sshd-xinetd [file=/etc/xinetd.d/sshd-xinetd] [line=15] nov 22 12:00:39 mach5.hviaene.thuis xinetd[12045]: 2.3.15.4 started with libwrap loadavg options compiled in. nov 22 12:00:39 mach5.hviaene.thuis xinetd[12045]: Started working: 1 available service Tried to connect from my desktop with the command $ rsh mach5 -l tester8 ls connect to address 192.168.2.5 port 544: Connection timed out When I change the frewall rule (using MCC) to allow port 544 i.s.o port 543,the message changes to Connection refused, same with both 543 and 544 allowed. This is beyond me.
CC: (none) => herman.viaene
Did you enable the rsh xinetd service? /etc/xinetd.d/rsh should say enabled = yes.
There was no line on "enable" in that file, but a "disable = yes" which I changed to no Anyway, adding the line "enable = yes" does not improve the situation Worse, when I start now the xinetd, it starts OK but shows a line: nov 22 16:34:03 mach5.hviaene.thuis xinetd[4654]: bad service attribute: enable [file=/etc/xinetd.d/rsh] [line=15]
For xinetd services, change the disable=yes to disable=no, then restart xinetd.
CC: (none) => davidwhodgins
Oops, sorry, disable = no is what I meant. Make sure you reload the xinetd service.
@Dave:that's exactly what I did.
Got it working. Both rsh and rlogin must be enabled. By default, if an ipv6 address is available, it will only listen to the ipv6 address. If ipv6 is not available, it uses ipv4. To get it to listen to both v6 and v4, add ... flags = IPV4 IPV6 to the rsh and rlogin files in /etc/xinetd.d If I'm reading it correctly, forward/reverse dns lookups within the lan must match (which I have previously set up for ipv4 on my lan for kerberos testing). The user on the server (x3.hodgins.homeip.net in my case) who will be logged into from the remote must give permission ... [dave@x3 ~]$ cat .rhosts rp4.hodgins.homeip.net The above gives permission for the user dave to be logged into from the host rp4, which is on my lan. On rp4, ... [dave@rp4 ~]$ rsh x3.hodgins.homeip.net hostname x3.hodgins.homeip.net Validating the update.
CC: (none) => sysadmin-bugsKeywords: (none) => validated_updateWhiteboard: (none) => MGA8-64-OK has_procedure
Fyi, the package that gets removed is krb5-appl-clients as krlogin conflicts with rlogin, just in case you want to restore it.
Keywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2021-0525.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED