Re: Insecure hostname in nsm_make_temp_pathname

[Chuck Lever III <chuck.lever@oracle.com>]

> On Nov 12, 2024, at 9:59 AM, Benjamin Coddington <bcodding@redhat.com> wrote:
> 
> On 12 Nov 2024, at 9:41, Chuck Lever wrote:
> 
>> On Tue, Nov 12, 2024 at 09:27:45AM -0500, Benjamin Coddington wrote:
>>> On 11 Nov 2024, at 17:49, Philip Rowlands wrote:
>>> 
>>>> If a host dies after nsm_make_temp_pathname but before rename(temp, path) we may be left with paths resembling .../server.example.com.new
>>>> 
>>>> Some clever person has registered and installed a wildcard DNS record for *.com.new.
>>>> 
>>>> $ host server.example.com.new
>>>> server.example.com.new has address 104.21.68.132
>>>> server.example.com.new has address 172.67.195.202
>>>> 
>>>> You can see where this is going...
>>>> 
>>>> Our firewall scanners tripped on outbound access to this address, port 111, I assume due to NSM reboot notifications.
>>>> 
>>>> Suggested workarounds include:
>>>> * explicitly skip over paths matching the expect tempname pattern in nsm_load_dir()
>>>> * use a different tmp suffix than .new, e.g. one which won't work in DNS
>>>> 
>>>> Steps to reproduce:
>>>> 
>>>> # cat /var/lib/nfs/statd/sm/server.example.com.new
>>>> 0100007f 000186b5 00000003 00000010 89ae3382e989d91800000000dc00ed000000ffff 1.2.3.4 my-client-name
>>>> # sm-notify -d -f -n
>>>> sm-notify: Version 2.7.1 starting
>>>> sm-notify: Retired record for mon_name server.example.com.new
>>>> sm-notify: Added host server.example.com.new to notify list
>>>> sm-notify: Initializing NSM state
>>>> sm-notify: Failed to open /proc/sys/fs/nfs/nsm_local_state: No such file or directory
>>>> sm-notify: Effective UID, GID: 29, 29
>>>> sm-notify: Sending PMAP_GETPORT for 100024, 1, udp
>>>> sm-notify: Added host server.example.com.new to notify list
>>>> sm-notify: Host server.example.com.new due in 2 seconds
>>>> sm-notify: Sending PMAP_GETPORT for 100024, 1, udp
>>>> # etc.
>>>> 
>>>> tcpdump shows the outbound traffic:
>>>> 22:42:31.940208 IP 192.168.0.131.819 > 172.67.195.202.sunrpc: UDP, length 56
>>>> 22:42:33.942440 IP 192.168.0.131.819 > 172.67.195.202.sunrpc: UDP, length 56
>>>> 22:42:37.946903 IP 192.168.0.131.819 > 172.67.195.202.sunrpc: UDP, length 56
>>>> 
>>>> The client statd was artificially placed for the purposes of showing the problem, but I hope it's close enough to make sense.
>>> 
>>> Makes sense.. yikes!
>>> 
>>> Maybe we could just prepend '.' since nsm_load_dir() ignores those - Chuck, you were in here last any thoughts?
>> 
>> The problem with a leading dot is, of course, the file becomes
>> hidden, which might be surprising to administrators who are trying
>> to diagnose a problem.
> 
> I used to be one of those, and would say this isn't a big issue for any
> competent admin.  It has another advantage of also never being a valid DNS
> name because it has an "empty label".
> 
>> Note that a domain label can contain only the letters A-Z (or a-z),
>> the digits 0-9, hyphen (-), and dot (.). So replace ".new" with
>> something that contains an invalid character like ".<new>"
> 
> Hmm.. I thought (goes to dig it up) that any binary string can serve as a
> name representation.  https://datatracker.ietf.org/doc/html/rfc2181#section-11
> 
> ..that's been updated by a number of other RFCs.. (gah! - case insensitive
> comparisons!)  I admit to not knowing or wanting to keep digging through RFCs
> for the current domain label specification.  Do you have a current reference
> and feel like we can depend on it?

If we expect to have to support IDNA as well, then I guess
"<" and ">" aren't going to be enough.

Prepending a dot to the temporary name is workable.


--
Chuck Lever