September 13th, 2024

Zero-Click Calendar invite – Critical zero-click vulnerability chain in macOS

A zero-click vulnerability in macOS, identified as CVE-2022–46723, allows attackers to manipulate Calendar files and access iCloud Photos. Apple has released updates to address these issues from 2022 to 2023.

Read original articleLink Icon
FrustrationSkepticismConcern
Zero-Click Calendar invite – Critical zero-click vulnerability chain in macOS

A critical zero-click vulnerability chain in macOS was discovered by Mikko Kenttälä, allowing attackers to manipulate files within the Calendar sandbox environment. This vulnerability, identified as CVE-2022–46723, enables malicious calendar invites to be sent, which can lead to arbitrary file writes and deletions. The exploit can be leveraged to execute remote code, particularly during macOS upgrades, by injecting files that trigger malicious actions without user interaction. The final phase of the exploit allows access to sensitive iCloud Photos data by altering the configuration of the Photos application, bypassing security measures. Apple has addressed these vulnerabilities through various updates from October 2022 to September 2023, including fixes for the Calendar and Photos vulnerabilities. The timeline of the discovery and subsequent fixes highlights the ongoing efforts to secure macOS against such exploits.

- A zero-click vulnerability in macOS allows attackers to manipulate Calendar files.

- The exploit can lead to remote code execution and unauthorized access to iCloud Photos.

- Apple has released multiple updates to fix these vulnerabilities between 2022 and 2023.

- The vulnerability was reported as CVE-2022–46723 and involved a series of complex exploit phases.

- Ongoing security measures are necessary to protect users from such vulnerabilities.

AI: What people are saying
The comments on the zero-click vulnerability in macOS reveal several key concerns and discussions among users.
  • Many commenters express frustration over Apple's handling of bounty payouts for reported vulnerabilities, questioning the company's commitment to rewarding legitimate security research.
  • There is confusion and concern regarding the exploit's mechanics, particularly how it allows unauthorized access to user files and the inconsistent protection of relocated photo libraries.
  • Some users reflect on the nature of the exploit, noting its old-fashioned approach and the implications of directory traversal attacks.
  • Several comments highlight the importance of timely updates and patches from Apple, emphasizing user privacy and security.
  • There is a call for more accountability from Apple, with suggestions that the company should be more transparent and responsive to security researchers.
Link Icon 18 comments
By @kccqzy - 4 months
Thankfully I don't use iCloud Photo Library, but it's both weird to learn that when the photo library location has been changed, the new location does not get any protection. I would have expected the exploit to fail after setting /var/tmp/mypictures/Syndication.photoslibrary as the system photo library and opening Photos because the Photos app should know to protect this directory.

I just did a quick test on my Sonoma 14.6.1 system. Hold the Option key while opening Photos to create a new photo library in ~/Pictures; then use an app without full disk access permission and without photo permission to access that folder. That app was denied access. Then do the same except the new photo library is created in /tmp. That same app is allowed access. This behavior is baffling and inconsistent.

If Apple really intends to support the feature of allowing the user to relocate their photo library to anywhere on the file system, they need to apply the protection properly.

By @tptacek - 4 months
Lots of comments on this thread about bounty payouts. If a tech giant with a standing bounty program isn't paying a bounty, the odds are very strong that there's a good reason for that. All of the incentives for these programs are to award bounties to legitimate submissions. This is a rare case where incentives actually align pretty nicely: companies stand up bounty programs to incentivize specific kinds of research; not paying out legitimate bounties works against that goal. Nobody on the vendor side is spending their own money. The sums involved are not meaningful to the company. Generally, the team members running the program are actually incentivized to pay out more bounties, not less.
By @cyrnel - 4 months
Ah another way to mess with the quarantine flags, the other being: https://imlzq.com/apple/macos/2024/08/24/Unveiling-Mac-Secur...

Seems just way too many different systems have the ability to modify those flags.

By @autoexec - 4 months
> An attacker can send malicious calendar invites to the victim that include file attachments...Before fixes were done, I was able to send malicious calendar invitations to any Apple iCloud user and steal their iCloud Photos without any user interaction.

What's the scope of this? Can anyone on macOS anywhere really just send random invites to anyone else who uses icloud? Who would even want that?

By @yard2010 - 4 months
> If the attacker-specified file already exists, then the specified file will be saved with the name “PoC.txt-2”. However, if the event/attachment sent by the attacker is later deleted the file with the original name (PoC.txt) will be removed. This vulnerability can be used to remove existing files from the filesystem (inside the filesystem “sandbox”).

That's bad engineering.

By @vessenes - 4 months
Don’t love the bounty state here — security researchers, is it typical to wait this long with Apple or other FAANG type companies?
By @paperplatter - 4 months
Step 1 is a crazy vulnerability on its own. How did Apple not consider this?

> The attacker can exploit this to conduct a successful directory traversal attack by setting an arbitrary path to a file in the ATTACH section with: “FILENAME=../../../PoC.txt”.

By @0xbadcafebee - 4 months
I get a thrill every time there's a big-time non-memory-safety security hole. I know it's petty, but I love the idea of all the time and energy invested in Rust being eventually wasted by a path traversal bug.
By @whitepoplar - 4 months
Does Lockdown Mode prevent this?
By @ChrisMarshallNY - 4 months
Wow. That's a fairly old-fashioned exploit. I remember reading about paths in filenames, like, a decade ago.
By @rvz - 4 months
Great write up.

Any guess on the bounty amount for this zero-click vulnerability, with a 5 step exploit chain for macOS?

By @languagehacker - 4 months
Super interesting, though I doubt they'll pay a bounty on something they've already fixed.
By @rs_rs_rs_rs_rs - 4 months
Come on Apple, do the right thing, reward the bounty already.
By @yieldcrv - 4 months
Should have sold it to the Israelis

NSO Group would have paid more, quicker

By @post_break - 4 months
And yet Apple still hasn't paid up. Need to just start selling these to people who will use them at this point.
By @yrcyrc - 4 months
Apple still not paying bounty or needs to be publicly reminded…
By @AzzyHN - 4 months
It sure is a good thing that Apple has fixed all these, and has put out patches for all effected versions, since they care about their users' privacy, right? Right?

I know Apple has now switched to 10 years for MacOS, and 7ish years of iOS, but I hope the EU passes some laws to make this a requirement, rather than something a company can choose to provide or not.