Password protection of SOCKS interface

[tmpuserforbugreport]

Is your feature request related to a problem? Please describe.
Currently shadowsocks exposes it's SOCKS interface (e.g. at port 1080) without any protection. Any malicious app may use it unauthorized and leak VPN IPs to banning authorities. There should be a way to protect SOCKS interface from unauthorized use.

Describe the solution you'd like
To implement SOCKS password protection according to https://datatracker.ietf.org/doc/html/rfc1929

Describe alternatives you've considered
No alternatives are actually available.

Additional context
It appears that Android OS is not well protected against VPN sensing/leaking (more details are available (in Russian) here https://github.com/loop-uh/yourvpndead). So any application-level protection is very useful. Please see amnezia-vpn/amnezia-client#2452 and amnezia-vpn/amnezia-client#2453 for a similar issue and a solution.

[kutukvpavel]

I'd argue, that the lack of authentication option for SOCKS5 proxy on Android should be treated as a vulnerability (and this issue label should be "bug"). And this vulnerability is now being actively exploited by censors. Unfortunately, even Android Work Profile does not isolate localhost ports, therefore even putting suspicious apps inside e.g. Shelter container does not mitigate this vulnerability. We need a fix ASAP @madeye @Mygod .

[madeye]

even with this fix, make sure not include any malicious app in the per-app proxy list.

[Mygod]

So is the idea that we are going to intentionally exclude apps possibly controlled by censor? (How do you even do that unless you have a known black list?) I think as a workaround, you could just set the local SOCKS port to a random port for now. A better fix would be to instead have shadowsocks-rust listen on a local socket inside the app's data dir rather than the port.

A more principled way would be to have an isolated environment but that might be too much to ask for for an average joe.

[kutukvpavel]

even with this fix, make sure not include any malicious app in the per-app proxy list.

@madeye Sure, but to my mind, this is (and always has been) an the end-user responsibility. It's impossible to make something foolproof without resorting to compromises.

So is the idea that we are going to intentionally exclude apps possibly controlled by censor (How do you even do that unless you have a known black list?)

@Mygod No, the idea is we (optionally) put the SOCKS proxy behind a password, effectively enabling the end-user to whitelist which applications can use it. This strategy has already been implemented across several popular mobile VPN clients (v2rayNG, Karing, Happ, ...).

Well, here is a brief outline of the emerging attack vectors that can not be mitigated using built-in Android isolation mechanisms:

1. Attacks targeting the local TUN interface.
   1.1. An app can use NetworkInterface.getNetworkInterfaces() API and parse its output to detect a tun interface.
   1.2. A malicious app can interrogate /proc/net/route to detect a default route passing through a tun.
   1.3. The worst of all is: a malicious app can connect to the detected tunnel interface (bypassing VpnService) and reveal the IP address of the VPN server, leading to a permanent IP-ban. Even on GrapheneOS...
2. Attacks targeting the local SOCKS5 proxies.
   2.1. Scan of a list of known SOCKS5 ports.
   2.2. Full blown port scan.
   2.3. As already discussed in 1.3, a malicious app can connect to the proxy server and reveal its IP.
   2.3. Same as 2.1 and 2.2 but with an RFC1928 auth probe.

Attacks targeting the tun interface and routing tables can be mitigated using VPNHide kernel module, but the installation procedure is certainly not suitable for 'an average Joe', not to mention that it requires root access and is a dirty hack.

At this point, it's arguably easier to just switch the app into the SOCKS5 proxy-only mode. This leaves us with one single attack vector that can lead to serious consequences for the user or the VPN provider: the unauthenticated SOCKS5 port. Granted, even with authentication enabled, a malicious actor will still find out that you are using some kind of a proxy, but they won't be able to find its address and ban it, which is a very significant distinction, especially if you are self-hosted.

I think as a workaround, you could just set the local SOCKS port to a random port for now

Already done, but this workaround can only buy us some time, since nothing prevents Android apps from running a full-blown port scanning, apart from the time and resources it takes. I keep potential abusers inside frozen inside a Shelter, so no background scanning for them, but still.

[Mygod]

I'm pretty sure that an excluded app cannot connect to the tun interface, otherwise we would use this feature in shadowsocks-android. Your linked issue is about the shell user which has special permissions and proves nothing about normal app behaviors.

[kutukvpavel]

There are conflicting reports on what permissions are required to execute setsockopt(SO_BINDTODEVICE, “tun0”) on Android, I guess it depends on the kernel version. And what kind of special permissions does a non-root shell user get, besides the mentioned Network permission? Regardless, my point about an unauthenticated SOCKS proxy still stands.

[HanabishiRecca]

So is the idea that we are going to intentionally exclude apps possibly controlled by censor?

No, there is already "Apps VPN mode" for users to decide what apps should go through the proxy.

But the problem is, without authorization any other app you didn't select still can use the proxy by connecting to its local address.

Example