story
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
Shaming Ivan, the head of SEAR, on Twitter is how people who should get paid bounties, but aren't, make progress.
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.
Thanks for this!
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...
But does that matter to security researchers or the public? No. Apple should fix their bounty program regardless of the reason it's broken.
Ultimately, this blog post is just another example on the already large pile[1][2][3][4][5]
1: https://arstechnica.com/information-technology/2021/09/three...
2: https://mjtsai.com/blog/2021/07/13/more-trouble-with-the-app...
3: https://medium.com/macoclock/apple-security-bounty-a-persona...
4: https://theevilbit.github.io/posts/experiences_with_asb/
5: https://shail-official.medium.com/accessing-apples-internal-...
I'd be rueful about leaving so many holes in my original argument, but I think these are useful conversations to have. Thanks!
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.
This is not from an examination of when bug programs work but when they have very demonstrably not worked in the past.
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.
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.
See the rest of the thread for a further response on this, esp. w/r/t Apple itself.
> The sums involved are not meaningful to the company
Which makes it the more bewildering to see how mishappen the handling is
I was really expecting you to say this doesn't happen, I'm now left wondering why security researcher's are willing to take such risks.
The easiest way to show this would be to give the responsibility of managing the bug bounty to a third party who isn't involved in the business.
Seems just way too many different systems have the ability to modify those flags.
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?
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.
Secretary office admin doing their job?
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.
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
Any guess on the bounty amount for this zero-click vulnerability, with a 5 step exploit chain for macOS?
The fact that security researchers are completely at the mercy of the companies made me choose to do software Eng instead. Much more stable.
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.
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.
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).
This one didn't.
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.
