Bug 28460 - krb5-appl new security issues CVE-2019-25017 and CVE-2019-25018
Summary: krb5-appl new security issues CVE-2019-25017 and CVE-2019-25018
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 8
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL:
Whiteboard: MGA7TOO MGA8-64-OK MGA7-64-OK
Keywords: validated_update
Depends on:
Blocks:
 
Reported: 2021-02-26 22:34 CET by David Walser
Modified: 2021-04-21 22:24 CEST (History)
5 users (show)

See Also:
Source RPM: krb5-appl-1.0.3-13.mga8.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2021-02-26 22:34:50 CET
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.
David Walser 2021-02-26 22:35:03 CET

Whiteboard: (none) => MGA8TOO, MGA7TOO

Comment 1 Lewis Smith 2021-02-27 10:02:46 CET
Uncertain maintainer, so assigning globally; CC'ing DavidG who did last security update.

Assignee: bugsquad => pkg-bugs
CC: (none) => geiger.david68210

Comment 2 Nicolas Lécureuil 2021-03-05 19:12:18 CET
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

Version: Cauldron => 8
Assignee: pkg-bugs => qa-bugs
CC: (none) => mageia
Whiteboard: MGA8TOO, MGA7TOO => MGA7TOO

Comment 3 David Walser 2021-03-05 19:58:00 CET
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
Comment 4 Herman Viaene 2021-03-22 15:24:01 CET
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

Comment 5 David Walser 2021-03-22 15:29:17 CET
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.
Comment 6 Herman Viaene 2021-04-02 12:26:56 CEST
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.
Comment 7 David Walser 2021-04-02 17:09:08 CEST
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.
Comment 8 Dave Hodgins 2021-04-21 01:02:11 CEST
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?

CC: (none) => davidwhodgins
Whiteboard: MGA7TOO => MGA7TOO MGA8-64-OK MGA7-64-OK

Dave Hodgins 2021-04-21 01:02:44 CEST

Keywords: (none) => feedback

Comment 9 David Walser 2021-04-21 01:19:38 CEST
Nothing changed in krb5-appl, so maybe the issue is in krb5 or elsewhere.

Keywords: feedback => (none)

Comment 10 Dave Hodgins 2021-04-21 07:07:27 CEST
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.
Comment 11 Dave Hodgins 2021-04-21 07:33:36 CEST
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
Comment 12 Dave Hodgins 2021-04-21 07:35:28 CEST
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.
Comment 13 Dave Hodgins 2021-04-21 22:24:45 CEST
I've validated this update. Will open a new bug report after I investigate
the Mageia 8 krb5 problem more.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs


Note You need to log in before you can comment on or make changes to this bug.