MacOS again appeared vulnerability, known as unbreakable system also has weaknesses-vulnerability warning-the black bar safety net

For convenience of expression, this article will use the first-person manner described.
This article describes my in Apple’s macOS system kernel found several stack and buffer overflow vulnerabilities, Apple will this several vulnerabilities categorized as the kernel of remote code execution vulnerabilities, so those vulnerabilities the threat level is very high. An attacker can use these vulnerabilities to remote intrusion Mac, you can also by physical access to the computer, only need to the visitors log in without a password, you can use these loopholes to get permission and control of the computer.
These vulnerabilities are basically present in the NFS Protocol, is used to the network drive mounted to a Mac when the file system is used, similar to NAS.
Vulnerabilities related content
Apple in 2018 7 November 9 release of MacOS 10.13.6 version update fixes these vulnerabilities. But at the time they asked we do not publish these vulnerabilities because they need to do some investigation and see what other platforms have similar problems or whether you need to solve. Of course, now we can open that up.
NFS this thing, now scope of use has been very wide, especially in some large enterprises, it is mainly used for the shared drive or networked device’s main directory. Of course, it can also be in the home equipment, usually used as a media server.
On macos, install the NFS does not require special permissions, so any level of user can trigger these vulnerabilities, and even does not require a password for the visitor account. In addition, many computers especially in an enterprise environment will be configured to start automatically when mount the NFS share.
This means that these vulnerabilities exist at least two attack vectors: the

1. May be used when using NFS, the file Manager of the enterprise in the rapid spread of the virus.
   Want to do this, the attacker need only in its file Manager on the installation with the malicious code of the NFS server software, or by the malicious files Manager put in the network up to intercept NFS traffic to reach the goal.
2. For mention right.
   For example, some people will use the Guest login, and then issue a series of commands to connect to the NFS server may be present in the network any location, it is possible on the computer to obtain kernel-level access.
   Apple is the five vulnerabilities are assigned CVE: CVE-2018-4259, CVE-2018-4286, CVE-2018-4287, CVE-2018-4288 and CVE-2018-4291。 I’m in 2018 5 on 21 September to Apple’s bug reports, respectively, in the source code listed in Article 14 does not determine the point. But since Apple only recently released an update, so I have not had time to complete the full source code audit. Therefore, to avoid accidental disclosure Any may not fix the errors in this article I’ll talk about two of which has been verified and repaired the vulnerability.
   Vulnerability reproduction
   I wrote a PoC to verify the vulnerability of availability, you can use 0 covers 4096 bytes of heap memory causing the kernel to crash. I made a short video to prove it.
   4096 is a random selection, in fact I can feel free to modify to send as much data as possible, and anything greater than 128 bytes the number will trigger a buffer overflow, I was also able to completely control the bytes written value. Therefore, although these actions only destroy the core, but in fact can be achieved through these buffer overflows to achieve remote code execution and local mention of the right of operation.
   When I first found this vulnerability, hardly dare to imagine I will be for the PoC to write your own NFS server. But I have learned a few NFS-related knowledge as well as learn how to use rpcgen, I found that in fact want to achieve is also very simple. To verify this vulnerability with a PoC, contains only 46 lines of C language and Line 63 of the RPC language code. Of course, the source code will be in the official Apple completion of all the repair after the re-release.
   Vulnerability details the
   I write for the PoC, these two vulnerabilities are required by this act seemingly harmless code to achieve:
   nfsm_chain_get_fh(error, &nmrep;, nfsvers, fh);
   This line of code does is to read the NFS server sends back a Mac of the reply message nmrep of file handles fh on. This file handle is the NFS shared file or directory of the opaque identifier. An NFSv3 file handles up to 64 bytes, in NFSv4, up to 128 bytes, MAP of fhandle_t type then there is enough space to accommodate 128 bytes of a file handle, but they neglected to check nfsm_chain_get_fh the macro in a buffer overflow situation:
   /* get the size of and data for a file handle in an mbuf chain /
   #define nfsm_chain_get_fh(E, NMC, VERS, FHP) \
   do { \
   if ((VERS) != NFS_VER2) \
   nfsm_chain_get_32((E), (NMC), (FHP)->fh_len); \
   else \
   (FHP)->fh_len = NFSX_V2FH;\
   nfsm_chain_get_opaque((E), (NMC), (a uint32_t that)(FHP)->fh_len, (FHP)->fh_data);\
   if (E) \
   (FHP)->fh_len = 0;\
   } while (0)
   Since the macro command used in large quantities, want to understand this code may seem difficult, but its actual role is very simple: it can be from the message reads a 32 for the unsigned integer to the(FHP)->fh_len, and then read the bytes from the message directly into the(FHP)->fh_data it. Since there is no bounds checking, so an attacker can select any byte sequence coverage of any number of kernel heap. Is covered by the file handle in memory nfs_socket. c:1401 distribution.
   This PoC, the second bug is nfsm_chain_get_opaque of an integer overflow:
   / copy the next consecutive bytes of opaque data from an mbuf chain /
   #define nfsm_chain_get_opaque(E, NMC, LEN, PTR) \
   do { \
   a uint32_t that rndlen; \
   if (E) break; \
   rndlen = nfsm_rndup(LEN); \
   if ((NMC)->nmc_left >= rndlen) { \
   u_char __tmpptr = (u_char)(NMC)->nmc_ptr; \
   (NMC)->nmc_left -= rndlen; \
   (NMC)->nmc_ptr += rndlen; \
   bcopy(__tmpptr, (PTR), (LEN)); \
   } else { \
   (E) = nfsm_chain_get_opaque_f((NMC), (LEN), (u_char)(PTR)); \
   } \
   } while (0)
   This code uses bfsn_rndup the LEN move 4 to the next multiple. But it is in the call to bcopy will use the LEN of the original value. If its initial value is 0xFFFFFFFF, then nfsm_rndup will appear in the adder overflow, renlen value is 0, which means that capable(NMC)->nmc_left more successful, and the use of 0xFFFFFFFF as the size parameters of the call to bcopy to. This will cause the kernel to crash, and therefore it is used as a denial of service attack.
   Using QL to find the error
   QL is a big advantage to be able to find known bugs variants. Earlier this year, my colleague Jonas Jensen in the Apple NFS start found two vulnerabilities: CVE-2018-4136 and CVE-2018-4160。 We were also publishing an article about the vulnerabilities of the article is mainly devoted to bcopy call, this call may exist for the negative of the user to control the size of the parameters. The easiest way is to find the user control of the source buffer to the bcopy calls. It’s funny, because they can be user’s copy the data to the kernel.

[1] [2] [3] next