Has to be at least 6 figures. I got $47k on a pretty insignificant flaw with TCC and I would assume this is much more serious. The wait time is crazy though. It took almost a year to get fixed and another 6 months for the bounty to be paid. Then another year for them to even credit me for the CVE.
The fact that security researchers are completely at the mercy of the companies made me choose to do software Eng instead. Much more stable.
Which black market? Who is buying it? The reason they quote such a huge range of prices is that there is a huge range of utility across different exploits, and many of them aren't worth much at all, including some that seem ultra-powerful on the tin.
Keep in mind also that the economics of bug bounties are different than those of the "black market". Bounties quote lower prices because they're offering assured payouts, often with lower exploit proof and enablement requirements. They're not actually apples and oranges.
Totally speculating, but I’d hope so. After all the prior zero-click image attachment related exploits, which I think lockdown mode was built to address, I’d figure all files are treated in that manner.
seems this just encourage researchers to sell zero-day exploits to organize crime and/or alphabet letter agencies. No wonder we have no digital security at all! Big tech don't really care about security or privacy. Why are we even using their stuff?
> 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?
I'd want to whitelist specific people before they could send me a calendar invite. Every other invite request should never reach my device. If I don't even know you, why would I want your invites anyway?
Idk, other members of the third party company get pulled in all the time and might schedule something. I can't imagine using a calendar whitelist or why you'd even want to.
Well, to eliminate a source of spam, reduce exposure to phishing, and prevent vulnerabilities like the one talked about in the article by reducing attack surface.
If someone is going to make some demand for my time, the very least they can do is give me notice outside of my icloud calendar. An email, an IM, a phone call, etc are all very easy and they allow me to make sure it's real before it has any chance to interfere with my schedule. "Hey Boss, this guy says he's our new IT guy and he wants to talk about my network settings" or "Hey $vendor, I just got a call from $rando saying he's our new contact, can you verify that for me before I tell him everything I know about your propriety applications?"
It helps that I like to keep my work devices and my personal devices entirely separate. If someone in the office wants to pull me into a work meeting through outlook, they'll already have to have an account set up on the company's exchange server. Anyone outside of the company I should already have a relationship with or at least a heads up.
The way I understand it now, they attach an invite to an email that you don't even read, but it shows up on your calendar. Is it too much effort to open the attachment yourself? Normally you think twice about opening an attachment from someone you don't know.
How often do you get a calendar invite from a person who you never interacted through email before and don't have in contacts vs the opposite, and actually take the meeting?
I, in UK, book things on Eventbrite, they email you with a calendar invite. Same with other booking systems for events IIRC. You can probably add people to an invitation? Maybe if you can exploit such a system then people would have them in their whitelist in any case?
A little adjacent to your question but relevant enough I think.
HR / Recruiter setting up interviews? The person doing the inviting might be different from previous calls/emails.
Customer meetings I get invited to often come from someone I’ve never dealt with before, but include others who I work with who were responsible for bringing me into it.
I think there's a pretty big gap between "people at my company are allowed to add things to my calendar" and "random stranger anywhere in the world can add things to my calendar".
"others who I work with who were responsible for bringing me into it" sounded to me like people at your company, who I assumed would be able to add you to the meetings. I guess I might have been mistaken
Depends on who is running the meeting. If the customer is hosting, the others I work with will provide my email to the customer so they can add me to the invite.
If the recruiter doesn't ask me first (or I don't agree to a meeting), this is called "spam", and I would be happy for the system to just not allow it.
I have never encountered a situation where recruiter starts immediately with an invite without prior conversation (such invite also blocks the time slot of the sender - it would be stupidly ineffective to do that). It is hypothetical and improbable scenario that is not even worth mentioning here.
It just doesn’t make sense to do it ahead of time in such situations. Email client could simply ask if I trust the email before processing the attachment (and some clients do that). Automated pre-processing of attachments is a general risk that doesn’t apply only to calendar.
I've received Apple Calendar invites containing Chinese characters from individuals I've never heard of. I deleted them, but just receiving them was a bit alarming.
I recently booked a haircut that sent me a calendar invite via email after booking it. I had never interacted with that email before, but I accepted the invite.
Not unrealistic as a consultant. My boss sells me to a project. Then clients might be asked to send me the meeting invite to kick things of. I might not have directly communicated with client at any point at this time.
Pretty often at work. I'm often interacting with client/vendor teams or even new people at the company I work for. Probably a few times a week I'll get an invite from someone I have never exchanged an actual email with. Maybe Teams/other chat messages, maybe exchanged information with one of their colleagues, or talked over the phone.
There are possible safeguards -- only allowing invites if you are on each other's contact lists, for example, or the same domain, or something else. Apple had a big problem with Calendar spam that they have not really fixed.
I think this isn't specific to iCloud, just in general invites are automatically picked up from emails. Calendar invites have long been a source of spam, so I'm not surprised there's also a vulnerability.
I don't understand, how is receiving a calendar invite different from receiving any other email? Does MacOS automatically do something with calendar invites by design?
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.
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.
I kind of get it. /tmp has historically been a world-readable/world-writable location in the directory hierarchy. If you want to save something private, it's not a great choice.
It's unclear that NSO group is interested in gaining access to iCloud accounts or Photos, nor is it clear that this entrypoint is something that would meet the bar or be useful for signals intelligence, since it requires sending a calendar invite and clicking on the attachment.
Bug bounties will pay for any bug. Offensive firms only pay for things that are practical, and they don't pay everything up front---it depends on the lifetime of the exploit. The business model is closer to a subscription or services.
There is no reason to believe NSO group would pay more, and they certainly wouldn't pay quicker.
> since it requires sending a calendar invite and clicking on the attachment.
I thought it was a zero click exploit?
As for being interested in iCloud and photos, is the argument that the people they’re looking to attack are unlikely to use iCloud? Cause otherwise getting photos and potentially email access seems quite valuable.
The bigger thing here I think is that the target platform is macOS. An important detail to internalize about major grey market buyers of vulnerabilities: they tend not to stockpile; every vulnerability they buy they need to maintain, and there's not much benefit to maintaining vulnerabilities you aren't going to use. There is, how should we put this, probably not a whole lot of scarcity in macOS RCE vulnerabilities? It would be wild to learn that a threat actor at NSO's scale doesn't already have macOS (and Windows, and Ubuntu) wired for sound already.
(This stockpiling thing isn't me guessing; it's something I learned pretty recently).
Again I'll say I'm not axiomatically reconstructing the relative values of exploits on different platforms, and observe that this is something you can go research and learn about. No, macOS exploits are not as valuable as iOS exploits.
> 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”).
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.
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”.
I think this speaks to a larger problem that likely exists in every company: certainly someone at Apple had written a library function to do this safely, but how do you enforce that that function is used, rather than reimplemented unsafely from scratch? Especially if code reviewers are also unfamiliar with the library. Are there any modern solutions for this?
There's probably a library function that's so annoying to call that people don't bother. Like you gotta first convert the NSString to an NSPath, acquire your library path using some singleton, then construct NSFileHandle (don't take literally, I haven't used objc/swift in ages).
Edit: and there are actually 4 library functions with subtly different behaviors
92 comments
[ 3.9 ms ] story [ 171 ms ] threadAny guess on the bounty amount for this zero-click vulnerability, with a 5 step exploit chain for macOS?
Weird that it's been 2 years now and Apple still hasn't paid anything.
Really highlights why people might tend to gravitate towards that route instead of going thru the legit bug bounty process.
The fact that security researchers are completely at the mercy of the companies made me choose to do software Eng instead. Much more stable.
Seems just way too many different systems have the ability to modify those flags.
CVE-2022–46723 was reported 2022-08-08 and fixed later on 2022-10-24, which the author of this post was credited by Apple for reporting.
>2024–09–12: Still no bounty [...].
Apples bounty payouts are ball-parked here:
https://security.apple.com/bounty/categories/
> Zero-click unauthorized access to sensitive data $5,000 to $500,000
Keep in mind also that the economics of bug bounties are different than those of the "black market". Bounties quote lower prices because they're offering assured payouts, often with lower exploit proof and enablement requirements. They're not actually apples and oranges.
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?
Boss: Why aren't you in the meeting with our vendor to upgrade our X system?
You: Oh I whitelist all my invites. You see, I am thinking about security and don't want to receive invites from someone I don't know.
Boss: Clear your desk, security will walk you out.
ExternalUser: Hello here is a calendar invite I would like you to attend, please confirm or deny
User: Thank you, now I can verify the request and choose to add this to my calendar or not
If I work with them, I would have them whitelisted. If I've never even heard of them they have no business sending my devices calendar invites.
Boss: Why aren't you working on that project I gave you?
You: Some stranger in Indonesia invited me to a sales meeting instead.
Boss: If I need you to go to a sales meeting with someone from Indonesia I'll tell you to! Clear your desk!
If someone is going to make some demand for my time, the very least they can do is give me notice outside of my icloud calendar. An email, an IM, a phone call, etc are all very easy and they allow me to make sure it's real before it has any chance to interfere with my schedule. "Hey Boss, this guy says he's our new IT guy and he wants to talk about my network settings" or "Hey $vendor, I just got a call from $rando saying he's our new contact, can you verify that for me before I tell him everything I know about your propriety applications?"
It helps that I like to keep my work devices and my personal devices entirely separate. If someone in the office wants to pull me into a work meeting through outlook, they'll already have to have an account set up on the company's exchange server. Anyone outside of the company I should already have a relationship with or at least a heads up.
A little adjacent to your question but relevant enough I think.
Customer meetings I get invited to often come from someone I’ve never dealt with before, but include others who I work with who were responsible for bringing me into it.
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.
2022–08–08: Arbitrary file write and delete in Calendar sandbox reported
2022–10–24: (No CVE) fixed in macOS Monterey 12.6.1 and Ventura 13 (Ventura beta3 was vulnerable)
One thing I think you won't like about this is that it's easier for large commercial vendors to comply than it is for open source projects.
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.
you're welcome
NSO Group would have paid more, quicker
Bug bounties will pay for any bug. Offensive firms only pay for things that are practical, and they don't pay everything up front---it depends on the lifetime of the exploit. The business model is closer to a subscription or services.
There is no reason to believe NSO group would pay more, and they certainly wouldn't pay quicker.
I thought it was a zero click exploit?
As for being interested in iCloud and photos, is the argument that the people they’re looking to attack are unlikely to use iCloud? Cause otherwise getting photos and potentially email access seems quite valuable.
(This stockpiling thing isn't me guessing; it's something I learned pretty recently).
No idea what portion non-western journalists use Macs.
This one didn't.
That mentality is cancerous to society.
That's bad engineering.
> 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”.
Edit: and there are actually 4 library functions with subtly different behaviors