-
Notifications
You must be signed in to change notification settings - Fork 921
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug] App tracking protection issue preventing GrapheneOS from shipping multicast leak fix #5051
Comments
Thank you for opening an Issue in our Repository. |
Hey there, thanks for reporting.
Similarly, we also exclude private local IP range (ie. 192.168.0.0 -> 192.168.255.255) from going through the |
I think you've misunderstood what I'm saying. My understanding of the situation has progressed, so I will give you all the information again. GrapheneOS is going to ship fixes for multiple different multicast leaks (refer to links above). Your app has a compatibility issue with one of our fixes, and no other apps have this issue. Unless you get involved and assist me in identifying the issue, I will have to recommend to Graphene that we add an off-by-default compatibility toggle that your users will have to activate in order to use app tracking protection on Graphene. This is bad for your users because many of them won't be aware of the toggle and will assume your app is faulty. They will also not get the benefit of multicast leak protection when using your VPN. We would like to avoid both of these issues. There is a separate but related issue which I am recommending you take very seriously for the sake of your users. In debugging the compatibility issue, I have noticed that your app is doing something very strange and potentially malicious. What is happening is that your app is enumerating the IPv4 address space and spamming huge amounts of UDP packets over The particular change to Android that is causing both the compatibility and spam issue is that we have used iptables to DROP multicast traffic going out over The spam is extremely heavy and consistently takes my local network down. It may be that the compatibility issue is really just that the spam overloads the local router which appears as a connectivity issue. So, we just need to figure out where the code that is generating the spam is, and then we can ship our fix without compromising your app. |
Thanks for the reply. Will try to bring some clarity, please lmk if I miss something
App tracking protection (AppTP) purposely excludes multicast traffic from going out over the tun interface. You can see IP config table in https://github.com/duckduckgo/Android/blob/develop/app-tracking-protection/vpn-impl/src/main/java/com/duckduckgo/mobile/android/vpn/service/VpnRoutes.kt It is the same (same file) for private local IP range (ie. 192.168.0.0 -> 192.168.255.255), ie. we also instruct Android to not route that traffic through the So in principle, your changes in GrapheneOS should not affect AppTP, as we instruct Android to not route any of that traffic through the tun interface.
Can you explain a bit your setup to get those packets? ie. how do you install our app, how do you enable AppTP etc. and how do you log the packets. |
We've identified the issue with your app and have been able to work around it without compromising privacy. We added a rule specifically for your VPN: Please read the comment above that rule that explains the problem. My guess would be that it is related to your app creating 2 tun interfaces when AppTP is enabled. It appears for some reason you're relying on data being immediately available on the first tun.
I assure you all those packets came from your app. |
Thanks for that, appreciate it.
Ah yes, we create a null tunnel (hogs and drops all traffic) while setting up the proper tun interface to avoid apps leaking trackers while we setup the protections.
If what you mean is that packets are sent from our app in a strict sense then yes, we intercept (by means of tun interface) and forward ALL packets from ALL the protected apps (except packets flagged as trackers that are dropped). Closing the issue as it seems resolved. |
The traffic is likely randomly generated, as your app is doing a random enumeration of the IPv4 address space. I am certain that the traffic is generated by your app, and not that it is traffic sent over the tun by another app. If you require proof of this, or need further assistance fixing your poorly-implemented VPN, feel free to reach out and we can discuss my rate. |
Appreciate it. Thanks again! |
Describe the bug
I am working on fixing the upstream Android multicast leaks for GrapheneOS. Our solution is working well, except for a compatibility issue that we are encountering with your app specifically.
The issue is that after we add an iptables rule to DROP all multicast traffic going out over virtual network interfaces (tun interfaces), we get very strange behaviour when enabling app tracking protection. The main issue is that we lose connectivity entirely. A secondary, but also very serious issue, is that your app generates a massive amount of spam out over wlan0 to IP addresses close to and within the multicast address range. An example packet capture:
07:54:04.659396 IP 192.168.1.254.40145 > 239.209.34.115.14658: UDP, length 133
07:54:04.659449 IP 192.168.1.254.34718 > 224.14.133.25.36679: UDP, length 39
07:54:04.659519 IP 192.168.1.254.53789 > 229.99.133.98.9412: UDP, length 35
07:54:04.659648 IP 192.168.1.254.45559 > 227.252.32.107.6473: UDP, length 116
07:54:04.659716 IP 192.168.1.254.56686 > 240.200.84.91.44530: UDP, length 55
07:54:04.659834 IP 192.168.1.254.47087 > 231.7.67.92.24432: UDP, length 200
07:54:04.659864 IP 192.168.1.254.52807 > 255.67.86.48.3335: UDP, length 52
07:54:04.659875 IP 192.168.1.254.54221 > 243.245.38.121.46521: UDP, length 68
07:54:04.659894 IP 192.168.1.254.34298 > 255.222.189.62.33198: UDP, length 70
07:54:04.659958 IP 192.168.1.254.55256 > 236.242.208.65.31138: UDP, length 59
07:54:04.660011 IP 192.168.1.254.49704 > 225.248.160.64.8507: UDP, length 97
Some of these packets are strange and suspicious, such as:
1950 22.865055 192.168.1.251 232.83.57.38 WireGuard 134 Handshake Response, sender=0xA1BEF649, receiver=0xC8670719
2508 25.276994 192.168.1.251 224.207.235.86 KPASSWD 100 Unknown command[Malformed Packet]
2758 26.445040 192.168.1.251 228.185.144.71 QUAKEWORLD 151 Client to Server Game
I have had a look at the source of your app, but can't find what is causing the compatibility issue, or the spam. Are you able to provide some insight into what is happening?
Fixing the multicast leaks is still a work in progress, but the changes relevant to the compatibility issue with your app can be found here GrapheneOS/platform_system_netd#6
Here is some more information about the leaks GrapheneOS/os-issue-tracker#3443
Thanks.
How to Reproduce
Build GrapheneOS from source after manually applying the linked PR patches and enable app tracking protection within the app.
Expected behavior
App tracking protection is enabled without any issues and there is no multicast spam.
Environment
The text was updated successfully, but these errors were encountered: