* Insecure hostname in nsm_make_temp_pathname @ 2024-11-11 22:49 Philip Rowlands 2024-11-12 14:01 ` Chuck Lever III 2024-11-12 14:27 ` Benjamin Coddington 0 siblings, 2 replies; 6+ messages in thread From: Philip Rowlands @ 2024-11-11 22:49 UTC (permalink / raw) To: linux-nfs 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. Cheers, Phil ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Insecure hostname in nsm_make_temp_pathname 2024-11-11 22:49 Insecure hostname in nsm_make_temp_pathname Philip Rowlands @ 2024-11-12 14:01 ` Chuck Lever III 2024-11-12 14:27 ` Benjamin Coddington 1 sibling, 0 replies; 6+ messages in thread From: Chuck Lever III @ 2024-11-12 14:01 UTC (permalink / raw) To: Philip Rowlands, Steve Dickson; +Cc: Linux NFS Mailing List > On Nov 11, 2024, at 5:49 PM, Philip Rowlands <linux-nfs@dimebar.com> 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 Indeed, wikipedia provides a non-authoritative listing of top-level domains that includes ".new" as a valid TLD owned by Google: https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains It should be a one-line patch to replace the temp suffix with characters that are not valid in a domain name. > 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. > > > Cheers, > Phil > -- Chuck Lever ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Insecure hostname in nsm_make_temp_pathname 2024-11-11 22:49 Insecure hostname in nsm_make_temp_pathname Philip Rowlands 2024-11-12 14:01 ` Chuck Lever III @ 2024-11-12 14:27 ` Benjamin Coddington 2024-11-12 14:41 ` Chuck Lever 1 sibling, 1 reply; 6+ messages in thread From: Benjamin Coddington @ 2024-11-12 14:27 UTC (permalink / raw) To: Philip Rowlands, Chuck Lever; +Cc: linux-nfs 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? diff --git a/support/nsm/file.c b/support/nsm/file.c index f5b448015751..eaf19cd4963e 100644 --- a/support/nsm/file.c +++ b/support/nsm/file.c @@ -185,9 +185,9 @@ nsm_make_temp_pathname(const char *pathname) { size_t size; char *path; - int len; + int le; - size = strlen(pathname) + sizeof(".new") + 2; + size = strlen(pathname) + sizeof(".new") + 3; if (size > PATH_MAX) return NULL; @@ -195,7 +195,7 @@ nsm_make_temp_pathname(const char *pathname) if (path == NULL) return NULL; - len = snprintf(path, size, "%s.new", pathname); + len = snprintf(path, size, ".%s.new", pathname); if (error_check(len, size)) { free(path); return NULL; ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: Insecure hostname in nsm_make_temp_pathname 2024-11-12 14:27 ` Benjamin Coddington @ 2024-11-12 14:41 ` Chuck Lever 2024-11-12 14:59 ` Benjamin Coddington 0 siblings, 1 reply; 6+ messages in thread From: Chuck Lever @ 2024-11-12 14:41 UTC (permalink / raw) To: Benjamin Coddington; +Cc: Philip Rowlands, linux-nfs 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. 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>" > diff --git a/support/nsm/file.c b/support/nsm/file.c > index f5b448015751..eaf19cd4963e 100644 > --- a/support/nsm/file.c > +++ b/support/nsm/file.c > @@ -185,9 +185,9 @@ nsm_make_temp_pathname(const char *pathname) > { > size_t size; > char *path; > - int len; > + int le; > > - size = strlen(pathname) + sizeof(".new") + 2; > + size = strlen(pathname) + sizeof(".new") + 3; > if (size > PATH_MAX) > return NULL; > > @@ -195,7 +195,7 @@ nsm_make_temp_pathname(const char *pathname) > if (path == NULL) > return NULL; > > - len = snprintf(path, size, "%s.new", pathname); > + len = snprintf(path, size, ".%s.new", pathname); > if (error_check(len, size)) { > free(path); > return NULL; > -- Chuck Lever ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Insecure hostname in nsm_make_temp_pathname 2024-11-12 14:41 ` Chuck Lever @ 2024-11-12 14:59 ` Benjamin Coddington 2024-11-12 15:03 ` Chuck Lever III 0 siblings, 1 reply; 6+ messages in thread From: Benjamin Coddington @ 2024-11-12 14:59 UTC (permalink / raw) To: Chuck Lever; +Cc: Philip Rowlands, linux-nfs 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? Thanks for chiming in here! Ben ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Insecure hostname in nsm_make_temp_pathname 2024-11-12 14:59 ` Benjamin Coddington @ 2024-11-12 15:03 ` Chuck Lever III 0 siblings, 0 replies; 6+ messages in thread From: Chuck Lever III @ 2024-11-12 15:03 UTC (permalink / raw) To: Benjamin Coddington; +Cc: Philip Rowlands, Linux NFS Mailing List > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-11-12 15:03 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-11-11 22:49 Insecure hostname in nsm_make_temp_pathname Philip Rowlands 2024-11-12 14:01 ` Chuck Lever III 2024-11-12 14:27 ` Benjamin Coddington 2024-11-12 14:41 ` Chuck Lever 2024-11-12 14:59 ` Benjamin Coddington 2024-11-12 15:03 ` Chuck Lever III
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox