Use-after-free in macOS sharing service
Categories
(Core :: Widget: Cocoa, defect)
Tracking
()
People
(Reporter: jaas, Assigned: jaas)
References
(Regression)
Details
(4 keywords, Whiteboard: [adv-main149+][adv-ESR140.9+])
Attachments
(2 files, 1 obsolete file)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
phab-bot
:
approval-mozilla-esr140+
|
Details | Review |
See the following code in widget/cocoa/nsMacSharingService.mm:
SharingServiceDelegate* shareDelegate =
[[SharingServiceDelegate alloc] initWithActivity:shareActivity];
...
[service setDelegate:shareDelegate];
[shareDelegate release];
The setDelegate: reference is weak:
@property (weak) id<NSSharingServiceDelegate> delegate;
The delegate is allocated, set as the delegate (weak reference), then released. Anything the service does with the delegate will be a UAF.
Attaching the patch here since I don't know if we're supposed to submit potentially security sensitive patches to phabricator.
Updated•5 months ago
|
Comment 2•5 months ago
|
||
You can put the patches in phabricator; in fact you have to for Lando to work. As long as they are associated with a security bug the access to the differential is set to the same as the bug. If you CC people to the differential for access it will get reset to the access on the bug so CC them here in bugzilla instead.
This is a hard code path to actually trigger, it would only happen if you're sharing to the reminder service.
This file hard codes the service name, presumably because it's not part of the macOS SDK.
NSString* const remindersServiceName =
@"com.apple.reminders.RemindersShareExtension";
I can't get this service name to come through, if I share to to reminders on Tahoe 26.3 I see the string com.apple.reminders.sharingextension.
So for the moment I would say this is low severity.
Also, while the patch I posted here would stop the UAF, it's probably worth figuring out if the code path being patched is still functionally correct, or even how to get it to execute, prior to patching this.
I can keep looking into this as I have time, but if someone else wants to do it faster go for it.
Comment 4•5 months ago
|
||
Set release status flags based on info from the regressing bug 1455310
Updated•5 months ago
|
It's probably possible to trigger the problematic code path on older versions of macOS. I don't think it's reasonably possible from macOS 26.
We can fix the functionality in question on macOS 26 by checking for the service name com.apple.reminders.sharingextension in addition to com.apple.reminders.RemindersShareExtension. I'll include this in my next patch.
The patch I just sent to phabricator does three things:
- Fixes the UAF
- Adds some additional defensive null checks
- Fixes reminder sharing on macOS 26, which re-enables the code path that had the UAF
Comment 9•5 months ago
|
||
Updated•5 months ago
|
Comment 10•5 months ago
•
|
||
Can we get a severity rating for this bug? Ideally we would have had that before landing the patch in case it needed to get sec-approval first. Also, an ESR140 cherry-pick will need rebasing around bug 1997022.
Comment 11•5 months ago
|
||
This should not have landed without sec-approval, or a security rating below sec-high.
I guess I'll rate it sec-moderate now, because it sounds like it requires user interaction, and a rather obscure one at that: "it would only happen if you're sharing to the reminder service".
| Assignee | ||
Comment 12•5 months ago
|
||
I see a needinfo request for me, if you're asking my opinion about severity I'm torn between sec-low and sec-moderate. The UAF seems pretty clear cut, but triggering it is not simple. It requires trying to share to the OS reminder service, and that functionality is likely broken on newer versions of macOS because of a different bug in this code such that the UAF code path can't be triggered. On older (likely still supported) versions of macOS the UAF code path probably does work though.
| Comment hidden (off-topic) |
Comment 14•5 months ago
|
||
(In reply to Andrew McCreight [:mccr8] from comment #11)
This should not have landed without sec-approval, or a security rating below sec-high.
I guess I'll rate it sec-moderate now, because it sounds like it requires user interaction, and a rather obscure one at that: "it would only happen if you're sharing to the reminder service".
My apologies, this was my mistake. I was going through a series of bugs/patches that were waiting to be landed earlier today and unfortunately, this was one of them. I did review the landing requirements for security bugs and saw that sec-low and sec-moderate bugs could be landed without sec-approval. Having reviewed the patch I inferred the same as Josh mentioned in comment 12, but since this was not explicit in the bug, I should not have landed the patch anyway. I did remove the reference to UAF from the commit message before landing.
Updated•5 months ago
|
Updated•5 months ago
|
Comment 15•4 months ago
|
||
Please nominate this for ESR140 uplift when you get a chance.
Comment 16•4 months ago
|
||
Original Revision: https://phabricator.services.mozilla.com/D283612
Updated•4 months ago
|
Comment 17•4 months ago
|
||
firefox-esr140 Uplift Approval Request
- User impact if declined/Reason for urgency: Possible UAF on older versions of macOS.
- Code covered by automated testing?: no
- Fix verified in Nightly?: no
- Needs manual QE testing?: no
- Steps to reproduce for manual QE testing:
- Risk associated with taking this patch: medium
- Explanation of risk level: Not well-tested in Nightly.
- String changes made/needed?: None
- Is Android affected?: no
Updated•4 months ago
|
Updated•4 months ago
|
Comment 18•4 months ago
|
||
| uplift | ||
| Assignee | ||
Comment 19•4 months ago
|
||
There is a request for info from me here but I'm not sure what input is needed. Are you asking my opinion about uplifting to ESR 140? If so, I think others are more qualified than me. I'm not sure what the standard criteria are.
Updated•4 months ago
|
Updated•4 months ago
|
Updated•4 days ago
|
Description
•