13 ms·
Zero-Click Calendar invite vulnerability chain in macOS
- rvz 2y agoGreat write up. Any guess on the bounty amount for this zero-click vulnerability, with a 5 step exploit chain for macOS?
- _lvbh 2y agoHas 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.
- edm0nd 2y agoDude likely could have sold this to malicious threat actors for 6 figures. 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.
- deleted 2y ago[deleted]
- yrcyrc 2y agoApple still not paying bounty or needs to be publicly reminded…
- deleted 2y ago[deleted]
- cyrnel 2y agoAh another way to mess with the quarantine flags, the other being: https://imlzq.com/apple/macos/2024/08/24/Unveiling-Mac-Security-A-Comprehensive-Exploration-of-TCC-Sandboxing-and-App-Data-TCC.html#28-cve-2023-42947-creating-an-app-folder-without-the-quarantine-attribute 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.
- languagehacker 2y agoSuper interesting, though I doubt they'll pay a bounty on something they've already fixed.
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- ziddoap 2y ago>though I doubt they'll pay a bounty on something they've already fixed. 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.
- sgt 2y agoSo he likely got the bounty, then, or will get it. Any idea how much it is?
- ziddoap 2y agoDefinitely not received yet. >2024–09–12: Still no bounty [...]. Apples bounty payouts are ball-parked here: https://security.apple.com/bounty/categories/ https://security.apple.com/bounty/categories/
- hypeatei 2y agoRelevant section states: > Zero-click unauthorized access to sensitive data $5,000 to $500,000
- 0cf8612b2e1e 2y ago$5?!? Really incentivizing selling it on the black market.
- whitepoplar 2y agoDoes Lockdown Mode prevent this?
- captainkrtek 2y agoTotally 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.
- saagarjha 2y agoYou can't treat "all files" like that. This would be akin to the "why don't they just make all the file handling out of Lockdown mode code" ;)
- vessenes 2y agoDon’t love the bounty state here — security researchers, is it typical to wait this long with Apple or other FAANG type companies?
- tptacek 2y agoVery yes.
- factormeta 2y agoseems 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?
- tptacek 2y agoIt does not. Bounties and zero-day markets are different things. Lots of people actively sell to both.
- fsflover 2y agoAnd you think this is fine?
- autoexec 2y ago> 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?
- s_dev 2y agoNot to be smart -- but how else would invites work?
- autoexec 2y agoI'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?
- bongodongobob 2y agoBecause you work with people outside of your company, support, vendors, sales people etc. 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.
- fbrchps 2y agoOr the much more sensible, and MSFT way of handling it (in outlook) 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
- autoexec 2y ago> Because you work with people outside of your company, support, vendors, sales people etc. 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!
- rs_rs_rs_rs_rs 2y agoCome on Apple, do the right thing, reward the bounty already.
- post_break 2y agoAnd yet Apple still hasn't paid up. Need to just start selling these to people who will use them at this point.
- tptacek 2y agoGood luck with that.
- AzzyHN 2y agoIt 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.
- anamexis 2y agoYes? As the OP states: 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)
- Avamander 2y agoApple can increase those times because that's how long it'll take them to patch issues like these.
- astrange 2y agohttps://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act https://digital-strategy.ec.europa.eu/en/policies/cyber-resi... 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.
- tptacek 2y agoLots 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.
- fulafel 2y agoI'm betting Hanlon's razor (= incompetence) helps with divining the reasons of the tech giant in question here.
- saghm 2y agoUnless the implication is that the author of this point is misrepresenting things, I'm struggling to think of what "very good reason" there could be when there's a clear record of someone reporting a bug well before it's fixed. At best, it seems like typical slow bureaucracy, which I don't think is a particularly good reason. There's no reason it should take over a year for someone to approve something like this if the company actually incentivized it. Your logic might be sound, but it's hard for me to look at a situation like this and think "company is either stingy or overly bureaucratic like companies overwhelmingly tend to be in almost every other circumstance" is less likely than "company has legitimate reason not to pay out a bounty that ostensibly has been fulfilled". It just seems way more plausible that the incentives that happen pretty much everywhere else have bled into this domain, assuming the author is accurately describing the events.
- tptacek 2y agoVulnerability researchers misapprehend the dynamics of bug bounty programs all. the. time. and are virtually never doing that in bad faith. I don't need to determine which of these two entities are above board; I presume they both are. If you think that any major vendor bug bounty has incentives to stiff researchers, I'm commenting to tell you that's a strong sign you should dig deeper into the dynamics of bounty programs. They do not have those incentives.
- kccqzy 2y agoThankfully 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.
- 1oooqooq 2y agoLinux now you can trivially isolate everything better than osx. Even without apparmor or firejail, most services gets their private tmp by default.
- SoftTalker 2y agoI 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.
- sulandor 2y agomkdir -m 700 /tmp/myprivatedir you're welcome
- saagarjha 2y agoTCC has historically always been kind of weird and full of holes in this way.
- yieldcrv 2y agoShould have sold it to the Israelis NSO Group would have paid more, quicker
- tptacek 2y agoNo they would not have.
- dadrian 2y agoIt'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.
- vlovich123 2y ago> 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.
- tptacek 2y agoThe 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).
- yard2010 2y ago> 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.
- ChrisMarshallNY 2y agoWow. That's a fairly old-fashioned exploit. I remember reading about paths in filenames, like, a decade ago.
- 0xbadcafebee 2y agoI 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.
- paperplatter 2y agoStep 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”.
- btown 2y agoI 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?
- 1oooqooq 2y agoEasy, by not firing people left and right.
- tikkabhuna 2y agoStatic code analysis tools that can flag for the use of the insecure function?
- paperplatter 2y agoThere'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