Bug 225668
| Summary: | tcsh: reads /etc/hosts and calls name resolution erroneously to find REMOTEHOST | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | feh | ||||
| Component: | bin | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||
| Status: | Open --- | ||||||
| Severity: | Affects Many People | CC: | cem, jilles | ||||
| Priority: | --- | ||||||
| Version: | 11.1-RELEASE | ||||||
| Hardware: | amd64 | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
Using ktrace -i on a su command, I found that it is not su, but csh that does these strange DNS requests. The code tries to set the REMOTEHOST environment variable and is in contrib/tcsh/tc.func.c getremotehost(). This exact problem is called out in a comment: /* * There is conflict with IPv6 address and X DISPLAY. So, * we assume there is no IPv6 address in utmp and don't * touch here. */ However, the assumption is wrong. There can be IPv6 addresses in utmp(x). A simple fix would be to use inet_pton() or getaddrinfo() with AI_NUMERICHOST to check for an IPv6 (or also IPv4) address, and to skip the X DISPLAY handling in that case. This fix should be submitted to the upstream tcsh project first. However, perhaps we want to eliminate more obsolete code here. The name of the remote host is rather less important now for shell startup files than it used to be when the code was written (such as to deal with terminal settings). It may be sufficient to extract a hostname from the utmp host without touching DNS at all. Fortunately, there is a 2 second timeout on finding the remote hostname, so it will not prevent you from logging in. The "leaked" information is just the top 16 bits of the IPv6 address together with the local DNS domain; perhaps the most important part is that you su'ed at that time. |
Created attachment 190321 [details] My /etc/hosts file + /etc/resolv.conf + capture of the name lookup following the 'su' command Hi, upon calling 'su', su does the following: - it reads /etc/hosts, - it misinterprets an entry here with a colon as token in the first column, - it uses a DNS stub resolver to forward this crippled name for unqualified name resolution. Given this behaviour, 'su' leaks information via DNS. After forwarding the information to a DNS cache server, the initial call of 'su' waits for a time-out (about 500 msec). Usually, the cache server returns NXDOMAIN following his cache, 'su' seems to work faster the following calls. Attached you will find a documentation of this behaviour. Regards. --eh.