close
close

Popular Microsoft Mac Apps Vulnerable to Code Injection Attacks

Posted on by darion

Many Microsoft applications designed specifically for Apple’s macOS operating system are vulnerable to attacks by malicious actors, according to research published by Cisco Talos.

Talos researcher Francesco Benvenuto discovered eight vulnerabilities in widely used Microsoft applications, including Excel, OneNote, Outlook, PowerPoint, Teams, and Word.

If the vulnerabilities were exploited, attackers could leverage Apple’s permissions settings, inject malicious libraries into vulnerable apps, and gain control over their permissions and user privileges.

“Permissions govern whether an app can access resources like the microphone, camera, folders, screen recording, user input, and more. So, if an adversary were to gain access to these, they could potentially expose sensitive information or, in the worst case, escalate privileges,” Benvenuto wrote.

How it works

The scope of the problem depends on how macOS handles third-party app permissions. Typically, operating systems base these policies on discretionary access control (DAC), but this provides very limited protection against vulnerable software or malware running with user or root privileges.

Apple goes even further by securing access to certain resources using a Transparency, Consent and Control (TCC) mechanism that requires apps to obtain explicit human consent before accessing protected things like your microphone, camera, and so on.

This consent mechanism is presented to the user as a pop-up that will be familiar to most Mac owners. This decision is then recorded for future use and can be changed via the device’s privacy and security settings in the future if necessary.

Now, macOS also includes provisions to stop code injection by requiring apps distributed through the App Store to enter a sandbox that limits access to resources that the app explicitly requests via permissions — some of which are further regulated by a pop-up asking for user consent.

For example, as Benvenuto explained, a properly sandboxed app will only ask for camera access if it has the camera permission set to “true.” If that permission isn’t present, it won’t be granted and the user will never see the popup.

Certified apps, meaning those that have been checked by Apple scanners for suspicious components, must also have runtime hardening enabled to make them more resistant to code injection.

These applications, which include all Microsoft applications in the research scope that may require higher risk actions such as loading an untrusted library, must declare this intent through their permissions. In this case, their developers must set the Disable Library Validation permission to true.

All of these features are designed to work together to provide Mac users with increased protection. However, if an attacker manages to inject a malicious code library into the process space of a running application, said library will be able to use all of the permissions that have been granted to it.

Research has shown that Microsoft applications become vulnerable if they load a library that an attacker has taken control of.

Responsible handling

Benvenuto said that for Apple’s model to be truly effective – and safe – it relies on apps managing permissions responsibly.

“macOS trusts apps to manage their own permissions. Failure to do so violates the entire permission model, with apps inadvertently acting as proxies for unauthorized actions, bypassing TCC and violating the system’s security model. This highlights the importance of apps implementing robust security measures to avoid becoming exploitation vectors.”

Benvenuto said Microsoft apps appear to use the library validation permission to support plug-ins, which should mean plug-ins signed by third-party developers, but in this case it seems to only apply to Microsoft’s own Office add-ins. He said this raised further questions about why Microsoft needed to disable library validation in the first place, if no third-party libraries were expected to appear.

“By using this permission, Microsoft is bypassing the protections offered by the hardened runtime, potentially exposing its users to unnecessary risk,” he wrote.

Eight security holes

Issues described by the Cisco Talos team have been assigned the following designations:

  • CVE-2024-39804 in Microsoft PowerPoint;
  • CVE-2024-41138 in Microsoft Teams (work or school) com.microsoft.teams2.modulehost.app;
  • CVE-2024-41145 in the WebView.app helper app in Microsoft Teams (work or school);
  • CVE-2024-41159 in Microsoft OneNote;
  • CVE-2024-41165 in Microsoft Word;
  • CVE-2024-42004 in Microsoft Teams (work or school);
  • CVE-2024-42220 in Microsoft Outlook;
  • And CVE-2024-43106 in Microsoft Excel.

According to Benvenuto, Microsoft has stated that it considers these issues to be low-risk and has allegedly declined to fix some of them because applications need to allow unsigned libraries to be loaded in order to support Office add-ins.

As of this writing, both Teams and OneNote have had the problematic permission removed and are no longer vulnerable to exploitation. The others remain vulnerable.