Another way to leak traffic on Android has been discovered

Posted by mhitza 17 hours ago

Comments

Comment by brinepot 4 hours ago

'Closed without action' is the tell. A leak that Google knows about and leaves in place isn't a bug anymore, it's a feature they're comfortable with.

Comment by grapheneos 31 minutes ago

[flagged]

Comment by exceptione 8 minutes ago

I am not sure why all your comments are flagged, but here is my response to your other comment:

  > We plan to heavily overhaul the VPN implementation to make most forms of leaks nearly impossible rather than continuing to use the current system prone to it.

Thanks, great to hear. Given the slew of bugs you uncovered it seems the Android implementation has some rough edges. Would `pasta` be helpful to you? It allows you to unshare netns and then pass a user-space network adapter inside. https://passt.top/passt/about/ Podman leverages this one as well in more recent versions.

Comment by exceptione 6 hours ago

This paper goes into much more detail: https://supuk.ch/papers/android-natt-keepalive-vpn-bypass

Comment by exceptione 6 hours ago

  > A proper fix would require changes in the Android system. The researcher who discovered the leak has reported the issue to the Android Vulnerability Reward Program, but according to the researcher the issue was closed without action. This issue is not public, but based on this information we deem it unlikely that Google will do anything about it. GrapheneOS is aware of the issue and are working on a fix.

If the account given by the researcher is correct, we cannot rule out that Google deliberately introduced or wanted to keep the leak in place.

Comment by jjav 6 hours ago

> we cannot rule out that Google deliberately introduced or wanted to keep the leak in place

I'd say a lot stronger than "cannot rule out". Regardless of how it was introduced, if it is now known and the issue was closed without action, they are actively choosing to keep it.

Comment by grapheneos 46 minutes ago

[flagged]

Comment by gib444 4 hours ago

The GrapheneOS team did not respond to an email report either [0]. Does that mean we can draw similar conclusions from the GrapheneOS team? I don't think that would be fair or correct, so why assume malice from Google just based on the (lack of) response to the report?

N.B. I don't disagree there is a possibility of foul play on Google's part, but I think more evidence / better argument is required.

[0] https://github.com/GrapheneOS/os-issue-tracker/issues/8617#i...

Comment by exceptione 4 hours ago

GOS explicitly stated that they work on a fix, also for other issues and they keep this on their radar.

Google just closed the ticket, without communicating their plan to deal with it. I just stated that we cannot rule out a possibility of foul play, thereby keeping other options open. Keeping that thing in mind which is better known as "the reality" I would be a little bit more wary about Google's stance towards privacy than I would be about GOS though. The difference in how these parties are handling this issue is already a tell.

Comment by nvme0n1p1 4 hours ago

There's a big difference between "the issue was closed" and "received no acknowledgment". The former is a deliberate action. The latter could be a case of SMTP-ate-my-email.

Comment by gib444 3 hours ago

Issue could have been closed by a mis-click, an AI bot gone wrong, a misunderstanding of the issue etc. You can't assert it was deliberate unless e.g. you work in the team that handled it and have inside knowledge. Agree GOS should have benefit of the doubt (too)

Comment by kennethkl 2 hours ago

your logic would assert a similar conclusion with this scenario:

a person walks up to you, punches you in the face, and leaves.

it could have been an accident, an AI bot, or a misunderstanding. definitely not deliberate.

Comment by gib444 2 hours ago

Ridiculous analogy.

By your logic, the GOS lack of reply was deliberate too.

Comment by 9 minutes ago

Comment by grapheneos 24 minutes ago

[flagged]

Comment by grapheneos 47 minutes ago

[flagged]

Comment by nonamesleft 6 hours ago

As a quick kludge use an USB-C wlan network adapter that lacks the functionality for this type of connection (albeit that won't help you with a cellular connection)?

Comment by exceptione 6 hours ago

Regarding cellular connection, the proof of concept presented here only works on wifi: https://github.com/GrapheneOS/os-issue-tracker/issues/8617

I have a hunch this leak is bound to wifi hardware only, for details: https://supuk.ch/papers/android-natt-keepalive-vpn-bypass

Comment by aucisson_masque 9 hours ago

> This issue is not public, but based on this information we deem it unlikely that Google will do anything about it. GrapheneOS is aware of the issue and are working on a fix.

Good guy Google, as usual.

Comment by grapheneos 16 minutes ago

[flagged]

Comment by potatoproduct 4 hours ago

Surprised this hasn't blown up more!

Comment by TutleCpt 4 hours ago

Mullvad did a really good job writing up this blog post. And yet again GrapheneOS to the rescue.

Comment by gib444 4 hours ago

I guess the best advice remains to only use wifi to connect to a router which forces traffic over a VPN and never use mobile data?

Do any similar leaks exists on iOS currently?

Comment by xicolo 8 hours ago

[dead]

Comment by arunvpp 17 hours ago

[flagged]

Comment by lsaferite 14 hours ago

I mean, they detailed *exactly* how it works in the very short article.

Comment by gib444 1 hour ago

[flagged]

Comment by tosti 4 hours ago

You're definately not hiding something if all your traffic goes out to a single IP address and a single pair of source and destination ports.

Comment by gib444 2 hours ago

A business: hiding everything is expected. To do otherwise is negligence

An individual: you're a pedo if you use a VPN

Give over.

Comment by tosti 1 hour ago

Most people I know use a VPN do it to bypass geo restrictions and/or get a discount with cheaper currencies. (But hey, our "representatives" seem to disagree.)