Comment by jeroenhd
5 days ago
A quite obvious attack mechanism, I'm surprised browsers permitted this in the first place. I can't think of a reason to STUN/TURN to localhost. Aside from localhost, trackers can also use all other IP addresses available to the browser to bind their apps/send traffic to.
Now that the mechanism is known (and widely implemented), one could write an app to notify users about attempted tracking. All you need to do is to open the listed UDP ports and send a notification when UDP traffic comes in.
For shit and giggles I was pondering if it was possible to modify Android to hand out a different, temporary IPv6 address to every app and segment off any other interface that might be exposed just because of shit like this (and use CLAT or some fallback mechanism for IPv4 connectivity). I thought this stuff was just a theoretical problem because it would be silly to be so blatant about tracking, but Facebook proves me wrong once again.
I hope EU regulators take note and start fining the websites that load these trackers without consent, but I suspect they won't have the capacity to do it.
> modify Android to hand out a different, temporary IPv6 address to every app
AFAIK this is on the Android roadmap and one of the key reasons they don't want to support DHCPv6. They want each app to have their own IP.
> hand out a different, temporary IPv6 address to every app and segment off any other interface that might be expose
Yes, but (AFAIK) not out of the box (unless one of the security focused ROMs already supports this). The kernel supports network namespaces and there's plenty of documentation available explaining how to make use of those. However I don't know if typical android ROMs ship with the necessary tooling.
Approximately, you'd just need to patch the logic where zygote changes the PID to also configure and switch to a network namespace.
I've looked into network namespaces a bit but from what I can tell you need to do a lot of manual routing and other weird stuff to actually make IPv6 addresses reachable through them.
In theory all you need to do is have zygote constrain the app further with a network namespaces, and run a CLAT daemon for legacy networks, but in practice I'm not sure if that approach works well with 200 apps that each need their IPs rotated regularly.
Plus, you'd need to reconfigure the sandbox when switching between WiFi/5G/ethernet. Not impossible to overcome, but not the weekend project I'd hoped it would be.
I don't follow? Your system is either routing packets or not. IPv6 vs IPv4 should not be a notable difference here.
I've never tested network namespace scalability on a mobile device but I doubt a few hundred of them should break anything (famous last words).
In the primary namespace you will need to configure some very basic routing. You will also need a solution for assigning IP addresses. That solution needs to be able to rotate IP assignments when the external IP block changes. That's pretty standard DHCP stuff. On a desktop distro doing the equivalent with systemd-networkd is possible out of the box with only a handful of lines in a config file.
Honestly a lot of Docker network setups are much more complicated than this. The difficult part here is not the networking but rather patching the zygote logic and authoring a custom build of android that incorporates the changes.