Content Filter: sourceAppAuditToken empty only for Firefox

Question

Created Nov ’24

Replies 3

Boosts 0

Participants 2

Starting on macOS Sequoia, flows originated in Firefox have an empty sourceAppAuditToken. Other apps contain a valid token.

Background: in order to fetch process info for a certain NEFilterFlow, my content filter extension uses sourceAppAuditToken, audit_token_to_pid() and proc_* (as recommended in #126820). When that fails, we use SecCodeCopyGuestWithAttributes, recommended in some other thread as a better alternative. Both approaches break when the sourceAppAuditToken is empty since they need the pid.

Debugging:

My logging shows audit token is empty for Firefox
Typical logs from com.apple.networkextension also indicate it fails to fetch the same info I'm looking for:

com.apple.networkextension	debug	11:22:07.024588-0300	Fetching appInfo from cache for pid: 948 uuid: 5C40B765-C6C9-3641-A822-2BC44D264361 bundle id: (null)
com.apple.networkextension	debug	11:22:07.024657-0300	Calling delegate lookup handler with pid: 948, uuid: 5C40B765-C6C9-3641-A822-2BC44D264361, bundleID: (null)
com.apple.networkextension	debug	11:22:07.025856-0300	Could not look up appInfo for pid: 948 bundle id: (null) uuid: 5C40B765-C6C9-3641-A822-2BC44D264361
com.apple.networkextension	error	11:22:07.025897-0300	Could not find app info, return the original flow without filling in app info

Handling new flow: 
        identifier = D89B5B5D-793C-4940-D992-4E90F2AD1900
        procPID = 953
        eprocPID = 948
        direction = outbound
        inBytes = 0
        outBytes = 0
        signature = {length = 32, bytes = 0x4afeafde b484aa0c c5cb8698 0567343d ... 7cdee33e 135666dd }
        socketID = 19adf2904e92d9
        localEndpoint = 0.0.0.0:0
        remoteEndpoint = 17.33.202.170:443
        protocol = 6
        family = 2
        type = 1
        procUUID = 0C68E603-967E-3643-B225-378BD2A655F7
        eprocUUID = 5C40B765-C6C9-3641-A822-2BC44D264361

Perhaps there's a bug when generating the audit token or could it be something with the Firefox signature?

I double-checked Firefox and it seems fine:

$ codesign --verify --verbose /Applications/Firefox.app
/Applications/Firefox.app: valid on disk
/Applications/Firefox.app: satisfies its Designated Requirement

Not sure if relevant, but codesign with -dv showed different flags in CodeDirectory when compared to chrome:

codesign -dv /Applications/Firefox.app
...
CodeDirectory v=20500 size=863 flags=0x10000(runtime) hashes=18+5
...

Versus chrome

CodeDirectory v=20500 size=1821 flags=0x12a00(kill,restrict,library-validation,runtime) hashes=46+7 location=embedded

Boost

Answer 1

terransw OP

Nov ’24

Update: I haven't figured out reproduction steps. After closing and reopening Firefox, it started producing audit tokens just fine. I proceeded to restart macOS to see if I could trigger the issue again, but now audit token are always present.

Now I'm wondering if this has anything to do with uptime or long-running processes. The issue was present when macOS had over 5 days of uptime.

I'll observe for the next few days, but if anyone has any idea what could the issue be, how to reproduce or anything like it, I'm still interested!

0

Answer 2

DTS Engineer OP

Apple

Nov ’24

Recommended

This is clearly a bug. There should always be an audit token because some process must’ve started the flow. The next time you see this, please trigger a sysdiagnose log as soon as you see it, and then file a bug with that log.

And once your done, I’d appreciate you posting the bug number here, just for the record.

If you’re doing this on a ‘victim’ machine then you should enable additional NE logging via the VPN (Network Extension) for macOS instructions on our Bug Reporting > Profiles and Logs page. If you’re doing this on a real machine, you can enable that extra logging, but please consider the privacy impact.

Not sure if relevant, but codesign with -dv showed different flags in CodeDirectory when compared to chrome:

That’s definitely not relevant. Chrome is opting in to some additional security checks, but Firefox gets most of those anyway because it’s enabled the hardened runtime (shown as runtime in that output).

If you reproduce this and want to poke around, the most likely source of interesting info is launchctl procinfo. For example:

% pgrep Finder
2021
% sudo launchctl procinfo 2021
Password:
program path = /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder

Still, that’s just for your own curiosity. The sysdiagnose log should contain enough for Apple to start an investigation.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

1

Answer 3

terransw OP

Aug ’25

Accepted Answer

(Closing the loop)

I did not observe (and therefore could not reproduce) the issue again after the initial report. Must have been fixed on 15.2 or later.

0