Bugzilla – Bug 1131109
VUL-0: CVE-2019-25017,CVE-2019-25018: krb5-appl: affects krb5-appl kerberized rcp (related to CVE-2019-6111)
Last modified: 2024-05-07 09:13:04 UTC
krb5-appl rcp has the same CVE-2019-6111 vulnerability as openssh scp. I reported this to krbcore-security@mit.edu; they consider this package end-of-life / unsupported. I have a PoC exploit and partial mitigation patches for src/krb5-appl-1.0.1/bsd/krcp.c Version-Release number of selected component (if applicable): krb5-appl-1.0.1-7.el6 krb5-appl-1.0.1-7.el6_2.1.src.rpm How reproducible: Always. Steps to Reproduce: 1. Apply patch krb5-appl-2019-6111-poc.diff (available on request) 2. Run kshd with now-evil rcp 3.1 rcp remote-host:test.txt . 3.2 rcp remote-host:dirtest.txt . Actual results: 3.1 mode 0755 ./.badrcp.rc with nc | bash script. 3.2 mode 0755 /tmp/.badrcp.rc with same remote access script. Expected results: Requested file, or nothing if remote file non-existant. Additional info: My first report to bugzilla.redhat.com, apologies for any mistakes. Not sure how you wanted "Product / Component" categorised. The affected package is available at http://ftp.redhat.com/pub/redhat/linux/enterprise/6Client/en/os/SRPMS/krb5-appl-1.0.1-7.el6_2.1.src.rpm References: https://bugzilla.redhat.com/show_bug.cgi?id=1677794 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-611
This is related to Bug 1121821, but technically should get its own CVE as its another code base ...
https://sintonen.fi/advisories/scp-client-multiple-vulnerabilities.txt describes the vulnerabilities the specific one: 2. CWE-20: scp client missing received object name validation [CVE-2019-6111] Due to the scp implementation being derived from 1983 rcp [1], the server chooses which files/directories are sent to the client. However, scp client only perform cursory validation of the object name returned (only directory traversal attacks are prevented). A malicious scp server can overwrite arbitrary files in the scp client target directory. If recursive operation (-r) is performed, the server can manipulate subdirectories as well (for example overwrite .ssh/authorized_keys).
https://bugzilla.suse.com/show_bug.cgi?id=1121821 for xref, potentially the openssh patch can be used as inspiration?
Hi Marcus, I have been looking at this and verified the 'rcp' tool provided by krb5-appl is vulnerable, as it is the version provided by netkit-rsh (rsh package in SLE12 family). I am attaching the reproducer (patch for krcp.c provided by krb5-appl injecting unwanted files to the client). Originally CVE-2018-20685 and CVE-2019-6111 were reported for OpenSSH. When it turned out netkit-rsh was also vulnerable, Debian requested CVE-2019-7282 (for the one similar to CVE-2018-20685) and CVE-2019-7283 (for the one similar to CVE-2019-6111) for it (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920486). As krb5-appl is also vulnerable, I think new CVEs should be requested. I am attaching the patches for krb5-appl, they should work also for netkit-rsh (maintained by Adam Majer). And I think Debian is still vulnerable because their patch is incomplete, OpenSSH seems to resolve the filename to an absolute path but netkit-rsh doesn't, so restrict_pattern is always NULL and the check is not performed. I will comment in their bug and propose our patches. Is there any problem with it?
Created attachment 844982 [details] Reproducer Patch for the rcp version provided by krb5-appl injecting unwanted files to the client.
Created attachment 844983 [details] Patch for CVE-2018-20685
Created attachment 844984 [details] Patch for CVE-2019-6111
if krb5-appl has the same code as another origin we could argue that we can use the old CVE. otherwise we can request a new CVE can it be traced back to other code pieces?
(In reply to Marcus Meissner from comment #12) > if krb5-appl has the same code as another origin we could argue that we can > use the old CVE. > > otherwise we can request a new CVE > > can it be traced back to other code pieces? Unfortunately the rcp tool in krb5-appl (krcp.c) is the kerberized version derived from BSD's netkit rcp.c, it is not the same code base.
(In reply to Samuel Cabrero from comment #13) > (In reply to Marcus Meissner from comment #12) > > if krb5-appl has the same code as another origin we could argue that we can > > use the old CVE. > > > > otherwise we can request a new CVE > > > > can it be traced back to other code pieces? > > Unfortunately the rcp tool in krb5-appl (krcp.c) is the kerberized version > derived from BSD's netkit rcp.c, it is not the same code base. Marcus, do we finally need new CVE numbers?
I have now filed 2 CVE requests. I asked for MERGE/SPLIT guidance (e.g. if we should better reuse the netkit-rsh or ssh CVEs), lets see. I *think* it might need new CVEs.
the krb5-appl suite was moved out of main krb5 before 1.8. krb5-appl stopped at version 1.0.3 in 2012.
Mitre assigned: > [Suggested description] > 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. > NOTE: MIT krb5-appl is not supported upstream but is shipped by a few Linux distributions. > The affected code was removed from the supported MIT Kerberos 5 (aka krb5) product many years ago, at version 1.8. > > ------------------------------------------ => CVE-2019-25017. > [Suggested description] > 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. > NOTE: MIT krb5-appl is not supported upstream but is shipped by a few Linux distributions. > The affected code was removed from the supported MIT Kerberos 5 (aka krb5) product many years ago, at version 1.8. => Use CVE-2019-25018.
SUSE-SU-2021:0527-1: An update that fixes two vulnerabilities is now available. Category: security (important) Bug References: 1131109 CVE References: CVE-2019-25017,CVE-2019-25018 JIRA References: Sources used: SUSE OpenStack Cloud Crowbar 9 (src): krb5-appl-1.0.3-3.6.1 SUSE OpenStack Cloud Crowbar 8 (src): krb5-appl-1.0.3-3.6.1 SUSE OpenStack Cloud 9 (src): krb5-appl-1.0.3-3.6.1 SUSE OpenStack Cloud 8 (src): krb5-appl-1.0.3-3.6.1 SUSE OpenStack Cloud 7 (src): krb5-appl-1.0.3-3.6.1 SUSE Linux Enterprise Server for SAP 12-SP4 (src): krb5-appl-1.0.3-3.6.1 SUSE Linux Enterprise Server for SAP 12-SP3 (src): krb5-appl-1.0.3-3.6.1 SUSE Linux Enterprise Server for SAP 12-SP2 (src): krb5-appl-1.0.3-3.6.1 SUSE Linux Enterprise Server 12-SP5 (src): krb5-appl-1.0.3-3.6.1 SUSE Linux Enterprise Server 12-SP4-LTSS (src): krb5-appl-1.0.3-3.6.1 SUSE Linux Enterprise Server 12-SP3-LTSS (src): krb5-appl-1.0.3-3.6.1 SUSE Linux Enterprise Server 12-SP3-BCL (src): krb5-appl-1.0.3-3.6.1 SUSE Linux Enterprise Server 12-SP2-LTSS (src): krb5-appl-1.0.3-3.6.1 SUSE Linux Enterprise Server 12-SP2-BCL (src): krb5-appl-1.0.3-3.6.1 HPE Helion Openstack 8 (src): krb5-appl-1.0.3-3.6.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.
Reassigned to security team to close it.
All done, closing.