ASA-2018-00023 – Apple XNU: Buffer overflows in macOS NFS client


Allele Security Alert

ASA-2018-00023

Identifier(s)

ASA-2018-00023, CVE-2018-4259, CVE-2018-4286, CVE-2018-4287, CVE-2018-4288, CVE-2018-4291

Title

Buffer overflows in macOS NFS client

Vendor(s)

Apple

Product(s)

macOS

Affected version(s)

macOS version 10.13.5 and earlier

Fixed version(s)

macOS 10.13.6

Proof of concept

Unknown

Description

This alert addresses only two among several vulnerabilities fixed by Apple.

The first one is in the macro nfsm_chain_get_fh() and the second is in the macro nfsm_chain_get_opaque().

The macro nfsm_chain_get_fh() doesn’t take the length of the message into account and then copies its contents to a buffer dynamically allocated.

Vulnerable code:

File: bsd/nfs/nfsm_subs.h
---
...
623 #define nfsm_chain_get_fh(E, NMC, VERS, FHP) \
624 do { \
625 if ((VERS) != NFS_VER2) \
626 nfsm_chain_get_32((E), (NMC), (FHP)->fh_len); \
627 else \
628 (FHP)->fh_len = NFSX_V2FH;\
629 nfsm_chain_get_opaque((E), (NMC), (uint32_t)(FHP)->fh_len, (FHP)->fh_data);\
630 if (E) \
631 (FHP)->fh_len = 0;\
632 } while (0)
...
---

The macro nfsm_chain_get_fh() calls nfsm_chain_get_32() to read the length from the message ‘NMC’ and puts it in ‘(FHP)->fh_len’ that is latter used in nfsm_chain_get_opaque() on line 629. It then reads ‘(FHP)->fh_len’ bytes from the message and stores it in ‘(FHP)->fh_data’. Because there’s no validation of the value of ‘(FHP)->fh_len’, it’s allowed to write more bytes than the destination supports. The destination buffer is allocated in nfs_socket.c on line 1401.

The macro nfsm_chain_get_opaque() has an integer overflow. This macro calls nfsm_rndup() macro to round ‘LEN’ up to the next multiple of 4. This allows the result to be overflowed because it doesn’t check against overflows.

Vulnerable code:

File:bsd/nfs/nfsm_subs.h
---
...
597 #define nfsm_chain_get_opaque(E, NMC, LEN, PTR) \
598   do { \
599    uint32_t rndlen; \
600    if (E) break; \
601    rndlen = nfsm_rndup(LEN); \
602    if ((NMC)->nmc_left >= rndlen) { \
603      u_char *__tmpptr = (u_char*)(NMC)->nmc_ptr; \
604      (NMC)->nmc_left -= rndlen; \
605      (NMC)->nmc_ptr += rndlen; \
606      bcopy(__tmpptr, (PTR), (LEN)); \
607    } else { \
608      (E) = nfsm_chain_get_opaque_f((NMC), (LEN), (u_char*)(PTR)); \
609    } \
610  } while (0)
...
---

When nfsm_rndup() tries to round ‘LEN’ up to the next multiple of 4, if ‘LEN’ is a very large value, it will then overflow and the variable ‘rndlen’ might be set to zero. This bypasses the validation on line 602 and because the call to bcopy() uses the value of ‘LEN’ and not ‘rndlen’, the large value set to ‘LEN’ will be used as length to the call to bcopy() on line 606. This result in copying more bytes than the destination supports.

Reference(s)

Semmle Discovers Six Critical Vulnerabilities Affecting Macs, iPhones, and iPads
https://semmle.com/news/apple-xnu-kernel-icmp-nfs-vulnerabilities

Kernel RCE caused by buffer overflows in macOS NFS client (CVE-2018-4259, CVE-2018-4286, CVE-2018-4287, CVE-2018-4288, CVE-2018-4291)
https://lgtm.com/blog/apple_xnu_nfs_vfsops_CVE-2018-4259

APPLE-SA-2018-10-30-2 macOS Mojave 10.14.1, Security Update 2018-001 High Sierra, Security Update 2018-005 Sierra
https://lists.apple.com/archives/security-announce/2018/Oct/msg00003.html

CVE-2018-4259
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-4259

CVE-2018-4259
https://nvd.nist.gov/vuln/detail/CVE-2018-4259

CVE-2018-4286
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-4286

CVE-2018-4286
https://nvd.nist.gov/vuln/detail/CVE-2018-4286

CVE-2018-4287
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-4287

CVE-2018-4287
https://nvd.nist.gov/vuln/detail/CVE-2018-4287

CVE-2018-4288
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-4288

CVE-2018-4288
https://nvd.nist.gov/vuln/detail/CVE-2018-4288

CVE-2018-4291
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-4291

CVE-2018-4291
https://nvd.nist.gov/vuln/detail/CVE-2018-4291

If there is any error in this alert or you wish a comprehensive analysis, let us know.

Last modified: February 11, 2019

We are not responsible for any data loss, device corruption or any other type of issue due to the use of any information mentioned in our security alerts.