DNS traffic can leak outside the VPN tunnel on Android
mullvad.net
mullvad.net
However I'm worried that their goodwill and values will become more valuable to some private equity corp that buys them to asset strip and squeeze their customers.
Not everyone's in it for the money. Assuming they're not operating at a loss, even less so.
In some lines of business, like (purely hypothetically) security, it might actually be a bad thing for your business if you do.
I also use mullvad because I don't really think this is the case, but bad actors are generally hard to conclusively identify by design. And VPNs are pretty far out in the "just trust me bro" realm of handing over all your browsing habits with no ability to check their real behavior.
This is so very, very, far away from the typical VPN company that any such comparison sounds ridiculous to me.
Just the pretense of doing all this work costs so much that a greedy biz bro simply wouldn't.
https://github.com/mullvad/system-transparency
- https://www.sigsum.org (a transparency log with witness cosigning)
- https://tillitis.se (an open-source hardware FPGA-based security key with measured boot)
On the other hand, if it were an NSA honeypot, doing all that work would easily be worth the cost. Personally, I don't think they are, so I'm merely pointing out that there are angles other than totally above-board honest legitimate reasons, and "greedy biz bro".
Yes. It is quite an interesting situation, really. It's also a fun challenge! To what extent can we prove that we are trustworthy, and using what tools? Do those tools exist or do we have to invent them?
https://github.com/menonsamir/spiral-rs claims to have implemented this at a level that's practical for real world applications, with a demo for a wikipedia server, but it's far too slow, as demoed, for use as DNS server.
Now, the fact of the matter is that you can map my account ID back to the IP I'm connecting from, but with very limited way to map from my IP to my identity protects that in many ways, but data-mining at scale, knowing how many users connecting to one proxy server from city X, would be worth something to advertising and related companies who are more interested in large habits of users. If it turns out no one uses the pirate bay anymore, but use torrent site XYZ, I know where I'd place my advertising dollars for, say, a VPN product.
This is on the extreme end, but you asked for a fun challenge! :)
I should've been more clear. The questions I posed above are rhetorical. I've spent well over half a decade obsessing over them. See my mention of System Transparency, Sigsum and Tillitis elsewhere in this thread.
At best you have stuff like attestation... but we all know those have a long history of being flawed and are subject to loads of side channels that can't be attested against. Plus VPNs are such a honeypot in every conceivable way that TONS of state-actor-level efforts are entirely reasonable, and that could easily include cheating on basically all attestation systems imaginable. We're just kinda stuck trusting history and lack of public leaks / correlated actions / whistleblowers IMO.
Or, frankly, the Mozilla partnering counts for a lot to me. I won't use their setup because it doesn't have non-vpn-app options, but they're a group I mostly trust to have people's safety at heart.
Personally, stuff like Tor (where by construction you only need to touch a couple good actors to be reasonably secure, and anyone can contribute) is about the only mostly-actually-trustworthy kind of system. You can expect malicious actors to participate there, and still have a reasonable level of privacy, particularly if you check a few personally (which is feasible because anyone can contribute). Tor and similar have plenty of issues, but structurally they're much more sound by design than any centralized VPN can ever be. Now if only they were even a tiny fraction as usable...
https://mullvad.net/en/help/policy-reviews-advertising-and-a...
On the other hand the campaign we did in Stockholm last year worked out quite well. It managed to affect both domestic and EU legislative discussions at the time. Or at least our campaign contributed to moving the discussion in the right direction.
How much is that worth? I'm not sure, but the reason we started Mullvad in the first place was to conduct political action through entrepreneurship, specifically regarding mass surveillance and censorship.
If nothing else it seems to amuse a lot of people, including me and my colleagues. When I first heard of the idea of plastering privacy propaganda all over some major U.S. cities my initial reaction was more or less "lol, we can just do that?". As it turns out we can. :)
transparency is absolutely a corporate virtue.
I can't speak for my marketing colleagues but I would assume they reason about it. It seems like a complex system to me, which means the approach kind of has to be (1) forming an understanding of the system and (2) deciding whether one is comfortable with the uncertainty.
One aspect that makes the cost/benefit assessment quite a bit easier is that we don't only care about how many new paying customers we get. It's also fun to do this kind of advertisement. How many interesting conversations about privacy have been had as a result of people seeing our billboards? That's worth something too.
Rather a neat subversion of the common corporate use of remote attestation, to preserve user privacy and security rather than curtail it.
Two years ago we moved the OSS projects System Transparency and Sigsum to its own organization: Glasklar Teknik AB (glasklarteknik.se).
The OSS and OSHW project TKey was moved to Mullvad's other sister company Tillitis AB (tillitis.se)
The ads are great to see in NYC subway and giant billboard near NY Times HQ.
Is there an online page with all of the ads? Maybe a video tour of the ads "in the wild" in different cities?
(Seeing the reply down thread from a Mullvad rep, this is not unexpected)
> Imagine an ad that won’t track you after you see it
> Mullvad VPN
That’s not what a VPN does though. Tunneling my browsing does not stop sites from serving ads, setting cookies, fingerprinting browsers, etc.
Mullvad itself is extremely clear that use of a VPN alone is not enough for the reasons you stated. Mullvad VPN (which is what they advertised) is a suite of products and services, some of which are:
- DNS services (ads, tracking)
- A privacy-optimized browser (cookies, fingerprinting)
- Network services like multihop routing (many benefits such as resistance to timing attacks)
All of these services are included with your subscription at no additional cost. I feel like the claim of preventing ad tracking is as legitimate as it could possibly be.
They’ve made some claims that are downright lies, I chuckle at the idea anyone would trust them.
The NYC subway ads state that they save you from online web ad systems; blatantly false.
I’ll take a photo next time I see the ad to store away.
Which claims are you referring to?
> The NYC subway ads state that they save you from online web ad systems; blatantly false.
> The NYC subway ads state that they save you from online web ad systems; blatantly false.
While it's true they've not always offered this, it's on you when making such claims to ensure you're still factual.
Please show me evidence to back this up and I’ll happily walk back my statements.
The “mullvad” browser is not their VPN product. And if you think DNS denylisting prevents “ad networks from spying on you”, I have some unfortunate news for you. It works to prevent the rendering of a subset of ads (especially in the browser), but isn’t worth a damn for actual behavioral analysis.
"How to set up ad blocking in our app"
Dated May 27, 2021
I would guess it started with something like this: they serve DNS to prevent DNS leaks when using the VPN. They realize they can use this to block domains, just like a pihole or Cloudflare DNS. They integrate that into their VPN offering.
It's pretty logical once you think about it, but it was a surprise to me too.
The paragraph above is clearly visible on our landing page. We don't want people using our service for things it's not designed for.
The paragraph below is also a direct quote from our website.
"When you visit a website, you can be identified and tracked through your IP address, third-party cookies, all kinds of tracking scripts, and through so called browser fingerprints. That’s why masking your IP address is not enough to stop the data collection. However, by using a trustworthy VPN in combination with a privacy-focused browser, you can put up a better resistance against the mass surveillance of today. That's why we partnered with the Tor Project to develop Mullvad Browser – a browser designed to minimize tracking and fingerprints."
I don't know if it's easily configurable in the app, though.
I just discovered it by accident the other day.
It's super easy.
See "DNS content blockers" at https://mullvad.net/de/help/using-mullvad-vpn-on-android#vpn...
Some of the ads also felt deceptive making it seem like it will prevent all your online tracking, even though we know that’s not the case.
I'm sorry to hear that. For what it's worth our marketing colleagues make a big effort to minimize the risk of such interpretations. Sometimes a really snappy string of words can be interpreted multiple ways. There's also only so many words we can put on an ad before it gets messy. We do try hard to make the nuances clear on our website, which ultimately is where any new users will have to go in order to buy the service.
It certainly wasn’t the most egregious VPN ad I’ve ever seen, but it was disappointing to see Mullvad imply privacy properties for VPNs knowing that ordinary people don’t understand cookies, sessions, fingerprinting, or JavaScript.
In any case we make the most important nuances clear on our landing page, and in other places on our website.
That copy should’ve never made it past basic checks for legitimacy.
Or alternatively: feel free to describe to HN how Mulvad protects users against ad networks.
To claim that you stop online ad networks is a downright falsehood and you know it.
A VPN is not enough for privacy. But in combination with a privacy-focused browser, you make sure to block third-party cookies and other tracking technologies used by the data collectors.
That's why we partnered with the Tor Project to develop Mullvad Browser – a browser designed to minimize tracking and fingerprints.
Please also note that this information is clearly displayed on our landing page. We don't want people using our service for things it's not designed for.
The browser piece is doing almost all of the work against ad networks, isn’t it?
Which part of defense against ad networks does a VPN contribute to?
Where do they claim their VPN stops online ad networks?
https://mullvad.net/en/blog/aiding-to-break-habits-gambling-...
https://mullvad.net/en/blog/how-were-knocking-down-ads-and-t...
It's not going to prevent everything, but it'll definitely help.
>"Unfortunately port forwarding also allows avenues for abuse, which in some cases can result in a far worse experience for the majority of our users. Regrettably individuals have frequently used this feature to host undesirable content and malicious services from ports that are forwarded from our VPN servers. This has led to law enforcement contacting us, our IPs getting blacklisted, and hosting providers cancelling us."
>"The result is that it affects the majority of our users negatively, because they cannot use our service without having services being blocked."
https://mullvad.net/en/blog/removing-the-support-for-forward...
Mullvad and a few others have had to disable this feature because it turns out it’s super useful for hosting malware C&C servers, phishing pages, etc
There are other solutions for your use case, with or without a third-party VPN, that wouldn't require port forwarding. There are also other VPN services that do offer this functionality.
im seeing it detect!!
I highly recommend reading some of our blog posts and community posts.
You can also checkout our IP data tags page: https://ipinfo.io/tags
If you are interested in what kind of other information we can discover from our internet measurements, check out our tags page: https://ipinfo.io/tags
I wrote some info about it in this thread[0], including how you can do ad blocking at the DNS level (and cloudflare info for the same).
I got back a swift reply which solved the payment question, and a detailed iptables reply with pros and cons of different solutions.
In short: they are great.
> these issues should be addressed in the OS in order to protect all Android users regardless of which apps they use.
Android's paranoid networking has always had an exception for System and OEM apps (which include Google apps). Most such bugs fixes are unlikely to fix that core assumption. Some code refs: https://github.com/celzero/rethink-app/issues/224
> The leak during tunnel reconnects is harder for us to mitigate in our app. We are still looking for solutions.
Android supports seamless handover between two TUN devices (on reconfiguration). It is tricky to get it right, but implementable.
> GrapheneOS adds a Network permission toggle for disallowing both direct and indirect access to any of the available networks. The device-local network (localhost) is also guarded by this permission, which is important for preventing apps from using it to communicate between profiles. Unlike a firewall-based implementation, the Network permission toggle prevents apps from using the network via APIs provided by the OS or other apps in the same profile as long as they're marked appropriately.
>The standard INTERNET permission used as the basis for the Network permission toggle is enhanced with a second layer of enforcement and proper support for granting/revoking it on a per-profile basis.
> To avoid breaking compatibility with Android apps, the added permission toggle is enabled by default. However, the OS app installation UI has been extended to show the toggle as part of the installation confirmation page so users can disable it when installing an app.
> when the Network permission is disabled, GrapheneOS pretends the network is down. It shows the network as down in various APIs, returns errors showing a network connectivity issue rather than a revoked permission and avoids running scheduled jobs depending on the network. This results in apps handling it as if the network is down rather than crashing or showing errors from trying to use the network and being unable to do it.
docker run --network none
For linux there's a couple ways of setting up a process group that can't access your network.
I'm not very familiar with other OSes.
Why do you ask? Isolation between processes can be difficult on non-phone operating systems, but removing permissions tends to be quite easy.
How about you all slowly wean off this utterly dumb habit of ranting and raving about your pet problems in unrelated topics?
GP is saying that the Android permissions model requires giving Internet access to any app you install from the Play Store; there isn't a way for an app to request "zero permissions" (or rather, there is, but basic Internet access is a permission granted to all apps, even when zero additional entitlements are requested).
That said, this isn't unique to Android. At least as of a few years ago, iOS did more or less the same thing. (You can disable an app's access to the local network, but that's not the same thing as denying (or requiring an app to request) basic network connectivity).
As I understand it, apps that use the internet still need an entitlement, it's just that the Google Play store no longer shows that one in the list.
That's what it is, I think. The Play Store doesn't show it in the list of permissions anymore.
It's an unfortunate limitation for a device I own to be handicapped this way.
It's not a real security check that they're doing, but rather just checking for certification, which is very unfortunate.
Android Auto is completely disabled as an opinionated security measure.
Google Pay and some banking apps (ones that require Google's Play Integrity API) will not run. GrapheneOS doesn't attempt to spoof these APIs because they are moving towards cryptographic verification [0]. Most apps don't require this check but if they do you are out of luck unless you can get the app developers to trust GrapheneOS's keys.
[0]: https://grapheneos.org/articles/attestation-compatibility-gu...
Nowadays it's the Google's Find My Tag network which will be unsupported.
https://grapheneos.org/usage#android-auto
VoLTE and VoWiFi are supported if your carrier supports it.
Google Maps and Uber work fine, provided you install sandboxed Google Play.
nary the case but i suppose if i absolutely needed to access any finances from my mobile device, it certainly wouldn't be from one of said institution's own mobile apps, but via web browser.
I used to do home banking from my bank's website. Recently, they created a digital-only branch for customers who mostly do home banking and only rarely need to go in person to the bank. They asked their customers if they wanted to switch and offered services at the same or lower cost than before. I made the switch, but found out that unfortunately the new website lacks some functionalities that are only available from the mobile app. I guess they are assuming that most people would just use their phone anyway and didn't bother to reach feature parity between the website and the app, preferring the app.
i hope you switched back, lol.
You can also contact your bank and tell them that you want to be able to deposit checks via the Web site.
If enough people do this, and don't use the overly-proprietary app, the bank might listen.
There are workarounds, but it sounds annoying and a burden. What if the closest bank branch is an hour on foot away? Or the OP lives in a rural place and it's half an hour drive? I don't have this problem since my bank works with graphene, but I would reconsider using it if most applications I use refused to load.
who uses checks anymore, btw?
banks and gov sites say it's because of security, but accept SMS. so we know what it's really about
I still hate it, but can't do much about it.
Custom ROMs nowadays require you to be scouring Qualcomm out of tree source repositories (or firmware dumps of equivalent phones, I think, in the case of Mediatek). It's impossible to guarantee quality with this conditions. Even if you just want to have a pristine kernel tree of the original firmware you may find, if it was ever released, it was squashed on the wrong source commit (again, laurel_sprout, though a random Github angel fixed it).
So Google's devices tend, thankfully, to have better sources. Additionally, GOS team is competent and, for now, sustained full-time by donations. Those three conditions are what allow GOS to be a very good ROM.
Do note: it has its quirks, specially with the new trimestral code dumps by Google where half-baked features are on the source (though disabled by feature flags).
I sometimes wish I could just configure that per-app as a user. Frustratingly, on iOS it's possible only for mobile data, but not for Wi-Fi – why!?
I agree that there should be an app firewall to the point I’m running an older phone w the checkm8 jailbreak to have a firewall.
https://support.google.com/googleplay/android-developer/answ...?
So yes, this hypothetical flashlight app can request the permission. The user has to allow it in some way - approx or precise, one-time or always. But also nowadays the users sees when & what app is requesting these kind of permissions. It's a moot point.
(For background location there's an extensive form in the play store, you even have to send videos in many cases - for foreground, there's nothing)
Did they edit their post? I just see "They don't even allow disabling internet permissions on a flashlight app, the OS is run by an internet ad company so it makes sense."
If you're implying that you need location permission to turn internet access into a tracking problem, you're wrong.
I agree that the OS should have a way to override the permission, but it’s not Android itself just giving out internet access by default. It’s more that it’s almost every developer’s default setting when building the app.
The best example of no internet permission in an app off the top of my head is Hacker’s Keyboard – and you can understand why the developer chose to avoid it.
It's especially frustrating when using internal dns records that only live internal will randomly not work on a phone. I can see that the device is on wifi that is feeding internal dns servers with the records, but it's resolving externally still for some android reason. This happens on my SO's phone when using things all the time, but I really don't use my phone in the house except to read books and rarely notice.
No idea how apple is about this, but the fact they try to proxy everything you do via their "privacy" vpn by default including dns as DOH, I can't imagine it is any better trying to use what they'd see as a competing product, and we know how apple feels about those.
Are you sure you don't have wifi assist enabled? That's explicitly designed to switch to cellular when wifi signal is poor.
And a simple search shows definitely people annoyed by the exact same symptom of redirected DNS queries and inability to use internal-only DNS entries. https://www.reddit.com/r/ios/comments/uurkqr/limit_ip_addres...
That is, if my configuration profile Becomes invalid or is non-functional, Will it just cease to pass traffic?
I hope someone who is more knowledgeable about the configuration profiles can give you a definitive answer.
Anyway I do trust the developer, he’s been at it a number of years working on this thing, and most importantly it really does work well, blocking the most amount of ads vs other blockers. He’s obviously not a web dev and the jailbreak scene is kind of scrappy so I can forgive the website. Look past the formatting and see what’s there. If you want to use the method but not run any code you can manually supervise your idevice but you have to backup / wipe / restore in order to do it on stock iOS. The pac scripts are open source and you can self-host them if you’re truly paranoid.
As far as I can tell the only issue I ran into was that despite being connected to a working wireless access point, the device reported I had no internet. It still worked, but it seems for the purposes of the status bar icon, and whatever other underlying system code, it was using a google server to verify internet was working.
I would just stay far away from android if you value your privacy, and probably tech all together.
If you really want secure and private, get a dumb phone, and just use it as a phone. Anything else, use linux that you can actually control and audit.
This worked great to ensure that no traffic was leaked from pc to vpn server. The IP address of the VPN server you’re making use of rarely changes or if it does it’s easy enough to change on the MikroTik firewall.
Another method is to block all traffic not to the port/protocol pair being used by the VPN server if you don’t know the servers IP address (or if it changes). As an example drop any traffic not dst UDP 1194 (based on the type of VPN, of course). MikroTik routers also have a great little tool called torch that allows you to quickly and easily watch traffic (in addition to of course, supporting packet captures. Mikrotik routers are very reasonably priced and range from as low as $30 up to $3000 - all with no software licenses, and they are very powerful and capable if you know what you’re doing.
This worked great to ensure that no traffic was leaked from pc to vpn server. The IP address of the VPN server you’re making use of rarely changes or if it does it’s easy enough to change on the MikroTik firewall.
Another method is to block all traffic not to the port/protocol pair being used by the VPN server if you don’t know the servers IP address (or if it changes). As an example drop any traffic not dst UDP 1194 (based on the type of VPN, of course).
just curious, what was your "main router" in this setup? ISP-supplied?
however, I had to show / prove to a client that the set up could be easily duplicated at other locations (and moved around) where everything else on the network was unknown (only known / controlled parts were to be a Windows laptop, and the mikrotik router connecting ethernet from that laptop to whatever network also via eth.
For some of the configurations that needed to be very portable, the (very low end) MikroTik was powered via USB from the laptop
Customer also wanted the router to log any dropped/leaked traffic (which we did on the mikrotik to it’s internal memory, or a usb stick with a txt file log)
If only we could insert a firewall between our apps and the modems in our phones.
As to your other point… If you remove the Sim card from your telephone and then connect to a second router device that you carry with you… But we’re getting a little weird here…
Edit: and GP asked specifically about Mikrotik, I think. They have L7 cap, but it's literally raw.
If we’re being formal, a true slug is one that has no IP address defined and is a transparent layer two firewall… But we don’t need to pick nits here…
When you are stuck with a router that always hands out IPv6 Adresses and doesn't let you turn that off you are just screwed.
I don't even know if you could install a firewall appliance behind that router and strip out the IPv6 DNS Servers it advertises.
does this happen with wifi tethering too? if i have a vpn set up on a laptop that i connect through the phone's wifi will that leak in the same way?
even bigger nightmare on iOS where 'always-on VPN' can only be configured on devices 'supervised' by an Apple-approved (documented application and telephone call with current employee required) organization's MDM solution—or you otherwise need a Mac to use the Apple Configurator app to even create a Configuration Profile containing the 'always-on VPN' key.
The format cannot be that complex, right?
https://developer.apple.com/business/documentation/Configura...
Disclaimer: I've never used this feature. I only use it for backups and copying files to my iPhone.
The Grugq created a tool for this a decade ago (sadly unmaintained): https://github.com/grugq/portal as part of a presentation about operational security for hackers. It's a great watch if you're interested in how various (in)famous hackers thought they were secure and got busted anyway. https://www.youtube.com/watch?v=9XaYdCdwiWU
This is terrifying.
solder on some ESPs on an old playstation portable device and connect from starbucks?
Even if the MMS is supposedly on an intranet, it wouldn't surprise be that a poor implementation might expose the rest of the system to internet for a brief moment.
The simple problem has always been that when you're selling someone a $1000 piece of hardware that's supposed to "just work" how much do you let their ignorance fuck it all up.
Now granted that's not an argument for locking away access from those who choose to accept the responsibility, as has always been the case, but the idea that there was any other outcome was absurd.
Yes it'd be nice if everyone had some tech savvy common sense, but even now when we have generations growing up with it, actual understanding is far and few between when looking at the general population. People don't care, and don't want to, and it can make things risky.
The thing is, it's not that I particularly care about people, but it's made Android/iOS incredibly irritating to use, I avoid it as much as I can. It's not just that it wants to protect me from myself, as much as it doesn't let me do what I want to do, it feels like computing with a straightjacket on. Build a fort knox of sandboxes and SELinux, that's fantastic, as long as you give me the keys and blueprints, and for christ sake, stop pretending that my phone isn't a computer.
...unless you care to elaborate on why you disagree with this statement in substance and/or on point?
In the sentence "See, I can do silly categorical statements too," the adjectives "silly" and "categorical" both modify the noun "statements" and are not themselves related to one another. That's why OP used both of them. If the two words were synonymous, only one would be required.
It's fun nitpicking nitpicks.
sure is.
https://github.com/chenxiaolong/avbroot
Works great with CalyxOS and GrapheneOS.
If you want root access, build and sign userdebug builds with ro.adb.secure=1, which is officially supported by GrapheneOS and only exposes root access via ADB which you should only use from the computer where you're building the OS.
It would be possible to add some kind of key combination at boot to disable loading user installed applications, etc. and instead making a terminal with root access available. Not clear how that's really useful though. Instead, what these projects are doing is giving out root access to a massive portion of the OS in order to be able to give out full root access to apps. This is used as a shortcut to implement features in a way that massively reduces security even if you never use it. Implementing those features properly integrated into the OS following the principle of least privilege is the proper approach. Most of the features people believe they need this hack to achieve are doable without it, such as filtering traffic with your own firewall rules while also using a VPN which is a standard Android feature available to apps.
https://github.com/chenxiaolong/avbroot?tab=readme-ov-file#u...
There will always be a subset of users who prioritize functionality over security. This includes anyone who would root an Android device (and anyone who would use a desktop computer running most distributions of Linux, macOS, or Windows).
I'll be glad to reconsider using root on Android if all of the functions of App Manager's "block trackers" feature[1] and Basic Call Recorder[2] were available on Android without root.
[1] App Manager: https://github.com/MuntashirAkon/AppManager
[2] BCR (Basic Call Recorder): https://github.com/chenxiaolong/BCR
Basically the idea is that there should be no need for root if everything is nicely gated by permission controls and high-level APIs. If every component of Android were actually well-designed, this idea would have more merit, but unfortunately there are still a few big gaps in what you can do with a rooted versus non-rooted device, e.g. custom firewall rules (which could provide a hotfix for the issue at hand here). When asked to expose more fine-grained firewall control to the end user, the Graphene devs basically responded that it's extremely difficult to set up firewall rules properly such that leaks are impossible [1], which may be true, but I'd like to think it's better than nothing.
Also, because root access would break Android's protection against end user application tampering, that would likely rule out the possibility of GrapheneOS receiving special support from banking apps, which is something they hope to see in the future [2].
Anyway, this particular issue is definitely a bug in AOSP, and will hopefully be resolved promptly. It's being tracked here: https://issuetracker.google.com/issues/337961996
[1] https://discuss.grapheneos.org/d/4113/6
[2] https://grapheneos.org/articles/attestation-compatibility-gu...
GrapheneOS already has fine-grained firewall support exposed to the user via the standard VPN service feature which despite misconceptions can be used while also using an actual VPN and there are multiple apps supporting this. It's not simply difficult to set up firewall rules where leaks aren't possible but rather it doesn't really work because not everything is done via direct socket access from the apps. This is why we have our Network toggle in the first place, which does a lot more than blocking direct socket access both to block indirect access and preserve compatibility by pretending the network is down for the most important APIs.
These DNS leak issues which were reported to us earlier may be an app bug which can be worked around by the app. The OS could be changed to prevent this happening but that doesn't imply that it's an OS bug. More investigation is required to determine the cause and solution. We're also aware of a local network multicast leak that's not covered in Mullvad's post, which is very likely to be an Android OS bug but we aren't certain about that yet either. It's worth noting that neither the DNS leak issues or local network multicast leak issue impact the built-in VPN support. They're only happening with VPN apps. It's likely that some of this is caused by bugs in the Android VPN service app support (particularly the multicast packet leaks) but the DNS leaks are quite possibly an app flaw. Mullvad's post acknowledges they found a way to address one of the forms of leaks with changes to their app, which may be possible for the rest since there aren't leaks when the VPN is down but rather when it's in the process of reconnecting. It looks a lot like a race condition where the VPN is being activated before everything is in place, which could be a bug in the OS but could also be a bug in the app where it's doing something in a different order than what's intended.
Interesting, didn't know that. Maybe I should file an issue with the official WireGuard app asking them to support this. It would be nice if "multiple VPNs" was provided as an OS feature.
> It's not simply difficult to set up firewall rules where leaks aren't possible but rather it doesn't really work because not everything is done via direct socket access from the apps.
This only applies to rules intended for specific apps and not system-wide rules, no? I'd hope so, since as you said people are already applying system-wide (or at least user-wide) rules using the VPN interface.
Apps have to implement it unless you mean supporting multi-hop WireGuard VPNs within the OS. Apps can support multi-hop and apps can also support doing filtering, etc. in addition to supporting an actual VPN. It's not exclusive unless the apps make it exclusive. Apps can also decide they want to support forwarding traffic through another app but they should really do that in a way that's secure instead of how some apps are currently offering this...
> This only applies to rules intended for specific apps and not system-wide rules, no? I'd hope so, since as you said people are already applying system-wide (or at least user-wide) rules using the VPN interface.
Sure, but output filtering doesn't really work well in general. For example, if you allow resolving any DNS names then you allow 2 way communication with anyone through your DNS resolver. The requests only go to your DNS resolver, but they can be for <data>.<random>.example.com where the name servers for example.com are set up to receive that data and the random value avoids it being served from the resolver's cache. The value of the DNS result can return data in the other direction. It's easier with a TXT record but can simply be an A/AAAA record too. DNS is commonly used to mask traffic by malware. It's not an obscure approach but rather very normal. Similarly, many services can be used as some form of proxy at least to communicate with arbitrary people.
The main purpose of a firewall is when you're actually hosting services and need to filter inbound connections for DDoS mitigation, etc. by limiting the number of connections per IP or IP block, rate limiting, etc. It also acts as a way to prevent listening on ports you didn't intend to be listening on due to default-enabled services or services which listen on all interfaces by default, etc. On platforms where loopback is commonly used for communication, it's also a way to do access control based on uid, gid, SELinux context, etc. None of those 3 things applies much to Android. It's very rare for apps to use loopback for communication, although some do it. Hopefully they already do their own authentication... GrapheneOS does plan to use network namespaces to provide the option of per-profile or per-app loopback interfaces, although we could also just start with a toggle for access to it.
Worth noting Android uses eBPF for controlling per-app access to the network for our Network toggle, not netfilter (iptables/nftables). They've gradually moved more and more to eBPF and away from netfilter since they have the resources to develop things that way.
Your definition is meaningless and not useful for reasoning or communication.
I found this out since on Mobile Linux, if you enable VPN, the VPN breaks all of those.
I don't think there is a clear way to fix this on Android without breaking a lot of expected functionalty.
i've done the dance re: VVS with advanced AT&T support on VPN'ed iOS—so can confirm your point is not limited to Android.
I will say that I wish there was a DisallowedIPs directive. It's fun having to subtract a /24 from 0.0.0.0/0, although there are calculators you can use.
for windows split tunnels it still does, I believe.
0: https://twitter.com/GrapheneOS/status/1782477984156311814
We're aware of a separate issue unrelated to DNS leaks where multicast packets can leak to the local network with VPN apps. This appears to be an OS bug, but that's not confirmed yet. It will likely only be determined if it's a bug when we find a fix for it. This multicast leak doesn't happen with the built-in VPN support either.
There have been plenty of VPN leaks on other platforms including issues that are still not really fixed without setting up custom netfilter or eBPF rules similar to what Android is trying to do on platforms where that's not done for you by the OS.
On Android, the responsibility for preventing leaks is partially taken on by the OS which promotes a standard leak blocking feature which has gotten much better in the past few years. Each app trying to do this themselves is not a recipe for success. It's not as if Mullvad was aware of these issues for a long time and asking Android to fix it without action.
I once worked with someone who worked with someone that had previously been a major Android fanboy, but after doing some work that required a security clearance, they became an iPhone user and insisted their family get iPhones too.
Got an AppleTV and this issue stopped.
I am a bit shocked when I see politicians with iPhones, most are unaware that Pegasus can take over at any point.
the matter at-hand considers Android (and iOS both) operating system- and kernel-level insecurities by-design. the operating system (together with all root-level or otherwise authorized system activity), under certain conditions—e.g. connectivity change, hard-coded system function, apps with permission to hardcode their own network functions, etc.—will refuse to use any NIC, whether physical or virtualized, except the one containing the cellular carrier's connection/routes. that traffic might then necessarily include DNS queries and any/all other private but now-leaked data.
1.) the system strictly respects user-configured DNS; and
2.) that the leak of some private data is acceptable. leaked traffic is still leaked even if otherwise encapsulated by some other encryption mechanism outside of an otherwise properly-configured VPN tunnel.
#1 is of course a much larger risk assumption to swallow.
Apple doesn’t seem to care, as they don’t care about preserving your privacy wrt themselves.
Inspect security empirically - you might think that your security must work, but that means nothing; you must investigate empirically: All data going to the Internet must pass through the gateway. Collect the packets on the gateway, not on the device, and inspect them for leaks. Finding leaks should be trivial at that point.
The only trick might be cellular connections: We don't know that leaks aren't unique to cellular connections. I know cellular gateways can be setup, but are the packets inspectable at a level that will reveal leaks?
There's also leak issue which was reported where multicast packets leak outside of the VPN tunnel to the local network. This is highly likely to be an OS bug, unlike the DNS leak issue where it's not yet clear if the OS or the app is the problem. The OS can likely prevent those DNS leaks even if apps don't get fixed but it wasn't necessarily supposed to be responsible for it. From the OS perspective, a VPN app is supposed to set a DNS configuration and not setting that configuration results in partially using the OS DNS.
Paradoxically, I don't believe this issue is faced regarding SYNC MODE. As you obviously know, 'in asymmetric mode, read memory accesses are processed as SYNC, while write memory accesses are processed as ASYNC'.
does this mean that the signal handlers in write memory are exploitable?
If this be true, does GOS offer a mitigation for this, or can it be possible to simply allow all users to have the option to pick SYNC MTE to bypass this attack surface?
Furthermore, MTE is not enabled for the kernel, would it be possible to have it enabled by choice as well?
Finally, regarding the OS processes to which GOS recently enabled MTE for as an option for its users, does it also include the cellular firmware, IOMMU/SMMU and the software stack that communicates between the isolated chip and the OS? I address this point because, GAL Beniamini stated that: " That said, up until now we’ve only considered the high-level attack surface exposed to the firmware. In effect, we were thinking of the Wi-Fi SoC and the application processor as two distinct entities which are completely isolated from one another. In reality, we know that nothing can be further from the truth. Not only are the Wi-Fi SoC and the host physically proximate to one another, they also share a physical communication interface". Nonetheless he further states: "For example, by going over the IOMMU bindings in the Linux Kernel, we can see that apparently both Qualcomm and Samsung have their own proprietary implementations of an SMMU (!), with it’s own unique device-tree bindings. However, suspiciously, it seems that the device tree entries for the Broadcom Wi-Fi chip are missing these IOMMU bindings". Despite that the research is from a couple years, it remains viable evidence that IOMMU although provides adequate protection, it remains an insufficient mechanism on its own and requires further hardening on the software stack. Does GOS address this profound attack vector?
I hope to get your perspective on the matter.
Thank you in advance.
Isn't Android open source? Can they not fix it for them and submit a PR?
Encrochat was similarly marketed as absolutely trustable complete with experts covering "we fixed this vulnerability/exploit and you can trust us" vibes (https://www.manchestereveningnews.co.uk/news/uk-news/dads-se...)
Isn't Mullvad the same thing?
Do you really think they would allow terrorists like Hamas use Mullvad to coordinate attacks? Coincidentally, Hamas does not trust any sort of VPN, opting for underground land lines.
I mean, duh. Like everyone always says around here, all bets are off when your threat model includes nation states.
Timing attacks, meta data, and total access to the internet backbones means it’s a reasonable bet that the Big Boys can track anything on the public internet, regardless of encryption or redirection. And if you’re Hamas, you’re probably on their radar.
Makes sense as there has been no cases involving terrorist using Mullvad and such.
So Mullvad is not good enough for terrorists but good enough for the rest? This makes no sense to me.
If they are a state actor, then the goal would be to use the intelligence only for parallel construction in the most severe cases like terrorism.
If they are not a state actor, then the goal would be to be so private that if terrorists use it, nobody would ever know including themselves.
In both cases, we see the same result as the public until somebody leaks.
This means that you would be very unlikely to get busted using a state compromised VPN for torrenting movies, as that's typically a civil matter and would require additional data points for parallel construction to not reveal the compromised VPN.
But if you are involved in terrorism, then you should assume the VPN is compromised in a way that will make digging up additional secrets about your activities trivial and attributable to something besides the VPN that everyone is fine with (like dragnet service provider data).
Oh, they probably do act on it. For most things, I assume they use the intelligence they gather for parallel construction - if you know a fact about an adversary, it can make it easier to find other, more obvious (to that adversary) ways to "find" that information.
I'd imagine taking direct, obvious action on information gleaned from front and honeypot VPN services is probably only done for extreme cases i.e. an active threat to the country/administration/agency/allies.