#25737: Tor Browser's update check bypassed Tor once on macos, because of xpcproxy? --------------------------------------+-------------------------- Reporter: cypherpunks | Owner: tbb-team Type: defect | Status: new Priority: Medium | Milestone: Component: Applications/Tor Browser | Version: Severity: Normal | Resolution: Keywords: | Actual Points: Parent ID: | Points: Reviewer: | Sponsor: --------------------------------------+--------------------------
Comment (by gk): Some discussion from today: {{{ 15:17 < Alex_Gaynor> tjr: Not sure I have a ton to contribute; we definitely use XPC IPC in process startup, but I can't imagine we're doing anything that intentionally causes a network connection. Dunno why an XPC process would need to make it's own network connections at all. I'm not sure I have anything to suggest besides using dtrace/lldb/something to capture the full stacktrace from XPCproxy when it makes the DNS lookup 15:18 <+tjr> Alex_Gaynor: Is there a particular function that does 'XPC IPC'? 15:20 < Alex_Gaynor> tjr: https://searchfox.org/mozilla- central/source/ipc/glue/GeckoChildProcessHost.cpp#823-884 15:23 <+tjr> So everything that goes through a 'MachPortSender' or a 'mach_port_t' is ultimately going through xpcproxy? 15:25 <+tjr> And it seems like xpcproxy is technically capable of making network connections given the right input (even if we don't know what that is) - so it seems like it could be used to bypass that sandbox rule... 15:26 <+tjr> Assuming not "If you're using LittleSnitch as your application firewall, it sometimes logs connections against the wrong process." 15:28 < Alex_Gaynor> tjr: I _think_, I can't say for certain I don't know a ton about xpcproxy }}} -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25737#comment:17> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs