Password protection of SOCKS interface #3242

Activity

1. tmpuserforbugreport

   added

   enhancement

   on Apr 28, 2026
2. kutukvpavel commented on Apr 29, 2026

   

   kutukvpavel

   on Apr 29, 2026

   Last edited by kutukvpavel

   More actions

   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 .
3. madeye

   assigned

   Copilot

   and

   madeye

   on May 1, 2026
4. Copilot

   linked a pull request that will close this issueAdd SOCKS5 password protection for local proxy interface (RFC 1929) #3243on May 1, 2026
5. madeye commented on May 1, 2026

   

   madeye

   on May 1, 2026

   Contributor

   More actions

   even with this fix, make sure not include any malicious app in the per-app proxy list.
6. Mygod commented on May 1, 2026

   

   Mygod

   on May 1, 2026

   Last edited by Mygod

   Contributor

   More actions

   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.
7. kutukvpavel commented on May 4, 2026

   

   kutukvpavel

   on May 4, 2026

   Last edited by kutukvpavel

   More actions

   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.
8. Mygod commented on May 5, 2026

   

   Mygod

   on May 5, 2026

   Contributor

   More actions

   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.
9. kutukvpavel commented on May 5, 2026

   

   kutukvpavel

   on May 5, 2026

   Last edited by kutukvpavel

   More actions

   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.
10. HanabishiRecca commented on May 6, 2026

    

    HanabishiRecca

    on May 6, 2026

    More actions

    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

    
11. dyhkwong commented on May 14, 2026

    

    dyhkwong

    on May 14, 2026

    More actions

    UDP is NOT protected by SOCKS5 authentication. Spyware can still access the public IP of the proxy server by enumerating all the 65565 local UDP ports. shadowsocks-android uses tun2socks so disabling UDP support for the local SOCKS5 server is not feasible.