SUSE has issued an advisory on February 19: https://lists.suse.com/pipermail/sle-security-updates/2021-February/008353.html Mageia 7 and Mageia 8 are also affected.
Whiteboard: (none) => MGA8TOO, MGA7TOO
Uncertain maintainer, so assigning globally; CC'ing DavidG who did last security update.
CC: (none) => geiger.david68210Assignee: bugsquad => pkg-bugs
Fixed in cauldron. Patches added in mga 7/8: src: - mageia7: - krb5-appl-1.0.3-10.2.mga7 - mageia8: - krb5-appl-1.0.3-13.1.mga8
Assignee: pkg-bugs => qa-bugsVersion: Cauldron => 8Whiteboard: MGA8TOO, MGA7TOO => MGA7TOOCC: (none) => mageia
Advisory: ======================== Updated krb5-appl packages fix security vulnerabilities: An issue was discovered in rcp in MIT krb5-appl through 1.0.3. Due to the rcp implementation being derived from 1983 rcp, the server chooses which files/directories are sent to the client. However, the rcp client only performs cursory validation of the object name returned (only directory traversal attacks are prevented). A malicious rcp server (or Man-in-The-Middle attacker) can overwrite arbitrary files in the rcp client target directory. If recursive operation (-r) is performed, the server can manipulate subdirectories as well (for example, to overwrite the .ssh/authorized_keys file). This issue is similar to CVE-2019-6111 and CVE-2019-7283 (CVE-2019-25017). In the rcp client in MIT krb5-appl through 1.0.3 malicious servers could bypass intended access restrictions via the filename of . or an empty filename, similar to CVE-2018-20685 and CVE-2019-7282. The impact is modifying the permissions of the target directory on the client side (CVE-2019-25018). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-25017 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-25018 https://lists.suse.com/pipermail/sle-security-updates/2021-February/008353.html ======================== Updated packages in core/updates_testing: ======================== krb5-appl-servers-1.0.3-10.2.mga7 krb5-appl-clients-1.0.3-10.2.mga7 krb5-appl-servers-1.0.3-13.1.mga8 krb5-appl-clients-1.0.3-13.1.mga8 from SRPMS: krb5-appl-1.0.3-10.2.mga7.src.rpm krb5-appl-1.0.3-13.1.mga8.src.rpm
MGA7-64 MATE on PeaqC1011 No installation issues. Found link to wiki page in bug 26451, not on the wiki reference on toold/updates Anyway, the wiki starts that you need to install the krb5-server. Is that just for the testing sake, or is that a real deoendency??? And then still to do a "wget" to get a setup????
CC: (none) => herman.viaene
These packages contain kerberized rcp and telnet clients and servers, which means that Kerberos can be used for authentication. Testing that aspect would require some kind of KDC, such as krb5-server, but Kerberos is not relevant to these security issues, so that is not needed. They involve other aspects of the rcp implementations.
Found some info on https://www.systutorials.com/docs/linux/man/8-in.telnetd/ So, on one MATE terminal tab I issued: # telnetd -debug 8080 that hangs as the telentd runs and on a second tab als normal user: [tester7@mach7 ~]$ telnet mach7 8080 Trying 192.168.2.7... Connected to mach7.hviaene.thuis (192.168.2.7). Escape character is '^]'. mach7.hviaene.thuis (Linux release 5.10.27-desktop-1.mga7 #1 SMP Wed Mar 31 00:16:43 UTC 2021) (2) login: testtelnet Password: Last login: Fri Apr 2 12:19:58 from mach7 [testtelnet@mach7 ~]$ ls tmp/ So, that seems to work. One remark: when exiting from this session, the telnetd is also terminated. I have no idea why or whether this should not happen. But OK'ing, I would not object.
Yes, telnetd is not meant to be run that way. It normally gets run via xinetd or as a systemd socket-activated service, where telnetd itself is only run to handle an active connection to the service.
Testing using the procedure https://wiki.mageia.org/en/QA_procedure:Krb5 [dave@x7v ~]$ kinit Password for dave@X7V.HODGINS.HOMEIP.NET: [dave@x7v ~]$ klist Ticket cache: FILE:/tmp/krb5cc_2000 Default principal: dave@X7V.HODGINS.HOMEIP.NET Valid starting Expires Service principal 2021-04-20 18:39:25 2021-04-21 18:39:25 krbtgt/X7V.HODGINS.HOMEIP.NET@X7V.HODGINS.HOMEIP.NET renew until 2021-04-20 18:39:25 [dave@x7v ~]$ krlogin $(hostname) This rlogin session is encrypting all data transmissions. Last login: Tue Apr 20 18:38:19 on :0 No regressions found on Mageia 7. On Mageia 8, the krlogin step is failing, both before and after installing the update, with no error message. The only difference I can find in the journals between m7 and m8 is that on m7 ... Apr 20 18:40:07 xinetd[2608]: START: eklogin from=::ffff:192.168.10.116 Apr 20 18:45:01 xinetd[2608]: EXIT: eklogin status=1 duration=294(sec) while on m8 ... Apr 20 18:40:43 xinetd[1188]: START: eklogin from=::ffff:192.168.10.112 Apr 20 18:40:43 xinetd[1188]: EXIT: eklogin status=1 duration=0(sec) So on m7 the eklogin remains running until I enter the exit command, but on m8 it's exiting immediately. No error messages, just the krlogin command terminating immediately, returning to the command prompt. I'm adding the ok tags for both m7 and m8 as no regressions found. Would you prefer I validate the update as is to get the fix out or wait till we can figure out what changed in krlogin between m7 or m8?
Whiteboard: MGA7TOO => MGA7TOO MGA8-64-OK MGA7-64-OKCC: (none) => davidwhodgins
Keywords: (none) => feedback
Nothing changed in krb5-appl, so maybe the issue is in krb5 or elsewhere.
Keywords: feedback => (none)
Also found some differences in /var/log/krb5kdc.log On Mageia 8, where krlogin seems to exit immediately ... Apr 21 00:39:22 x8v.hodgins.homeip.net krb5kdc[1219](info): AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17), camellia128-cts-cmac(25)}) 192.168.10.112: ISSUE: authtime 1618979962, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, dave@X8V.HODGINS.HOMEIP.NET for krbtgt/X8V.HODGINS.HOMEIP.NET@X8V.HODGINS.HOMEIP.NET Apr 21 00:44:02 x8v.hodgins.homeip.net krb5kdc[1219](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17), camellia128-cts-cmac(25)}) 192.168.10.112: ISSUE: authtime 1618979962, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, dave@X8V.HODGINS.HOMEIP.NET for host/x8v.hodgins.homeip.net@X8V.HODGINS.HOMEIP.NET On Mageia 7 where it opens a shell and waits for the exit command ... Apr 21 00:46:42 x7v.hodgins.homeip.net krb5kdc[2684](info): AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 192.168.10.116: ISSUE: authtime 1618980402, etypes {rep=18 tkt=18 ses=18}, dave@X7V.HODGINS.HOMEIP.NET for krbtgt/X7V.HODGINS.HOMEIP.NET@X7V.HODGINS.HOMEIP.NET Apr 21 00:46:58 x7v.hodgins.homeip.net krb5kdc[2684](info): TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 192.168.10.116: ISSUE: authtime 1618980402, etypes {rep=18 tkt=18 ses=18}, dave@X7V.HODGINS.HOMEIP.NET for host/x7v.hodgins.homeip.net@X7V.HODGINS.HOMEIP.NET The lines prior to that point for that kinit session are identical. No idea if that's relevant.
Decided to try krb5-telnet to see if it's only krlogin that's failing. After enabling it and restarting xinetd, it's working in m7, but failing in m8 with ... $ telnet $(hostname) Trying 192.168.10.112... Connected to x8v.hodgins.homeip.net (192.168.10.112). Escape character is '^]'. Unencrypted connection refused. Goodbye. Connection closed by foreign host. $ rpm -q -f /usr/bin/telnet krb5-appl-clients-1.0.3-13.1.mga8
Just to be clear, I do have forward/reverse dns matching ... [dave@x8v log]$ host $(hostname) x8v.hodgins.homeip.net has address 192.168.10.112 [dave@x8v log]$ host 192.168.10.112 112.10.168.192.in-addr.arpa domain name pointer x8v.hodgins.homeip.net.
I've validated this update. Will open a new bug report after I investigate the Mageia 8 krb5 problem more.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Keywords: (none) => advisoryCC: (none) => ouaurelienCVE: (none) => CVE-2019-25017, CVE-2019-25018
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2021-0196.html
Status: NEW => RESOLVEDResolution: (none) => FIXED