Re: [tor-bugs] #25737 [Applications/Tor Browser]: Tor Browser's update check bypassed Tor once on macos, because of xpcproxy?

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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:  tbb-proxy-bypass          |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+--------------------------

Comment (by cypherpunks):

 I'm the OP, someone else is using the cypherpunks account: such as in 1,
 6, 8, 13 and 15. Just to clarify.

 > Yet another reason for using Tails/Subgraph/Whonix.

 Unfortunately we need to work with Macs, using a separate workstation for
 browsing is too uncomfortable. We tried these days and it didn't worked
 out well. But Tor is part of our security posture, in the past we have
 been targeted and suffered a number of minor data breaches.

 > Logs and cache of what? The application firewall?

 The logs and cache of the dns resolver. Which means the process did a DNS
 lookup on that name, around that time.

 We are sure no outgoing connection has ever been made, because the
 firewall and the transparent proxy never logged any attempted bypass. I
 called it an isolating proxy because it inspects the traffic and blocks
 everything, except done for the connections to Apple, the bridge and our
 own IPs, redirecting each kind of traffic on a different route.

 > Oh, another thing that might be interesting the next time is seeing the
 process hierarchy by clicking on the respective LuLu icon on the alert
 window.

 Did this: `launchd` -> `/usr/libexec/xpcproxy`. But I can not remember
 anything more specific than this now.

 > At some point in the past, the default browser proxy preferences were
 modified.

 No preferences were modified: after the bundle installation, I inserted
 the bridge, closed the browser, opened ~/Library/Application Support
 /TorBrowser-Data/Tor/torrc and added `UseBridges 1`. Only usual browsing
 activity from thereon.

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

 > So instructing the user to run "ps -ef|grep xpcproxy" might give us the
 arguments to xpcproxy at the time. Since it's basically a launcher, we
 want to know what it's launching that is doing the https requests.

 Will do it if it happens again.

 > If you're using LittleSnitch as your application firewall, it sometimes
 logs connections against the wrong process.

 Denying the outgoing connection blocked the progress of the launcher and
 the browser window never popped up. So, I find this unlikely. But maybe
 I'm missing something here?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25737#comment:21>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs