Newbie questions about security and how to audit

ryrona

[GrapheneOS: These were upstream Android VPN bypasses which were quickly resolved by GrapheneOS and still impact non-GrapheneOS Android, see https://grapheneos.org/features#improved-vpn-leak-blocking for more details. We've found additional issues since then ourselves which we've fixed, although a couple of the fixes for less serious issues still need to be fully tested and shipped.]

See, this is why I want to audit things myself. I have found two VPN bypass bugs in my testing today.

https://github.com/GrapheneOS/os-issue-tracker/issues/3442
https://github.com/GrapheneOS/os-issue-tracker/issues/3443

Maybe Android/AOSP bugs rather than GrapheneOS bugs, but it is in GrapheneOS I have found them and expected that high level of privacy, so reported them here for now.

Next thing is looking into disk encryption, but that will be another day.

alfred

@ryrona There was some discussion about multicast and VPNs awhile back that may be helpful.

https://discuss.grapheneos.org/d/10337-spotify-communicating-with-other-devices-on-local-network/27

From what I have researched, multicast and broadcast traffic is not typically routed over VPNs. Both are isolated to the local network.

nunyo

alfred
Have you enabled "block connections without VPN" in the network settings? (Not Mullvad)

alfred

nunyo Yes I've tested it with that switch enabled in the settings. Normal device to device network traffic is blocked. i.e. You can't go log into your WiFi router or a local computer.
Broadcast and multicast don't appear to be blocked with that switch. Which does make sense. If all broadcast traffic was blocked, then DHCP wouldn't work which would mean no network traffic would work.

ryrona

alfred Actually, multicast and broadcast traffic should be blocked, but not DHCP specifically. The mental model of a secure VPN setup is that you have two computers. The first computer is a workstation, its only physical network connection is a cable to the other computer. The second computer is a gateway, and it has two network cards, one that only goes to the first computer, and one that goes out on internet. The first computer thinks it is directly connected to internet, but all data packets coming from it will transparently be bridged into a VPN connection out to the internet by the gateway computer. All replies coming from the VPN connection will be sent back to the first computer. This way, the first computer cannot by design bypass the VPN in any way, not with any kind of data packet. Data packets not suitable to be bridged over the VPN will simply be ignored instead by the gateway. In no way can the first computer learn the external IP address or communicate with anyone other than the gateway, not even if the gateway stops working. DHCP and other network connection protocols of course runs on the gateway here, if at all, those are details irrelevant to the first computer. For all purposes, the first computer in this mental model will be all apps installed in a user profile in GrapheneOS.

alfred

ryrona If I am understanding you correctly, your are saying that ideally, a VPN should act like a hard wire connection between itself and the VPN server and nothing should be allowed outside except what is necessary for the connection to the VPN server?

DHCP uses broadcast. So not sure if you can block all other broadcast/multicast traffic without any issues. So I am not actually sure that it is a bug, but appears to be how networks and most VPNs are designed.

If you google "VPN multicast" there are lots of articles on VPNs that support multicast, or how to get multicast to work over a VPN. It is worth noting that multicast and broadcast are limited to the network boundary, it is stopped at the router.

ryrona

alfred Ideally, or actually how VPN are supposed to work, a VPN should virtually put your device on a totally different local network than your own. For cooperative use, this is to ensure employees working from home can virtually be on the company network and not their untrusted home network (from the company's view point). For anonymous VPN usage, you would be on a virtual local network only your device and a virtual gateway/router is on, so all local network traffic is blocked entirely. This is how VPN is supposed to work.

On Linux, this is accomplished by making the VPN network interface become the default one all network traffic is sent to by the system and all applications. The VPN application or protocol itself binds to the real interface so it can send out traffic there, ignoring the default. Typically the DHCP client also binds to each real interface to get an IP for each interface. If you add an iptables based kill switch, you would configure it so all traffic to the virtual VPN network interface is allowed, but for the real interface only traffic to the specific IP:port of the VPN server is allowed, preferably also only if sent by the VPN application (the kernel itself for wireguard). This does not block DHCP, since the DHCP client must use raw packet mode (which requires root permissions), because it need to function before the IP layer has been initialized. Multicast packets at the IP layer would be blocked, and non-root applications cannot send raw packets or below IP layer. QubesOS specifically goes further by realizing the actual ideal design by using virtual machines and connecting them like I described, but typically a killswitch is enough like typically done on Linux.

Tryptamine

ryrona a kill switch in a desktop Linux distribution is normally provided by a VPN app, isn't it? I haven't seen one baked into the base OS. I'm sure there are packages you can install to get the function system wide, but I know in Ubuntu I can have a kill switch if I use the ProtonVPN app, but not if I import a WireGuard or OpenVPN config file and set it as primary and to connect at boot.

The ProtonVPN app gives 2 options for kill switch, Standard, where as long as the app is open the kill switch is active when VPN disconnects, and Advanced where the kill switch is active no matter what! Its active if the app shuts down, and when you reboot its active before ProtonVPN starts. I guess you could add in an iptables kill switch for the system managed VPN, I'll have to look into that, thanks for the idea!

On Android the kill switch seems to work in conjunction with the VPN app it is set under. As you have found in the above issue tracker report, Mulvad VPN does not effectively block all traffic when VPN connectivity is lost and packets leak. On the other hand, the only VPN app recommended on the GrapheneOS website, the official WireGuard app, does effectively block all traffic upon loss of connectivity!

So... There's obviously something behind the recommendation on the GrapheneOS website, and you've just shown data that shows not all VPN apps are created equal, and therefore not all VPN apps are perhaps worthy of full user trust!

Dumdum

Tryptamine only VPN app recommended on the GrapheneOS website, the official WireGuard app, does effectively block all traffic upon loss of connectivity!

Does this still apply with "Block connections without VPN" turned off? I need/want to have that setting toggled off otherwise I can't use KDE Connect as it prevents local network sharing.

ryrona

Tryptamine I guess you could add in an iptables kill switch for the system managed VPN, I'll have to look into that, thanks for the idea!

Yeah, that is what I have always done. I use the built-in wireguard support, and some iptables rules. I think most reputable VPN providers have instructions or at least hints about how to set up such an iptables based kill switch.

Tryptamine On Android the kill switch seems to work in conjunction with the VPN app it is set under. As you have found in the above issue tracker report, Mulvad VPN does not effectively block all traffic when VPN connectivity is lost and packets leak. On the other hand, the only VPN app recommended on the GrapheneOS website, the official WireGuard app, does effectively block all traffic upon loss of connectivity!

I wouldn't expect a system provided kill switch to work in conjunction with the VPN app, and I think my ticket showed that doing that is not always secure. I will try to dig a little bit deeper and see if I can understand how the kill switch is implemented in Android, because it sounds odd to me the way it is done, and not particular secure. I would need to find another way to reproduce the issue anyway if I am going to report it to AOSP, because the disable network permission functionality is GrapheneOS specific.

In an ideal world, GrapheneOS would provide native wireguard support. Linux has had it forever. I guess it is just a matter of someone finding the time to implement the UI for it, the kernel should support it already.

Tryptamine

Dumdum I don't think it will 100% ensure that if the VPN disconnects that no packets will not go out over your local connection, but having Always On VPN on it should attempt to reconnect immediately upon disconnection. If your VPN cannot reconnect though, there could be a situation where you may not notice the key symbol at the top of the screen for a while and therefore not realize that you were running an unencrypted connection for the last while...

When using a VPN, by design they are supposed to replace your local networks unless you enable split tunneling. Then whatever apps you allow to "split" outside your VPN will use your local network, while everything else goes to the VPN. The PN stands for Private Network. Its supposed to allow you to log into your office's network remotely, and while connected it should be just like being on a computer at your office, you can't see anyone else on your local network!

GrapheneOS

ryrona Android enables WireGuard support in the Generic Kernel Image configuration already but hasn't added the infrastructure for configuring it to netd, Settings, etc. yet. It would be a lot of work just to add basic functionality and a lot more work to support complex setups.

ryrona There are other apps available for managing encrypted USB devices. That's not the only option. Android only permits FAT and exFAT for external storage due to major security issues with supporting ext4, xfs, f2fs, etc. Android has an encryption format for added storage which can use ext4 or f2fs with fscrypt, but it's not for portable drives and is explicitly tied to the device in a similar way as the internal storage encryption. It's not what you want, and it's meant for a storage device which remains attached such as an sdcard since the purpose of it is offloading most data from the internal SSD. It could be slightly extended to work well with USB drives, but it's not usable for transferring files even between two Android devices.

https://source.android.com/docs/core/storage/adoptable

[deleted]

ryrona For encryption, use gocryptFS on pc then use DroidFS to access the data on Android.

ryrona

[deleted] For encryption, use gocryptFS on pc then use DroidFS to access the data on Android.

Thanks. I think I got MTP working now, but this sounds like a good alternative. All my existing disks are LUKS2 encrypted, and I won't switch them over since LUKS2 is a bit stronger security and supported out-of-the-box on Linux. But now I at least have two secure means of moving files to and from my phone.

[deleted] File selector is controlled by GOS the app will only see it when you select the file(s). IPC is available for apps that consent to it mutually. Use profiles to mitigate this until Graphene devs fully develop the complete app isolation feature.

I have managed to figure these things out already the past few days, but thanks anyway for confirming. I will use separate user profiles for the different parts of my life, just to be safe.

Sempa

Quite interesting post,

[deleted] thank you for your encryption suggest.

[deleted]

ryrona File selector is controlled by GOS the app will only see it when you select the file(s). IPC is available for apps that consent to it mutually. Use profiles to mitigate this until Graphene devs fully develop the complete app isolation feature.

Murcielago

ryrona

Another alternative for transporting encrypted files between different devices would be Cryptomator. The combination of VeraCrypt and EDS Lite (which can also handle LUKS but not LUKS2 if i interpret it correctly) is also frequently mentioned in the forum (note: I have not tested EDS Lite myself).

horde

Murcielago

found this in EDS Lite repo https://github.com/sovworks/edslite/issues/36

Cryptographic APIs misuses

horde

horde These might be false positives tho.

GrapheneOS

This thread s being heavily misrepresented here including falsely claiming we did something to stop people auditing GrapheneOS or reviewing our work. It also implies the Android VPN leaks we fixed with a very high priority are somehow specific to GrapheneOS. Meanwhile, those leaks still impact the OS that's being promoted there (LineageOS):

https://arstechnica.com/gadgets/2025/01/google-pixel-4as-ruinous-battery-performance-update-is-a-bewildering-mess/?comments=1&comments-page=3#comments

They're also making clearly false claims about security in general, our documentation and the responses on our forum.