Shadowsocks-android: DNS spoofed by 0.0.0.0

[IrineSistiana]

It seems 0.0.0.0 is part of spoofed IP addresses now. (update: 127.0.0.1 as well)

> nslookup www.google.com 223.5.5.5
Server:  public1.alidns.com
Address:  223.5.5.5

Name:    www.google.com
Addresses:  2001::4b7e:7ca2
          0.0.0.0

But shadowsocks-android build-in DNS resolver can't filter it away.

Because we have:

https://github.com/shadowsocks/shadowsocks-android/blob/11a0ecd95e162c70c318cd09e0e5bd545b43ea1e/core/src/main/assets/acl/bypass-lan-china.acl#L3-L4

https://github.com/shadowsocks/shadowsocks-android/blob/11a0ecd95e162c70c318cd09e0e5bd545b43ea1e/core/src/main/java/com/github/shadowsocks/net/LocalDnsServer.kt#L133

Affected route mode:
Bypass LAN,
Bypass LAN & mainland China
GFW List

Got err, for example, when testing server latency: Fail to detect internet connection: Fail to connect to www.google.com/0.0.0.0:443

Tested on shadowsocks-android version: 5.0.1

[Mygod]

Why would you use alidns for remote dns?

[Mygod]

Okay on closer inspection, maybe the domain should be handled by proxy_list instead (though I were not able to reproduce this).

@madeye Thoughts?

[madeye]

I think we can just remove 0.0.0.0/8 from the bypass list, which didn't make sense here.

[madeye]

I cannot reproduce this either.

Actually, all domains in GFWList should be handled by remote DNS, unless the user is using a Chinese DNS server as remote DNS.

[IrineSistiana]

Sorry I didn't make things clear. I just want to show that 0.0.0.0 is part of GFW spoofed IP list by using > nslookup www.google.com 223.5.5.5 . I'm not using it as shadowsocks remote dns server.

Configuration

• [x] IPv4 server address
• [ ] IPv6 server address
• [x] Client IPv4 availability
• [ ] Client IPv6 availability
• Encrypt method: rc4md5
• Route
  
  
  
  • [ ] All
  
  
  • [ ] Bypass LAN
  
  
  • [ ] Bypass China
  
  
  • [x] Bypass LAN & China
  
  
  • [ ] GFW List
  
  
  • [ ] China List
  
  
  • [ ] Custom rules
  
  
• [ ] IPv6 route
• [ ] Apps VPN mode
  
  
  
  • [ ] Bypass mode
  
  
• Remote DNS: 1.1.1.1
• [ ] DNS over UDP

Its quite hard to reproduce since the spoofed IP address is randomly chosen from a IP list.

But once a 0.0.0.0 is returned from local dns server,

$ dig www.google.com @127.0.0.1 -p 54500 <-shadowsocks local dns port

; <<>> DiG 9.14.7 <<>> www.google.com @127.0.0.1 -p 54500
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15140
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         120     IN      A       0.0.0.0

;; Query time: 10 msec
;; SERVER: 127.0.0.1#54500(127.0.0.1)
;; WHEN: Fri Jan 17 09:04:04 CST 2020
;; MSG SIZE  rcvd: 48

Edited:

Oh, i see, as for www.google.com, it should use remote server since we have:

https://github.com/shadowsocks/shadowsocks-android/blob/11a0ecd95e162c70c318cd09e0e5bd545b43ea1e/core/src/main/java/com/github/shadowsocks/net/LocalDnsServer.kt#L133-L137

But why it handled by local dns server. And reached here

https://github.com/shadowsocks/shadowsocks-android/blob/11a0ecd95e162c70c318cd09e0e5bd545b43ea1e/core/src/main/java/com/github/shadowsocks/net/LocalDnsServer.kt#L156-L158

[madeye]

It doesn't matter. Any domain name in GFWList should be handled by remote DNS, whatever you get from your local DNS server.

@Mygod Can you confirm that?

[madeye]

@IrineSistiana You may debug around shouldBypass, to see if "www.google.com" got matched in ACL.

[Mygod]

Correct. Hostname matcher overrides IP rules.

[madeye]

It looks that our current RE2 matcher cannot match anything... @Mygod

[madeye]

Looks related to FullMatch in RE2.

According to https://regex-golang.appspot.com/assets/html/index.html

(?:^*|\.)google\.com$ can only partially match www.google.com

[Mygod]

Oh right lulz. Let me fix it.

[madeye]

I tried this one ^(|.+\.)google\.com$, which works well.

[Mygod]

It should be fixed now. Either way google.com was not handled by our old DNS resolver either so I consider that I did not introduce a new bug. 😛

[philos3]

please check it ，the problem is still exist ，when i use 5.0.6