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.
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.
No, it's because Apple's 'product security' team that investigates and pays out bug bounties is horribly mismanaged and ineffective. It was recently moved from the SWE program office to SEAR (security engineering & arch), and the manager was recently shown the door and went to AirBNB. The team members are mostly new college grads (ICT2's and 3's) who wouldn't pass a coding interview elsewhere in the company, and mostly function as bug triagers. They spend more time going to conferences and hanging out with hackers, than in front of a computer screen working. Their portal of 'open investigations' shows a graph that only goes up (aka they only get more swamped with emails and don't even try to catch up).
Shaming Ivan, the head of SEAR, on Twitter is how people who should get paid bounties, but aren't, make progress.
I have no idea about how well the bounty program at Apple is managed, so, without affirming this, I acknowledge this is another plausible explanation: it's just an understaffed team that needs to get its act together.
The only crusade I'm on is against the idea that companies ruthlessly avoid paying bounties, which is, on information and belief, flatly false, like, the opposite of the truth. I think it's valuable for people to get an intuition for that.
Honestly, Apple is a 3.5 trillion dollar company. If the bug bounty program is understaffed then it's an intentional choice and they should fix it. And I say that as someone who's generally sympathetic to Apple.
I think suspicion of bug bounties even from organizations who would clearly benefit the nost from doing them right are well founded and you are over simplifying the situation.
Every organization includes a mess of situations where the overall best interest of the organization no longer comes through. Groups and individuals don't want to admit mistakes both personal and in wider senses and have alliances, competitions, team and organizational loyalty that twists their behavior.
A lot of organizations know they would benefit from having a proper whistle blower program and then proceed to crucify the first person who uses it.
> the idea that companies ruthlessly avoid paying bounties, which is, on information and belief, flatly false
Eh, it's likely usually true, but I've worked for a company which was attracted to the bounty program idea mainly for the optics and very much did push back on/was very reluctant to pay out on bounties.
And when I say "for the optics" I mean not only for the company being able to boast about having a bounty program but also the executive in question having something for his quarterly report. Having it not be too expensive was definitely part of the deal.
Needless to say this was a terrible company with terrible leadership, but it's a data point...
> Apple historically used to have a deservedly good reputation for this.
Are they? Apple only started their bug bounty program (with monetary rewards) merely 5 years ago, 12 years after first iOS release and well after everyone else. They are not very transparent about bugs and payouts (which is understandable) so I wonder where this good reputation comes from?
(if you count their invitation-only program then it started in 2016, 8 years ago)
Getting paid to fuck off at conferences and hang out with hackers on the company dime instead of staring at a screen in a cubicle all day sounds pretty awesome. Do I detect some jealousy or resentment that you haven't mastered the art of the corporate grift?
Similar problem when if you're an innocent software engineer who introduces a bug, the security people will find it, make up a fancy website and logo for it, go around giving conference talks about it, get bounties (or not), give each other prizes, post on Mastodon about it from their accounts with cool hacker nicknames, presumably go have Vegas orgies, etc. Nobody's doing that for you.
that's the thing though: security teams composed of grizzled talent absolutely benefit from going to conferences. they bring back what they've learned and leverage their new connections to bring more value to the company. so now you've got this industry-wide norm that the security guys are kind of out of pocket and spend a bunch of time at conferences, but they know their shit and protect the infra so it's all good. if it worked at the last X companies $CISO worked for so they're going to be hesitant to drop the hammer on the netsec team networking.
practice of the art of the corporate grift does take a toll on one's soul. Usually only pyscho/sociapath can do master this and do it for a long time without any emotional/mental consequences.
Until we get to the total market dynamics (ie, the idea that "black markets" are an immediate substitute for bounty programs) I don't have a dog in this hunt or any reason to litigate the importance of changing how this particular program is managed. If it can be managed more effectively to the benefit of researchers without breaking internal incentives for the bounty program, I'm all for it.
I'd be rueful about leaving so many holes in my original argument, but I think these are useful conversations to have. Thanks!
Unless 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.
Vulnerability 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.
Other than bad press there's no immediate incentive for the company to avoid stiffing researchers. Bug bounty programs work if the company is vulnerable to bad press and it would actually impact their bottom line.
This is not from an examination of when bug programs work but when they have very demonstrably not worked in the past.
Press is a perfect example of incentive alignment in these programs, since not paying a bounty a researcher believes is deserved is practically a guarantee of an uncharitable blog post.
Which process ensures that the company should actually care in the slightest about an uncharitable blog post or two, especially when its motivations are opaque enough that the lack of payment might be chalked up to "there's a good reason for that"?
If the cost of an uncharitable blog post is less than the cost of paying out the bounty, then a company would still be incentivized to find as many reasons to reject a payout as possible, as long as future reporters still believe they have a good chance of receiving a payout (e.g., if they believe they can sideskirt any rejection reasons).
Have you ever reported security and privacy issues to Apple? I have. In fact, I have more than one incident open with them right now. One of them could be fixed in one line of code with no adverse consequences. It’s been open for two years. Apple’s Security team is either highly disinterested or highly incompetent. I don’t care which, neither is good.
It’s one of the most infuriating and frustrating experiences I ever had in computing. They clearly don’t want you sharing the issue publicly, but just string you along indefinitely. I’m honestly reaching my limit.
I don’t even care about the bounty money, I just want the bugs fixed. I’d give them all the latitude in the world if I thought the matters were taken seriously, but I don’t believe they are.
Not saying any about Apples bug bounty program, i manage my companies bug bounty program and for every good submission we get about 10 from India where they xss themselves in web browser console or similar hard to read texts that lead to nothing.
And now we starting to get a lot of AI generated submitted stuff. Take a lot of effort just sort trough the bullshit to accept the good ones, and then to manage it and fix things within SLA when not critical is very easy it gets pushed very down the backlog, competing with all different kind of request from customers to fix things. Code changes might be a one liner but testing etc can blow up stuff to be a very long process.
There have been many documented cases where tech giants have outright refused to pay out, employing practices like: changing the rules of engagement post-factum, silently banning security researchers from active bounties, escalating good-faith disclosures to law enforcement, extreme pettiness from managers, etc.
> The sums involved are not meaningful to the company
Which makes it the more bewildering to see how mishappen the handling is
Give me an example of a good-faith disclosure escalated to law enforcement? Some examples come to mind, but the ones I'm thinking of won't support your argument.
You are generally not going to be legally liable for things you do in ordinary security research, but you will sure as hell be liable if you do unauthorized serverside research. Apple bounty stories are invariably about clientside work with little to no legal risk.
What I haven't had time to learn more about is when bounties are a such a tiny drop in the bucket for such an enormous number of users and revenue, how is it not a win-win?
> 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?
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.
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.
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.
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.
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.
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.
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".
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'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?
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.
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.
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?
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.
> 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”).
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?
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
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.
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.
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.
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.
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.
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.