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.networkextensionalso 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
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"
