MISC-38: Strange queries coming from kiosk-pi - Chrome placing DNS requests with random names



Issue Information

Issue Type: Bug
 
Priority: Major
Status: Closed

Reported By:
Ben Tasker
Assigned To:
Ben Tasker
Project: Miscellaneous (MISC)
Resolution: Fixed (2020-04-08 14:16:14)
Affects Version: Chrome Issues,
Target version: Chrome Issues,
Labels: Chrome, Chromium,

Created: 2020-04-08 09:21:13
Time Spent Working


Description
Yesterday I was running a DNS packet capture on vr1 to look at something else, and noticed that Kiosk Pi (192.168.1.100) seems to be generating quite a lot of DNS noise, looking up seemingly random strings under .home

xrwbuzpvdieklvp.home
pwahmqcdwrise.home
zgyesfuw.home
lltaffmzm


The list changes over time. Aside from the being extremely unlikely names, it almost looks like it's trying to enumerate the zone .home so I'm a bit worried/concerned as to what on there is doing this.

The steps I originally followed to build the Kiosk Pi can be found here - https://www.bentasker.co.uk/documentation/linux/687-building-a-raspberry-pi-based-music-kiosk


Issue Links

Building a Raspberry Pi based Music Kiosk
Chromium Preferences Documentation
Toggle State Changes

Activity


FWIW my bet is that this is going to turn out to be some kind of performance check run by the chrome kiosk instance on that device.
Let's get an idea of the names being queried then
ben@milleniumfalcon:~$ tshark -q -r kiosk-pi-dns-queries.pcap.gz -Y "dns" -T fields -e dns.qry.name | sort | uniq -c
    6 htxjnwhttdbngzf.home
    6 lltaffmzm
    6 mjamlxqrre.home
    6 pwahmqcdwrise
    6 pwahmqcdwrise.home
    6 vbsqraigywoouk
    6 wsqmxgkzgnrto.home
    6 xludgzupz
    6 xrwbuzpvdieklvp
    6 xrwbuzpvdieklvp.home
    6 zgyesfuw
    6 zgyesfuw.home


All being queried against the LAN DNS server (i.e. the DNS server configured at OS level).

It's obviously querying the random string (say zgyesfuw) and when that fails, is then placing a new one within .home (i.e. zgyesfuw.home) because resolv.conf contains domain .home
So, which processes on the Pi are using DNS?
root@jamstashpi1:~# netstat -anp | grep 53
udp        0      0 192.168.1.100:49852     192.168.1.250:53        ESTABLISHED 630/chromium-browse 
udp        0      0 192.168.1.100:60100     192.168.1.250:53        ESTABLISHED 630/chromium-browse 
udp        0      0 192.168.1.100:41167     192.168.1.250:53        ESTABLISHED 630/chromium-browse 
udp        0      0 224.0.0.251:5353        0.0.0.0:*                           630/chromium-browse 
udp        0      0 224.0.0.251:5353        0.0.0.0:*                           591/                
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           300/avahi-daemon: r 
udp        0      0 192.168.1.100:44323     192.168.1.250:53        ESTABLISHED 630/chromium-browse 
udp        0      0 192.168.1.100:42340     192.168.1.250:53        ESTABLISHED 630/chromium-browse 
udp        0      0 192.168.1.100:44404     192.168.1.250:53        ESTABLISHED 630/chromium-browse 
udp        0      0 192.168.1.100:35204     192.168.1.250:53        ESTABLISHED 630/chromium-browse 
udp        0      0 192.168.1.100:57332     192.168.1.250:53        ESTABLISHED 630/chromium-browse 
udp        0      0 192.168.1.100:48662     192.168.1.250:53        ESTABLISHED 630/chromium-browse 
udp        0      0 192.168.1.100:37434     192.168.1.250:53        ESTABLISHED 630/chromium-browse 
udp        0      0 192.168.1.100:48720     192.168.1.250:53        ESTABLISHED 630/chromium-browse 
udp        0      0 192.168.1.100:55895     192.168.1.250:53        ESTABLISHED 630/chromium-browse 
udp6       0      0 2001:8b0:bb6a:f45:60522 2001:8b0:bb6a:f45e:8:53 ESTABLISHED 630/chromium-browse 
udp6       0      0 2001:8b0:bb6a:f45:42104 2001:8b0:bb6a:f45e:8:53 ESTABLISHED 630/chromium-browse 
udp6       0      0 2001:8b0:bb6a:f45:38037 2001:8b0:bb6a:f45e:8:53 ESTABLISHED 630/chromium-browse 
udp6       0      0 2001:8b0:bb6a:f45:45246 2001:8b0:bb6a:f45e:8:53 ESTABLISHED 630/chromium-browse 
udp6       0      0 :::5353                 :::*                                300/avahi-daemon: r 
udp6       0      0 2001:8b0:bb6a:f45:37662 2001:8b0:bb6a:f45e:8:53 ESTABLISHED 630/chromium-browse 
udp6       0      0 2001:8b0:bb6a:f45:53027 2001:8b0:bb6a:f45e:8:53 ESTABLISHED 630/chromium-browse 
udp6       0      0 2001:8b0:bb6a:f45:52096 2001:8b0:bb6a:f45e:8:53 ESTABLISHED 630/chromium-browse 
udp6       0      0 2001:8b0:bb6a:f45:40353 2001:8b0:bb6a:f45e:8:53 ESTABLISHED 630/chromium-browse 
udp6       0      0 2001:8b0:bb6a:f45:36821 2001:8b0:bb6a:f45e:8:53 ESTABLISHED 630/chromium-browse 
udp6       0      0 2001:8b0:bb6a:f45:41999 2001:8b0:bb6a:f45e:8:53 ESTABLISHED 630/chromium-browse 
udp6       0      0 2001:8b0:bb6a:f45:47634 2001:8b0:bb6a:f45e:8:53 ESTABLISHED 630/chromium-browse 
udp6       0      0 2001:8b0:bb6a:f45:37409 2001:8b0:bb6a:f45e:8:53 ESTABLISHED 630/chromium-browse 
unix  2      [ ACC ]     STREAM     LISTENING     15361    548/Xorg             /tmp/.X11-unix/X0
unix  2      [ ACC ]     STREAM     LISTENING     12253    498/systemd          /run/user/1000/gnupg/S.gpg-agent.browser
unix  3      [ ]         STREAM     CONNECTED     13153    565/dbus-daemon      
unix  2      [ ]         DGRAM                    10153    309/cron             
unix  3      [ ]         STREAM     CONNECTED     15363    548/Xorg             
unix  3      [ ]         SEQPACKET  CONNECTED     15553    591/                 
unix  3      [ ]         STREAM     CONNECTED     13653    338/wpa_supplicant   
unix  3      [ ]         STREAM     CONNECTED     15376    498/systemd          


That's a very chrome heavy selection. We only really care about the IPv4 set for now though as the source was `192.168.1.100`. Looks like it is, almost certainly, Chrome then.
There's a Stackexchange Post - https://unix.stackexchange.com/questions/363512/chrome-dns-requests-with-random-dns-names-malware discussing this behaviour.

Beyond the ISP level or malware DNS hijacking the linked Wikipedia entry above, some paid wireless access points or captive portals also hijack DNS. Random requests are made at seemingly random intervals,and not just when starting Chrome. At least, they happen each time the current network interface gets a new IP address.


There's also a quote in there from the chrome source code
Because this function can be called during startup, when kicking off a URL fetch can eat up 20 ms of time, we delay seven seconds, which is hopefully long enough to be after startup, but still get results back quickly.

This component sends requests to three randomly generated, and thus likely nonexistent, hostnames. If at least two redirect to the same hostname, this suggests the ISP is hijacking NXDOMAIN, and the omnibox should treat similar redirected navigations as 'failed' when deciding whether to prompt the user with a 'did you mean to navigate' infobar for certain search inputs.

trigger: "On startup and when IP address of the computer changes."

We generate a random hostname with between 7 and 15 characters.


There's a copy of the source here - https://chromium.googlesource.com/chromium/src/+/lkgr/chrome/browser/intranet_redirect_detector.cc#42

It does seem to imply that it only happens when Chrome is started or the box gets a new IP, but I seem to be seeing it more regularly than that. It's not even aligned with DHCP lease renewals, just seems to be constant
I get the aim, but it seems like unnecessary overhead on a kiosk unit where searches will literally never be performed, there isn't even an omnibox active to enter a search term or URL into.

It's not a massive demand on the DNS server, but I'd still prefer to turn it off if at all possible

There appears to be a pref for it though - https://source.chromium.org/chromium/chromium/src/+/master:chrome/common/pref_names.cc;drc=7bf6998a6433c26266180353473b5153ffab0517;l=1744?originalUrl=https:%2F%2Fcs.chromium.org%2F
// Boolean specifying that the intranet redirect detector should be enabled.
// Defaults to true.
const char kDNSInterceptionChecksEnabled[] =
    "browser.dns_interception_checks_enabled";


So, lets try and set that at chrome startup then see if the DNS queries persist. Need to check if there's an command line switch for it first I guess. Only clone `HEAD` as the repo is massive
ben@milleniumfalcon:/mnt/tmp/tmp$ git clone https://chromium.googlesource.com/chromium/src --depth=1
Cloning into 'src'...
remote: Counting objects: 322486, done
remote: Finding sources: 100% (322486/322486)
remote: Total 322486 (delta 71551), reused 209311 (delta 71551)
Receiving objects: 100% (322486/322486), 975.49 MiB | 6.95 MiB/s, done.
Resolving deltas: 100% (71551/71551), done.
Checking connectivity... done.
Checking out files: 100% (318593/318593), done.


Search for references to it
ben@milleniumfalcon:/mnt/tmp/tmp$ cd src/
ben@milleniumfalcon:/mnt/tmp/tmp/src$ grep -Rl browser.dns_interception_checks_enabled
chrome/common/pref_names.cc
chrome/test/data/policy/policy_test_cases.json


No switch then
Lets edit the Kiosk's profile then
root@jamstashpi1:/home/pi# vi .config/chromium/Default/Preferences


Added the following at the beginning of the JSON
"browser.dns_interception_checks_enabled": false,


As it's a kiosk, rebooting's the easiest way to get the changes live
root@jamstashpi1:~# reboot


Checking port 53 usage
root@jamstashpi1:~# netstat -anp | grep 53
udp        0      0 224.0.0.251:5353        0.0.0.0:*                           644/                
udp        0      0 224.0.0.251:5353        0.0.0.0:*                           696/chromium-browse 
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           316/avahi-daemon: r 
udp6       0      0 :::5353                 :::*                                316/avahi-daemon: r 
unix  2      [ ACC ]     STREAM     LISTENING     11653    486/dhcpcd           /var/run/dhcpcd.sock
unix  3      [ ]         STREAM     CONNECTED     15390    550/xinit            
unix  3      [ ]         STREAM     CONNECTED     15391    551/Xorg             @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     15453    644/                 
unix  3      [ ]         STREAM     CONNECTED     15395    1/init               /run/systemd/journal/stdout
unix  2      [ ]         DGRAM                    8538     143/systemd-udevd    
unix  3      [ ]         STREAM     CONNECTED     8534     143/systemd-udevd    
unix  3      [ ]         STREAM     CONNECTED     9953     1/init               /run/systemd/journal/stdout


And running a capture on the DNS server to confirm
root@VR1:~# tcpdump -i any -v port 53 and host 192.168.1.100
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
12:44:40.806406 IP (tos 0x0, ttl 64, id 36311, offset 0, flags [DF], proto UDP (17), length 70)
    kioskpi1-wifi.60553 > vr1.domain: 18946+ A? subsonicser.bentasker.co.uk. (42)
12:44:40.806486 IP (tos 0x0, ttl 64, id 36312, offset 0, flags [DF], proto UDP (17), length 70)
    kioskpi1-wifi.60553 > vr1.domain: 20482+ AAAA? subsonicser.bentasker.co.uk. (42)
12:44:40.806644 IP (tos 0x0, ttl 64, id 2418, offset 0, flags [none], proto UDP (17), length 86)
    vr1.domain > kioskpi1-wifi.60553: 18946* 1/0/0 subsonicser.bentasker.co.uk. A 192.168.1.5 (58)
12:44:40.806747 IP (tos 0x0, ttl 64, id 2419, offset 0, flags [none], proto UDP (17), length 70)
    vr1.domain > kioskpi1-wifi.60553: 20482* 0/0/0 (42)
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel


Perfect.
For completeness, current package versions are
root@jamstashpi1:~# dpkg-query --list | grep chromi
ii  chromium-browser                  78.0.3904.108-rpt1             armhf        Chromium web browser, open-source version of Chrome
ii  chromium-codecs-ffmpeg-extra      78.0.3904.108-rpt1             armhf        Extra ffmpeg codecs for the Chromium Browser
I've updated the title to refer to Chrome so I've half a chance of finding this issue again in future.
btasker changed Project from 'Home LAN' to 'Miscellaneous'
btasker changed Key from 'LAN-149' to 'MISC-38'
btasker added 'Chrome Chromium' to labels
btasker added 'Chrome Issues' to Fix Version
btasker added 'Chrome Issues' to Version
Moved into project MISC as it's a general Chrome issue (I guess it's behaving as designed, so not a bug as such)
btasker changed status from 'Open' to 'Resolved'
btasker added 'Fixed' to resolution
btasker changed status from 'Resolved' to 'Closed'
It does seem to imply that it only happens when Chrome is started or the box gets a new IP, but I seem to be seeing it more regularly than that. It's not even aligned with DHCP lease renewals, just seems to be constant


The idea that it's only at network change is demonstrably false - one of the laptops has Chrome open and it's hitting DNS with these names every 15 seconds or so.
Funnily enough, this "feature" has made it's way into the news - https://arstechnica.com/gadgets/2020/08/a-chrome-feature-is-creating-enormous-load-on-global-root-dns-servers/

The feature apparently now contributes to half the load on the root DNS servers (or, at the very least, on Verisign's), generating about 60 billion junk queries a day. There's also a write-up on the APNIC blog here: https://blog.apnic.net/2020/08/21/chromiums-impact-on-root-dns-traffic/

There's a Chromium bug open to disable the Intranet Redirect Detector by default - https://bugs.chromium.org/p/chromium/issues/detail?id=1090985 - and to have enterprises enable it (if they need it) using GPO.

<grumble>
This really is just another problem with the flawed idea that the Omnibox should be a one-stop shop. It's that combined with behaviour like this that causes privacy leaks (for example https://bugs.chromium.org/p/chromium/issues/detail?id=479620)
</grumble>