* 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