{"id":20850,"date":"2022-12-19T10:01:04","date_gmt":"2022-12-19T18:01:04","guid":{"rendered":"https:\/\/www.palada.net\/index.php\/2022\/12\/19\/news-14583\/"},"modified":"2022-12-19T10:01:04","modified_gmt":"2022-12-19T18:01:04","slug":"news-14583","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2022\/12\/19\/news-14583\/","title":{"rendered":"Gatekeeper\u2019s Achilles heel: Unearthing a macOS vulnerability"},"content":{"rendered":"

Credit to Author: Microsoft Security Threat Intelligence| Date: Mon, 19 Dec 2022 18:00:00 +0000<\/strong><\/p>\n

On July 27, 2022, Microsoft discovered a vulnerability in macOS that can allow attackers to bypass application execution restrictions imposed by Apple\u2019s Gatekeeper security mechanism, designed to ensure only trusted apps run on Mac devices. We developed a proof-of-concept exploit to demonstrate the vulnerability, which we call \u201cAchilles\u201d. Gatekeeper bypasses such as this could be leveraged as a vector for initial access by malware and other threats and could help increase the success rate of malicious campaigns and attacks on macOS.<\/p>\n

After carefully reviewing the implications, we shared the vulnerability with Apple in July 2022 through Coordinated Vulnerability Disclosure<\/a> (CVD) via Microsoft Security Vulnerability Research<\/a> (MSVR). Fixes for the vulnerability, now identified as CVE-2022-42821<\/a>, were quickly released by Apple to all their OS versions. We note that Apple’s Lockdown Mode<\/a>, introduced in macOS Ventura as an optional protection feature for high-risk users that might be personally targeted by a sophisticated cyberattack, is aimed to stop zero-click remote code execution exploits, and therefore does not defend against Achilles. End-users should apply the fix regardless of their Lockdown Mode status. We thank Apple for the collaboration in addressing this issue.<\/p>\n

In this blog post, we share information about Gatekeeper<\/a> and the vulnerability able to bypass it. We also share this research to emphasize the importance of collaboration among researchers and the security community to improve defenses for the larger ecosystem.<\/p>\n

Unlocking the Gatekeeper security mechanism<\/h2>\n

Many macOS infections are the result of users running malware, oftentimes inadvertently. Fake app bundles might masquerade themselves as different apps, like Flash Player, or as a legitimate file, such as using a PDF icon and using the app name \u201cResume\u201d. To combat this highly popular infection vector, Apple has imposed strong security mechanisms. When downloading apps from a browser, like Safari, the browser assigns a special extended attribute to the downloaded file. That attribute is named com.apple.quarantine<\/em> and is later used to enforce policies such as Gatekeeper or certain mitigations that prevent sandbox escapes<\/a>. In recent years, Apple has tightened the security policies even further, and the current Gatekeeper design dictates the following behavior for downloaded apps:<\/p>\n

    \n
  1. If the app is validly signed and notarized, meaning approved by Apple, then a prompt requires the user\u2019s consent before its launched.<\/li>\n
  2. Otherwise, the user is informed that the app cannot be run as it\u2019s untrusted.<\/li>\n<\/ol>\n

    Extended attributes are a filesystem feature supported on common macOS filesystems, like APFS and HFS+, and their main purpose is to save file metadata. Specifically, the com.apple.quarantine<\/em> attribute saves information regarding the source of the downloaded file, as well as data instructing Gatekeeper how to process the file. The attribute format is generally:<\/p>\n

    flag;date;agent_name;UUID<\/pre>\n
    Extended attributes can be viewed or modified with the xattr<\/em><\/a> command line utility.<\/p>\n
    A flag value of \u201c0083\u201d enforces Gatekeeper restrictions on the file, as displayed below:<\/p>\n
    \"Graphical
    Figure 1. A common com.apple.quarantine<\/em> extended attribute value<\/figcaption><\/figure>\n
    \"Graphical
    Figure 2. Gatekeeper blocking an untrusted downloaded file<\/figcaption><\/figure>\n
    Due to its essential role in stopping malware on macOS, Gatekeeper is a helpful and effective security feature. However, considering there have been numerous bypass techniques targeting the security feature in the past, Gatekeeper is not bulletproof. Gaining the ability to bypass Gatekeeper has dire implications as sometimes malware authors leverage those techniques for initial access.<\/p>\n
    Historical overview of Gatekeeper bypasses<\/h2>\n
    Numerous Gatekeeper bypasses have been identified in the past years, some even abused by malware families<\/a> such as Shlayer. When examining Gatekeeper bypasses from recent years, we see two approaches:<\/p>\n
      \n
    1. Misuse the com.apple.quarantine<\/em> extended attribute assignment.<\/li>\n
    2. Find a vulnerability in the components that enforce policy checks on quarantined files.<\/li>\n<\/ol>\n
      Two cases that we don\u2019t consider to constitute a \u201ctrue\u201d Gateway bypass are:<\/p>\n
        \n
      1. Using unsupported filesystems, like a USB mass storage device using FAT32, as these require non-trivial user interaction to run macOS applications.<\/li>\n
      2. MITRE\u2019s definition of \u201cGatekeeper Bypass\u201d (T1553.001<\/a>), which requires code execution to forcefully modify or remove the com.apple.quarantine<\/em> extended attribute.<\/li>\n<\/ol>\n
        Here are some examples of Gatekeeper bypass vulnerabilities discovered over the last several years:<\/p>\n
        \n\n\n\n\n\n\n\n\n\n
        Vulnerability<\/strong><\/td>\nExploits<\/strong><\/td>\nDescription<\/strong><\/td>\n<\/tr>\n
        CVE-2022-22616<\/a><\/strong><\/td>\nAssignment of the quarantine attribute.<\/td>\nGzip files archived in BOM archives are not assigned with the quarantine extended attribute, further detailed here<\/a>.<\/td>\n<\/tr>\n
        CVE-2021-1810<\/a><\/strong><\/td>\nAssignment of the quarantine attribute.<\/td>\nPaths longer than 886 characters were not assigned with extended attributes. Therefore, creating a symbolic link that points to an app that resides in a long path results in a Gatekeeper bypass. Since symbolic links are not assigned with the quarantine attribute, it was possible to completely bypass Gatekeeper, as outlined here<\/a>.<\/td>\n<\/tr>\n
        CVE-2021-30657<\/a><\/strong><\/td>\nComponent(s) that enforce policy checks.<\/td>\nApp bundles with a missing Info.plist<\/em> and a shell script main executable component are treated incorrectly by syspolicyd<\/em>, a component that enforces policy restrictions on apps. Writeups can be found here<\/a> and here<\/a>.<\/td>\n<\/tr>\n
        CVE-2021-30853<\/a><\/strong><\/td>\nComponent(s) that enforce policy checks.<\/td>\nA security bug in the way files with a \u201cShebang<\/em>\u201d (#!) header are interpreted by syspolicyd<\/em> cause it to consider the app bundle to be safe, as detailed here<\/a>.<\/td>\n<\/tr>\n
        CVE-2019-8656<\/a><\/strong><\/td>\nAssignment of the quarantine attribute.<\/td>\nSince symbolic links are not assigned with the quarantine extended attribute, an archive that contains a symbolic link to an app that resides in an external filesystem (NFS) results in a Gatekeeper bypass. Apple fixed the issue by blocking the execution of applications from remote shared locations, documented here<\/a>.<\/td>\n<\/tr>\n
        CVE-2014-8826<\/a><\/strong><\/td>\nComponent(s) that enforce policy checks.<\/td>\nQuarantine attributes are not checked for JAR files, which are run by Java, as summarized here<\/a>.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n
        Metadata persistence over AppleDouble<\/h2>\n
        Intrigued by CVE-2021-1810<\/a>, as listed in the above table, we wondered what mechanism could be leveraged in archives. Considering symbolic links are preserved in archives and aren\u2019t assigned with quarantine attributes\u2014we looked for a mechanism that could persist different kinds of metadata over archives.<\/p>\n
        After some investigation, we discovered a way to persist important file metadata through a mechanism called AppleDouble.<\/p>\n
        Even though extended attributes are common on different filesystems, they might be implemented differently or even not supported, so copying files with their metadata becomes a challenging task. To solve this problem, back in 1994<\/a>, Apple introduced the concept of AppleSingle and AppleDouble formats. In a nutshell, AppleSingle is a binary blob that is added as a part of the original file contents so that there\u2019s only a \u201csingle\u201d file to process, whereas AppleDouble saves the metadata in a different file side-by-side next to the original file, with a \u201c._\u201d prefix.<\/p>\n
        Interestingly, when extracting an archive, macOS processes any attached AppleDouble file and assigns the target file with the appropriate metadata.<\/p>\n
        The AppleDouble binary file format is quite complicated, but the code that parses it can be read in the XNU git repository in the file<\/a> that handles extended attributes, which also includes ASCII-art depiction of the format. To demonstrate the AppleDouble file information, we used the ditto<\/em><\/a> utility as such:<\/p>\n
        \"Graphical
        Figure 3. AppleDouble file created as \u201c._somefile\u201d<\/figcaption><\/figure>\n
        When the file is archived alongside its original file and then extracted by macOS, extended attributes are fully restored, as demonstrated here:<\/p>\n
        \"Graphical
        Figure 4. Using AppleDouble in a zip file to preserve extended attributes<\/figcaption><\/figure>\n
        Using this newfound knowledge, we examined how we could use the AppleDouble mechanism to trick Gatekeeper in some way.<\/p>\n
        Our first approach was to generate many large extended attributes in the AppleDouble format such that there won\u2019t be enough space to assign the com.apple.quarantine<\/em> extended attribute. Interestingly, it doesn\u2019t work\u2014AppleDouble is ignored if the overall size is over 2 GB, and there is no limitation on the number of extended attributes a file could get (besides the size of the disk).<\/p>\n
        Researching further, we decided to examine the source code<\/a> of the unarchiving mechanism. Carefully studying the copyfile_unpack<\/em> implementation, we discovered an option for a special extended attribute named com.apple.acl.text<\/em> (saved in the XATTR_SECURITY_NAME<\/em> constant in the source code), which is used to set arbitrary Access Control Lists.<\/p>\n
        \"Graphical
        Figure 5. The code that allows setting arbitrary Access Control Lists<\/figcaption><\/figure>\n
        Using ACLs for exploitation<\/h2>\n
        Access Control Lists (ACLs) are a mechanism in macOS that further extends the traditional permission model. The traditional permission model saves permission for each file in a file \u201cmode\u201d, which can be changed by using the chmod<\/em><\/a> utility. It enforces permissions on the owning user, owning group, and others in terms of reading (r), writing (w) and launching (x). A file\u2019s mode can be viewed by listing files with the \u201c-l<\/em>\u201d (long) flag:<\/p>\n
        \"Graphical
        Figure 6. Viewing the “hello.sh” file mode, the owner can do anything while others can only read or launch it<\/figcaption><\/figure>\n
        Unlike the traditional permission mechanism, ACLs allow fine-grained permissions to files and directories. Each ACL has one or more Access Control Entries (ACEs) that dictate what each principal can or cannot do, much like firewall rules. Like the file mode, ACLs can be modified with the chmod<\/em> utility and viewed with the ls<\/em> utility. It\u2019s important to note that file access checks are dictated by both ACLs and the traditional permission model mechanisms, as demonstrated by the following example:<\/p>\n
        \"Graphical
        Figure 7. Denying file reads from everyone makes it impossible to read the file despite its mode<\/figcaption><\/figure>\n
        The set of authorizations supported by ACLs is well-documented by Apple in the chmod<\/em> manual, which contain more than the traditional reading, writing, or launching abilities, including:<\/p>\n