• Cisco Talos has identified eight vulnerabilities in Microsoft applications for the macOS operating system.
• An adversary could exploit these vulnerabilities by injecting malicious libraries into Microsoft's applications to gain their entitlements and user-granted permissions.
• Permissions regulate whether an app can access resources such as the microphone, camera, folders, screen recording, user input and more. So if an adversary were to gain access to these, they could potentially leak sensitive information or, in the worst case, escalate privileges.
• This post also provides an overview of the macOS security model and illustrates how vulnerabilities within macOS applications could be exploited by adversaries to steal app permissions.

Cisco Talos recently conducted an analysis of macOS applications and the exploitability of the platform's permission-based security model, which centers on the Transparency, Consent, and Control (TCC) framework.

We identified eight vulnerabilities in various Microsoft applications for macOS, through which an attacker could bypass the operating system’s permission model by using existing app permissions without prompting the user for any additional verification. If successful, the adversary could gain any privileges already granted to the affected Microsoft applications. For example, the attacker could send emails from the user account without the user noticing, record audio clips, take pictures or record videos without any user interaction. Microsoft considers these issues low risk, and some of their applications, they claim, need to allow loading of unsigned libraries to support plugins and have declined to fix the issues. Here is the list of vulnerabilities Talos discovered with their Talos IDs and corresponding CVEs:

Before delving into the details of our findings, it is crucial to comprehend Apple's macOS permission security model. We will concentrate on the different components associated with the research campaign we executed and use the Microsoft vulnerabilities as a case study.

Understanding Apple's macOS permission security model

The security policy of most operating systems is, by default, based on Discretionary Access Control (DAC). This provides only minimal protection against exploited software or malware that runs with user or root privileges.

Apple's macOS is designed to safeguard users against malicious software and breaches of privacy. Beyond the standard DAC policy, access to certain resources is further secured by TCC, which governs how applications can access sensitive user data and system resources.

Below is an indicative, though not exhaustive, list of the capabilities of the consent-based permission model utilized by macOS.

TCC and data protection

TCC enforces a policy that requires applications to obtain explicit user consent before they can access protected resources such as contacts, calendars, photos and location, ensuring that users maintain direct control over their personal information and the accessibility of their data to applications.

TCC operates in conjunction with entitlements, which are a set of capabilities required for an app's functionality. Developers choose these entitlements from a selection provided by Apple, and although only a subset of all possible entitlements is available for general use, the most powerful ones are reserved exclusively for Apple's own applications and system binaries.

When an application with specific entitlements initially asks for the use of a specific capability, a permission pop-up appears.

The image above shows an example of such a permission prompt: “Malevolent App” would like to access the camera. The user must decide whether to allow camera access or to deny it. This decision is then logged in the TCC database.

Once the user has made their choice, any future camera-related request from the “Malevolent App” will be governed by the recorded decision in the database. This system effectively enables users to control and be informed of the privacy-sensitive actions an application intends to carry out. The necessary user interaction is what enables users to prevent malicious applications from performing sensitive actions such as recording a video or taking pictures.

A user can later verify this permission within the “Privacy & Security” section of the macOS “System Settings.” There, a list of permissions can be found, including Camera, Microphone and Location Services.

For example, following the user's decision regarding the previously mentioned pop-up, the Camera permission category under the “Privacy & Security” settings would show the “Malevolent app” listed among the applications that have been granted camera access. Here, the user also has the option to enable or disable permissions.

Code injection

Apple's macOS includes security measures to guard against code injection, a tactic often employed by malware, in which an attacker seeks to insert malicious code into legitimate processes to access protected resources.

To counter this risk, sandboxing is required for apps distributed through the Mac App Store. Sandboxing is designed to restrict access to resources and data; a sandboxed app can only access the resources it has explicitly requested through entitlements, and access to some of those resources is further protected by a user consent pop-up similar to the one previously shown.

For example, a sandboxed app will prompt the user for camera access only if it has the com.apple.security.device.camera entitlement set to true. If this entitlement is not present, the app won't be allowed camera access, and consequently, the permission pop-up won't even appear.

For a notarized app—a designation indicating that the app has been checked by Apple's automated service for malicious components, even if it is not present in the App Store—it is required to enable hardened runtime.

While the sandbox is designed to limit potential impacts from a resource and data perspective, the hardened runtime is focused on making the application more resistant to exploitation. For instance, it includes by default a series of protections that aim to prevent various classes of attacks, particularly those related to code injection. Under the hardened runtime, applications performing higher-risk actions such as just-in-time (JIT) compilation or loading untrusted libraries must explicitly declare these capabilities through entitlements.

In fact, the hardened runtime enables library validation by default, which restricts the loading of libraries to those signed by the application's developer or Apple. If an application needs to disable this behavior, typically to import plug-ins, the developer must explicitly set the com.apple.security.cs.disable-library-validation entitlement to true.

The sandbox and the hardened runtime features can work together to provide enhanced protection. This approach can sometimes lead to what may appear like duplication of entitlements. For instance, consider a sandboxed application that also utilizes the hardened runtime and needs microphone access; in this case, you'll find two separate entitlements for the microphone – one for the sandbox and another for the hardened runtime:

com.apple.security.device.audio-input
com.apple.security.device.microphone

Library injection

The research campaign conducted is primarily focused on the ability to inject a library and exploit the permissions or entitlements of other applications. Library injection, also known as Dylib Hijacking in the context of macOS, is a technique whereby code is inserted into the running process of an application. macOS counters this threat with features such as hardened runtime, which reduce the likelihood of an attacker executing arbitrary code through the process of another app. However, should an attacker manage to inject a library into the process space of a running application, that library could use all the permissions already granted to the process, effectively operating on behalf of the application itself.

The graphics above illustrate what we have explained. Essentially, the bad actor possesses a set of capabilities on their own. By opening a more privileged app and injecting a malicious library, the bad actor gains the capabilities of the exploited application. The attacker then accesses these new capabilities through the exploited app.

Least privilege principle

Within the context of a sandboxed app or an app with hardened runtime enabled, even simply requesting permission to access one of the “privileged” resources (such as the camera, microphone, or location) requires the app to possess specific entitlements. Many entitlements are linked to resources, indicating the application's intention to use a particular resource.

The following snippet is an example of entitlements from the “Microsoft Teams” application.
These three entitlements authorize the application to request permission to use the camera and the microphone:

[Key] com.apple.security.device.audio-input
[Value]
	[Bool] true
[Key] com.apple.security.device.camera
[Value]
	[Bool] true
[Key] com.apple.security.device.microphone
[Value]
	[Bool] true

Entitlements also facilitate the implementation of the principle of least privilege. Apps are only granted access to the resources that are necessary for their proper function, which reduces the potential impact of a compromised app. This approach narrows the attack surface and limits what an attacker can achieve if they manage to exploit an app. In addition, some entitlements enable various security features by default. If needed, developers must deliberately opt out of these features by adding specific entitlements, as was previously shown with the hardened runtime and the com.apple.security.cs.disable-library-validation entitlement.

The implications of Apple’s permission model

Apple's macOS features a layered security model, including TCC and entitlements, aimed at protecting users' privacy and maintaining system security. TCC manages application access to personal data and system privileges, requiring explicit user approval before granting access.

Despite its strength, the macOS security model isn't foolproof. Elevated permissions given to applications could be hijacked, potentially turning these apps into conduits for unauthorized access to sensitive resources.

The effectiveness of TCC depends on applications responsibly handling the permissions they receive. If a trusted application is compromised, it might be manipulated to abuse its permissions, allowing attackers to perform actions without user knowledge. For instance, if a video chat app with camera and microphone access is exploited, it could be forced to record without alerting the user.

This situation points to a key aspect: macOS trusts applications to self-police their permissions. A failure in this responsibility leads to a breach of the entire permission model, with applications inadvertently acting as proxies for unauthorized actions, circumventing TCC and compromising the system's security model. This highlights the importance for applications to implement robust security measures to avoid becoming vectors for exploitation.

Case study: Microsoft applications for macOS

During our research, we discovered that many of Microsoft's macOS applications employ hardened runtime, a feature that enhances security. However, they also have the com.apple.security.cs.disable-library-validation entitlement active, which can be potentially risky.

Even though hardened runtime guards against library injection attacks and the sandbox secures user data and system resources, a malware might still find ways to exploit certain applications under specific conditions. If successful, this would allow the attacker to assume the application's entitlements and permissions. It's important to note that not all sandboxed applications are equally susceptible. Typically, a combination of specific entitlements or vulnerabilities is required for an app to become a viable attack vector.

The vulnerabilities we're addressing are relevant when an application loads libraries from locations an attacker could potentially manipulate. If the application has the com.apple.security.cs.disable-library-validation entitlement, it allows an attacker to inject any library and run arbitrary code within the compromised application. As a result, the attacker could exploit the application's full set of permissions and entitlements.

The flowchart above, even though not exhaustive, describes a simple schema to check if an app is potentially vulnerable to library injection. Many cases are not caught by this flowchart.

We are going to examine two groups of apps: One that exhibits numerous similarities in terms of their vulnerabilities and another that possesses unique characteristics, partly because two of the apps are helper apps, among other specific features.

The first group is “Microsoft Office apps”:

• Microsoft Word
• Microsoft Outlook
• Microsoft Excel
• Microsoft OneNote
• Microsoft PowerPoint

The second group is “Microsoft Teams apps”:

• Microsoft Teams (work or school) the main app
• Microsoft Teams (work or school) WebView.app
• Microsoft Teams (work or school) com.microsoft.teams2.modulehost.app

For each group, we are going to show why the apps are vulnerable and describe the implications.

Microsoft Office apps

Although the Office apps are distinct from one another, they share a common characteristic: They are all hardened runtime apps that include the following entitlement:

[Key] com.apple.security.cs.disable-library-validation
[Value]
  [Bool] true

This effectively indicates that the security protection provided by the hardened runtime, which guards against the hijacking of dynamically linked libraries, is disabled. As a result, all the office apps permit the loading of unsigned dynamic libraries. This poses a security concern because a malware could exploit the apps' permissions without proper authorization.

For example, consider the entitlements for Microsoft Outlook at the time we reported its vulnerability:

The other Office apps are different, but they all share both the hardened runtime feature and the com.apple.security.cs.disable-library-validation entitlement, which is set to true.

If an attacker manages to inject a malicious library, they could utilize all the entitlements and permissions of the apps.

Typically, the only replaceable libraries are the ones with relative import. Below is a portion of the imports from the Microsoft Outlook app:

$ otool -L "/Applications/Microsoft Outlook.app/Contents/MacOS/Microsoft Outlook"
/Applications/Microsoft Outlook.app/Contents/MacOS/Microsoft Outlook:
        @rpath/OPF.framework/Resources/OPF_Common.dylib (compatibility version 1.0.0, current version 1.0.0)
        @rpath/ADAL4.framework/Versions/A/ADAL4 (compatibility version 0.0.0, current version 0.0.0)
        @rpath/CocoaUI.framework/Versions/A/CocoaUI (compatibility version 0.0.0, current version 0.0.0)
        @rpath/COMBase.framework/Versions/A/COMBase (compatibility version 0.0.0, current version 0.0.0)
        [...]
        @rpath/EditorKit.framework/Versions/A/EditorKit (compatibility version 1.0.0, current version 1.0.0)
        @rpath/EmailRendererKit.framework/Versions/A/EmailRendererKit (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/swift/libswiftAppKit.dylib (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/swift/libswiftFoundation.dylib (compatibility version 1.0.0, current version 1.0.0)

The @rpath entries attempt to use all the paths defined as LC_RPATH in the binary's load commands:

$ otool -l "/Applications/Microsoft Outlook.app/Contents/MacOS/Microsoft Outlook" | grep LC_RPATH -A2
          cmd LC_RPATH
      cmdsize 40
         path @loader_path/../Frameworks (offset 12)

For instance, in the case of Microsoft Outlook, there is only one LC_RPATH that uses @loader_path/../Frameworks. The LC_RPATH specifies the search paths for dynamic libraries and can potentially be:

• @executable_path: This refers to the path containing the executable
• @loader_path: When used in a binary, this behaves the same as @executable_path, but when used in a dynamic library (dylib), it refers to the directory where that library is located.

Therefore, in this case, for an executable, the path is relative to the executable itself. The other Office apps have similar relative imports.

To modify an application, already executed once, located in /Applications, a specific entitlement is required. However, it is possible to circumvent this requirement by copying and modifying the application in another folder, such as /tmp.

Given that there are some relative imports and the entitlement to disable library validation is present, all the Microsoft Office apps are vulnerable to library injection attacks.

All Microsoft Office apps share several common features, but their entitlements differ. This means that the impact of injecting a library into one of the apps varies depending on which specific app is compromised. Generally speaking, if an app has already been granted certain permissions, an attacker exploiting the app could access restricted resources without any further user interaction.

For example:

All apps, except for Outlook, can send an Apple event to Microsoft Outlook to dispatch an email without any user prompt. Essentially, the attacker is capable of sending emails without user interaction.

All apps, except for Excel, have the ability to record audio, some can even access the camera.

The attacker can extract keychain entries belonging to the UBF8T346G9.com.microsoft.identity.universalstorage access group using any of the apps.

Microsoft Teams apps

The Microsoft Teams (for work or school) app is similar to Microsoft Office apps in its vulnerability to library injection. However, what sets it apart is that within the app, there are helper applications that are also susceptible to this vulnerability. Nonetheless, one of these helper applications does not have any relative imported libraries.

Similar to the Microsoft Office suite, these three apps are vulnerable to library injection attacks. This is because, despite having hardened runtime enabled, all three possess the com.apple.security.cs.disable-library-validation entitlement, which is set to true.

Microsoft Teams (work or school)

Microsoft Teams (for work or school), hereafter referred to simply as Teams, has numerous entitlements. The entitlements for the Teams app at the time of this report were as follows:

Similar to other Microsoft Office apps, Teams possesses several entitlements and relative imported libraries. However, the main difference from the other apps is that if a user has installed Teams, it is likely that the app has already been used, which means that camera and microphone permissions have probably already been granted. An attacker capable of injecting a library into Teams would almost certainly be able to access the camera and microphone without triggering any pop-up notifications using Teams as its proxy.

com.microsoft.teams2.modulehost.app

One of the helper apps for Microsoft Teams, previously known as com.microsoft.teams2.modulehost.app, has been renamed to “Microsoft Teams ModuleHost.app” in the latest release. This module had the following entitlements:

This app has multiple relative imports. Although it only has three entitlements, the helper app can utilize some entitlements of the main app. This could potentially enable an attacker to take photos, record audio, exfiltrate data and perform other unauthorized actions.

WebView.app

WebView.app, one of the helper apps for Teams, had the following entitlements at the time we reported the issue:

Similar to the previous helper app, this app had only three entitlements. Despite this, the helper app can still request audio recording permission, as it inherits some entitlements from the main app.

A distinctive feature of this helper app is that it does not use relative imports:

$ otool -L "/Applications/Microsoft Teams (work or school).app/Contents/Helpers/Microsoft Teams WebView.app/Contents/MacOS/Microsoft Teams WebView"
/Applications/Microsoft Teams (work or school).app/Contents/Helpers/Microsoft Teams WebView.app/Contents/MacOS/Microsoft Teams WebView:
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.0.0)

This creates a problem from the perspective of an attacker. Indeed, by following the flowchart above concerning the assessment of whether an app is vulnerable to library injection attacks, we would conclude that it is “Likely not vulnerable.” However, the relative imports used by the app are not the only means to load a library. In fact, the app itself utilizes dlopen with a relative path. This is not revealed in the app's static dependencies. Here is a snippet of the app's code:

void _main(int32_t arg1, int64_t arg2) 
{
    [...]
    uint64_t path_length = 0;
    [...]
    if (__NSGetExecutablePath(0, &path_length) != 0xffffffff)
    {
        [...]
    }
    else
    {
        int64_t new_ptr = wrapper_simil_malloc(((uint64_t)path_length));
        if (__NSGetExecutablePath(new_ptr, &path_length) == 0)
        {
            int64_t likely_executable_path = _dirname(new_ptr);
            char const* const rdi_12;
            if (likely_executable_path == 0)
            {
                _strerror(((uint64_t)*(uint32_t*)___error()));
                rdi_12 = "dirname %s: %s.";
            }
            else
            {
                int64_t executable_path_length = (_strlen(likely_executable_path) + 0x63);
                int64_t edge_framework_path = wrapper_simil_malloc(executable_path_length);
                _snprintf(edge_framework_path, executable_path_length, "%s/%s", likely_executable_path, "../Frameworks/Microsoft Edge Framework.framework/Versions/122.0.2365.103/Microsoft Edge Framework");
                int64_t edge_framework_handler = _dlopen(edge_framework_path, 0x105);
                if (edge_framework_handler != 0)
                {
                    int64_t ChromeMain_func = _dlsym(edge_framework_handler, "ChromeMain");
                    if (ChromeMain_func == 0)
                    {
                        [...]
                    }
                    _exit(ChromeMain_func(((uint64_t)arg1), arg2));
                    /* no return */
                }
                [...]
            }
            [...]
        }
        [...]
    }
    [...]
}

The code above essentially constructs the <WebView executable path>/../Frameworks/Microsoft Edge Framework.framework/Versions/122.0.2365.103/Microsoft Edge Framework path and utilizes dlopen to load the Microsoft Edge Framework library, subsequently calling the ChromeMain function. Since the application is dynamically loading a library, the behavior closely resembles that of loading a library through a relative import, which makes this app vulnerable to library injection.

Conclusions

The macOS security model offers enhanced protection that goes beyond the capabilities of standard DAC policy systems. It notifies users whenever an application attempts to access sensitive data or privacy-related resources. Moreover, macOS includes specific features that prevent dynamic library injection, thereby effectively neutralizing an entire category of vulnerabilities. Although no system is without flaws and new vulnerabilities may arise, this framework plays a significant role in reducing them and heightening user awareness of application behavior.

Our research centered on applications vulnerable to library injection, a scenario enabling a malware to exploit the entitlements and permissions already granted to a vulnerable app.

We used Microsoft apps as a case study. Each of these applications had hardened runtime enabled, together with the com.apple.security.cs.disable-library-validation entitlement. Microsoft considers these issues low risk. Nevertheless, of the eight applications we reported, the following four were updated by Microsoft and no longer possess the com.apple.security.cs.disable-library-validation entitlement and are therefore no longer vulnerable to the scenario we described:

• Microsoft Teams (work or school) the main app
• Microsoft Teams (work or school) WebView.app
• Microsoft Teams (work or school) com.microsoft.teams2.modulehost.app, now renamed Microsoft Teams ModuleHost.app
• Microsoft OneNote

However, the remaining four applications remain vulnerable:

• Microsoft Excel
• Microsoft Outlook
• Microsoft PowerPoint
• Microsoft Word

The vulnerable apps leave the door open for adversaries to exploit all of the apps' entitlements and, without any user prompts, reuse all the permissions already granted to the app, effectively serving as a permission broker for the attacker.

Microsoft appears to use the com.apple.security.cs.disable-library-validation entitlement for certain apps to support some kind of “plug-ins.” According to Apple, this entitlement allows the loading of plug-ins signed by third-party developers. Yet, as far as we know, the only “plug-ins” available to Microsoft's macOS apps are web-based and known as “Office add-ins.”

If this understanding is correct, it raises questions about the necessity of disabling library validation, especially if no additional libraries are expected to be loaded. By using this entitlement, Microsoft is circumventing the safeguards offered by the hardened runtime, potentially exposing its users to unnecessary risks.

It's also important to mention that it’s unclear how to securely handle such plug-ins within macOS' current framework. Notarization of third-party plug-ins is an option, albeit a complex one, and it would require Microsoft or Apple to sign third-party modules after verifying their security.

MacOS could also introduce a user prompt, akin to the resource permissions in TCC, enabling users to decide whether to load a specific third-party plug-in. This would provide a more controlled means of granting access without broadly compromising security.