TNFSD Directory Listing Vulnerability

mozzwald · February 8

A vulnerability has been found in the TNFSD server that can allow a person to get directory listings outside of the configured TNFS root directory. We were notified of the issue on Jan 31, 2023 and have been working on a fix since that time. The fix is now available as source code and binaries in our Github repo (https://github.com/FujiNetWIFI/spectranet). Binaries at https://fujinet.online/download have also been updated. Anyone running a publicly available TNFS server should update their TNFSD server immediately.

The issue occurs when requesting a directory listing with ".." which can allow viewing the file listing in directories above the TNFS root. In our testing we were not able to download or view contents of any files outside of the TNFS root, only get directory listings. The bugfix compares the absolute path of the TNFS root directory with the absolute path of the requested directory and if the requested directory is not inside the TNFS root it will return a listing of the root directory instead. This has been tested on Windows 10 64Bit, Linux 64bit and Raspberry Pi 3B+ armhf.

We have also overlooked the fact that the Linux version of TNFSD has built in chroot capabilities already which would prevent this bug from happening in the old vulnerable version. Linux users can run the server with the '-c [username]' flag to start it in it's own chroot (ex: sudo tnfsd /home/tnfs -c tnfs) and we recommend using this option going forward. Windows users do not have the chroot option and must use the updated TNFSD binary.

For Linux users running the server with systemd, this is an example script with chroot:

[Unit]
Description=TNFS Server
After=remote-fs.target
After=syslog.target

# replace /tnfs with your TNFS directory

[Service]
User=root
Group=root
ExecStart=/usr/local/sbin/tnfsd /tnfs -c tnfs

[Install]
WantedBy=multi-user.target

We hope our transparency and action to fix the issue shows our commitment to security and to keeping your trust. Thank you for your understanding.

tsom · February 8

I installed my TNFS server onto my raspberry pi using the packaged image posted on here, somewhere (I forget who had set it up). It has a "tnfsupd" script that looks to go out to Github and update itself. It looks like it successfully did, but I'm not sure how to tell if it's the latest version:

```

pi@tnfs:~ $ sudo tnfsupd
Stopping TNFSD
Updating TNFSD fom GitHub
Restarting TNFSD
pi@tnfs:~ $ tnfsd -v
Starting tnfsd version 20.1115.2 using root directory "-v"
Unable to bind

```

My systemd setup has this:

```

[Service]
User=tnfs
Group=tnfs
ExecStart=/usr/local/sbin/tnfsd /tnfs

```

I assume it's ok? (it's also not visible outside my network, so it may be a moot point)

Also, looking at the GitHub link, the releases linked there look very old

Just want to make sure the latest version is available.

Thanks!

tsom · February 8

Well, the script didn't do the update, as it assumes the code was already downloaded. I ended up doing the steps in the script manually, after cloning the repo and was able to update my local server.

mozzwald · February 8

@tsom the latest version is 23.0207.1 which is displayed when started.

tsom · February 8

Yep. All good now:

```

pi@tnfs:~ $ systemctl status tnfsd
● tnfsd.service - TNFS Server
   Loaded: loaded (/etc/systemd/system/tnfsd.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2023-02-08 08:47:19 EST; 2h 7min ago
 Main PID: 29144 (tnfsd)
    Tasks: 1 (limit: 2178)
   CGroup: /system.slice/tnfsd.service
           └─29144 /usr/local/sbin/tnfsd /tnfs
Feb 08 08:47:19 tnfs systemd[1]: Started TNFS Server.
Feb 08 08:47:19 tnfs tnfsd[29144]: setroot real path: /tnfs
Feb 08 08:47:19 tnfs tnfsd[29144]: Starting tnfsd version 23.0207.1 using root directory "/tnfs"

```

Edited February 8 by tsom

moonlight_mile · February 13

Dumb question. Would this be an issue on a tnfs server running in a docker container? If so will an updated container image be available?

mozzwald · February 13

41 minutes ago, moonlight_mile said:

Dumb question. Would this be an issue on a tnfs server running in a docker container? If so will an updated container image be available?

This would be an issue with any way you run the old TNFS server. I not that familiar with docker. Maybe you can just shut it down and replace the binary inside the container?

moonlight_mile · February 14

I will just take down the Alcatraz server until I can figure out how to update the binary. Pretty busy now. Will work on it.

thanks!

_The Doctor__ · February 14

is it noted who made the docker versions? might be in the threads somewhere. maybe they can do it again, or give a step by step on what a person needs to do in order to create their own from here on out.

Edited February 14 by _The Doctor__

moonlight_mile · February 14

Thomas cherryholmes I am pretty sure. Tschak909

_The Doctor__ · February 14

Sounds like it should be or should have been handled already, I'd give him PM, DM, or Discord shout etc.

Seems someone pointed issues of this nature out back when this was all chugging along, So it would be good to see such stuff being addressed.

Edited February 14 by _The Doctor__

moonlight_mile · February 14

I know I pulled a newer version of the container image I just haven’t had a chance to look into it too closely. Let me know if the “-latest” version has the bug fix in it.

thanks!

mozzwald · February 14

@moonlight_mile the x64 docker image was update by @tschak909

https://hub.docker.com/r/tschak909/tnfsd-x64

moonlight_mile · February 14

That was the one I downloaded. Thanks so much. I will deploy it asap.

+x=usr(1536) · February 19

On 2/8/2023 at 7:32 AM, tsom said:

I installed my TNFS server onto my raspberry pi using the packaged image posted on here, somewhere (I forget who had set it up). It has a "tnfsupd" script that looks to go out to Github and update itself. It looks like it successfully did, but I'm not sure how to tell if it's the latest version:

```

pi@tnfs:~ $ sudo tnfsupd
Stopping TNFSD
Updating TNFSD fom GitHub
Restarting TNFSD
pi@tnfs:~ $ tnfsd -v
Starting tnfsd version 20.1115.2 using root directory "-v"
Unable to bind

20.1115.2 is outdated. 23.0207.1 is current as of this writing; I just built it out of the source repo, so it's definitely the latest.

If you do a `systemctl status tnfsd`, you should see the following output if you're up to date:

● tnfsd.service - tnfs Daemon

Loaded: loaded (/etc/systemd/system/tnfsd.service; enabled; vendor preset:>

Active: active (running) since Sun 2023-02-19 07:44:18 CST; 1min 13s ago

Main PID: 45768 (tnfsd)

Tasks: 1 (limit: 4675)

Memory: 176.0K

CPU: 1ms

CGroup: /system.slice/tnfsd.service

└─45768 /usr/local/bin/tnfsd /mnt/tnfs/atari/

Feb 19 07:44:18 tnfs systemd[1]: Started tnfs Daemon.

Feb 19 07:44:18 tnfs tnfsd[45768]: Starting tnfsd version 23.0207.1 using root

On 2/8/2023 at 7:32 AM, tsom said:

My systemd setup has this:

```

[Service]
User=tnfs
Group=tnfs
ExecStart=/usr/local/sbin/tnfsd /tnfs

```

Sort of. I'd strongly recommend starting tnfsd with the -c option, however. More:

On 2/8/2023 at 7:32 AM, tsom said:

I assume it's ok? (it's also not visible outside my network, so it may be a moot point)

Your network so your call, but it's generally not good practice to leave known vulnerabilities unmitigated once they are discovered and confirmed present in the environment. You'll need weigh the risk of patching vs. not patching for yourself, but if I were in your shoes I'd absolutely do it, public-facing server or not.

Getting back to the systemd service file configuration for a moment: while it can be equivalent to starting tnfsd with the -c option, that is also going to be dependent on certain external factors. Most relevant will be file ownership and permissions on /tnfs, which users are part of the tnfs group, whether or not those users have login capabilities, etc. Assuming that all of these items (and others) are addressed properly, then yes, that configuration should be OK.

However, given that tnfsd now specifies a best practice for both the configuration of its service file as well as a startup method, it's probably easiest to move to doing things the current way. Chances are solid that it's not going to revert to the old method.

Note that I'm not using the RasPi build, so am not aware of how it may have been configured in regards to the items I've mentioned. Knowing who put it together, however, it's a fairly safe bet that it was done properly.

On 2/8/2023 at 7:32 AM, tsom said:

Also, looking at the GitHub link, the releases linked there look very old

Looks updated to me - check the FujiNetWIFI/spectranet Github page, which should show the tnfsd directory is as having been updated two weeks ago, which is correct based on when I'm writing this. To be fair, it's easy to miss given the number of things around it that haven't been touched as recently.

+x=usr(1536) · February 19

On 2/7/2023 at 7:50 PM, mozzwald said:

We hope our transparency and action to fix the issue shows our commitment to security and to keeping your trust. Thank you for your understanding.

My thanks to everyone who handled this. Seeing a solid commitment to security is a huge positive for the project.

Out of curiosity, has anyone looked into the possibility of having tnfsd included in some distros' official repos? That would help with the updating aspect, for sure, and potentially widen the userbase.

tschak909 · February 20

On 2/19/2023 at 8:37 AM, x=usr(1536) said:

My thanks to everyone who handled this. Seeing a solid commitment to security is a huge positive for the project.

Out of curiosity, has anyone looked into the possibility of having tnfsd included in some distros' official repos? That would help with the updating aspect, for sure, and potentially widen the userbase.

If you can help there, please do so.

-Thom

E474 · February 20

Hi,

Newbie question. I have an RPi (3B) install from source from Jan 2022. Do I do:

$ git clone https://github.com/FujiNetWIFI/spectranet

to over-write the existing (outdated) sources, or should I just delete the current sources and redo the git clone?

+x=usr(1536) · February 20

1 hour ago, tschak909 said:

If you can help there, please do so.

That's actually something I've never had to do before Let me see if I can't figure it out; I'm actually curious as to how that process works and the worst that happens is that I get a bunch of 'no' responses.

tschak909 · February 20

1 hour ago, E474 said:

Hi,

Newbie question. I have an RPi (3B) install from source from Jan 2022. Do I do:

$ git clone https://github.com/FujiNetWIFI/spectranet

to over-write the existing (outdated) sources, or should I just delete the current sources and redo the git clone?

if you cloned from git?

$ git pull

-Thom

E474 · February 22

Hi @tschak909,

Thanks very much for the info. Unfortunately I've encountered some problems, I'm assuming this is a user error, but giving feedback in case otherwise:

pi@pi3bp2:~/spectranet $ git pull
hint: Pulling without specifying how to reconcile divergent branches is
hint: discouraged. You can squelch this message by running one of the following
hint: commands sometime before your next pull:
hint: 
hint:   git config pull.rebase false  # merge (the default strategy)
hint:   git config pull.rebase true   # rebase
hint:   git config pull.ff only       # fast-forward only
hint: 
hint: You can replace "git config" with "git config --global" to set a default
hint: preference for all repositories. You can also pass --rebase, --no-rebase,
hint: or --ff-only on the command line to override the configured default per
hint: invocation.
remote: Enumerating objects: 43, done.
remote: Counting objects: 100% (43/43), done.
remote: Compressing objects: 100% (25/25), done.
remote: Total 43 (delta 25), reused 34 (delta 18), pack-reused 0
Unpacking objects: 100% (43/43), 263.62 KiB | 629.00 KiB/s, done.
From https://github.com/FujiNetWIFI/spectranet
   4157ecb..95c5b55  master     -> origin/master
Updating 4157ecb..95c5b55
error: Your local changes to the following files would be overwritten by merge:
        tnfs/tnfsd/bin/tnfsd
Please commit your changes or stash them before you merge.
Aborting

I figured it was simplest to remove the binary it was complaining about, after which it worked, as shown below:

pi@pi3bp2:~/spectranet $ git pull
hint: Pulling without specifying how to reconcile divergent branches is
hint: discouraged. You can squelch this message by running one of the following
hint: commands sometime before your next pull:
hint: 
hint:   git config pull.rebase false  # merge (the default strategy)
hint:   git config pull.rebase true   # rebase
hint:   git config pull.ff only       # fast-forward only
hint: 
hint: You can replace "git config" with "git config --global" to set a default
hint: preference for all repositories. You can also pass --rebase, --no-rebase,
hint: or --ff-only on the command line to override the configured default per
hint: invocation.
Updating 4157ecb..95c5b55
Fast-forward
 tnfs/tnfsd/bin/tnfsd         | Bin 85560 -> 0 bytes
 tnfs/tnfsd/bin/tnfsd.armhf   | Bin 0 -> 79860 bytes
 tnfs/tnfsd/bin/tnfsd.exe     | Bin 294364 -> 368984 bytes
 tnfs/tnfsd/bin/tnfsd.linux64 | Bin 0 -> 96840 bytes
 tnfs/tnfsd/datagram.c        |  21 ++++++++++++++++-----
 tnfs/tnfsd/datagram.h        |   1 +
 tnfs/tnfsd/directory.c       |  72 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------
 tnfs/tnfsd/directory.h       |   5 ++++-
 tnfs/tnfsd/errortable.h      |   1 +
 tnfs/tnfsd/main.c            |   2 +-
 tnfs/tnfsd/tnfs_file.c       |  23 +++++++++++++++++++++--
 11 files changed, 109 insertions(+), 16 deletions(-)
 delete mode 100755 tnfs/tnfsd/bin/tnfsd
 create mode 100644 tnfs/tnfsd/bin/tnfsd.armhf
 mode change 100644 => 100755 tnfs/tnfsd/bin/tnfsd.exe
 create mode 100755 tnfs/tnfsd/bin/tnfsd.linux64

Then, following on from the instructions at: https://github.com/FujiNetWIFI/spectranet - I did a make, but got:

pi@pi3bp2:~/spectranet $ make
make -C syslib
make[1]: Entering directory '/home/pi/spectranet/syslib'
z80-unknown-coff-as -I../include ui_menu.asm -o ui_menu.o
make[1]: z80-unknown-coff-as: No such file or directory
make[1]: *** [Makefile:46: ui_menu.o] Error 127
make[1]: Leaving directory '/home/pi/spectranet/syslib'
make: *** [Makefile:15: syslib] Error 2

I tried make clean:

for dir in syslib rom modules installer utils; do \
        make -C $dir clean; \
done
make[1]: Entering directory '/home/pi/spectranet/syslib'
rm -f -f *.o *.a
make[1]: Leaving directory '/home/pi/spectranet/syslib'
make[1]: Entering directory '/home/pi/spectranet/rom'
rm -f *.o *.module *.bin *.map *.xinc *.tzx *.tap
make[1]: Leaving directory '/home/pi/spectranet/rom'
make[1]: Entering directory '/home/pi/spectranet/modules'
for dir in snapman messages config basext streams allram; do \
        make -C $dir clean; \
done
make[2]: Entering directory '/home/pi/spectranet/modules/snapman'
rm -f *.o *.module *.bin *.map
make[2]: Leaving directory '/home/pi/spectranet/modules/snapman'
make[2]: Entering directory '/home/pi/spectranet/modules/messages'
rm -f *.o *.module *.bin *.map
make[2]: Leaving directory '/home/pi/spectranet/modules/messages'
make[2]: Entering directory '/home/pi/spectranet/modules/config'
rm -f *.o *.module *.bin *.map
make[2]: Leaving directory '/home/pi/spectranet/modules/config'
make[2]: Entering directory '/home/pi/spectranet/modules/basext'
rm -f *.o *.module *.bin *.map
make[2]: Leaving directory '/home/pi/spectranet/modules/basext'
make[2]: Entering directory '/home/pi/spectranet/modules/streams'
rm -f *.o *.module *.bin *.map
make[2]: Leaving directory '/home/pi/spectranet/modules/streams'
make[2]: Entering directory '/home/pi/spectranet/modules/allram'
rm -f *.o *.module *.bin *.map
make[2]: Leaving directory '/home/pi/spectranet/modules/allram'
make[1]: Leaving directory '/home/pi/spectranet/modules'
make[1]: Entering directory '/home/pi/spectranet/installer'
rm -f *.o *.module *.bin *.map *.xinc *.tzx *.tap
make[1]: Leaving directory '/home/pi/spectranet/installer'
make[1]: Entering directory '/home/pi/spectranet/utils'
rm -f bin2tape bin2tape.o configserv configserv.o
make[1]: Leaving directory '/home/pi/spectranet/utils'

Then tried make again, but got the same as previously:

pi@pi3bp2:~/spectranet $ make
make -C syslib
make[1]: Entering directory '/home/pi/spectranet/syslib'
z80-unknown-coff-as -I../include ui_menu.asm -o ui_menu.o
make[1]: z80-unknown-coff-as: No such file or directory
make[1]: *** [Makefile:46: ui_menu.o] Error 127
make[1]: Leaving directory '/home/pi/spectranet/syslib'
make: *** [Makefile:15: syslib] Error 2

I figure I am missing the assembler, but I'm not sure what the correct dependencies/packages are, and I couldn't find anything in the README.TXT at https://github.com/FujiNetWIFI/spectranet

I'm reasonably sure the previous install was from git, but can't be 100% certain as it was over a year ago (there was a .git folder there already, I assume that's not included in the .zip). I tested that the tnfsd server worked by booting via FujiNet-PC before starting the upgrade, so I'm sure it was working originally.

Any help would be appreciated, I'm expecting it's a user error, but don't want to guesswork my way to in incorrect, but working, fix.

mozzwald · February 23

1 hour ago, E474 said:

Any help would be appreciated, I'm expecting it's a user error, but don't want to guesswork my way to in incorrect, but working, fix.

You're almost there... just move to the tnfsd directory and run make from there

cd ~/spectranet/tnfs/tnfsd
make OS=LINUX DEBUG=1

You can leave off the DEBUG flag if you don't want the extra messages but you still need the OS flag

E474 · February 23

Hi @mozzwald,

Thanks very much, that built the binary!

pi@pi3bp2:~/spectranet/tnfs/tnfsd $ make OS=LINUX
gcc -Wall -DUNIX -DNEED_BSDCOMPAT -DENABLE_CHROOT -DNEED_ERRTABLE     -c -o main.o main.c
gcc -Wall -DUNIX -DNEED_BSDCOMPAT -DENABLE_CHROOT -DNEED_ERRTABLE     -c -o datagram.o datagram.c
datagram.c: In function ‘tcp_accept’:
datagram.c:231:61: warning: pointer targets in passing argument 3 of ‘accept’ differ in signedness [-Wpointer-sign]
  231 |  acc_fd = accept(tcplistenfd, (struct sockaddr *)&cli_addr, &cli_len);
      |                                                             ^~~~~~~~
      |                                                             |
      |                                                             int32_t * {aka int *}
In file included from datagram.c:34:
/usr/include/arm-linux-gnueabihf/sys/socket.h:233:28: note: expected ‘socklen_t * restrict’ {aka ‘unsigned int * restrict’} but argument is of type ‘int32_t *’ {aka ‘int *’}
  233 |      socklen_t *__restrict __addr_len);
      |      ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
datagram.c: In function ‘tnfs_handle_udpmsg’:
datagram.c:260:38: warning: pointer targets in passing argument 6 of ‘recvfrom’ differ in signedness [-Wpointer-sign]
  260 |         (struct sockaddr *)&cliaddr, &len);
      |                                      ^~~~
      |                                      |
      |                                      int32_t * {aka int *}
In file included from datagram.c:34:
/usr/include/arm-linux-gnueabihf/sys/socket.h:165:27: note: expected ‘socklen_t * restrict’ {aka ‘unsigned int * restrict’} but argument is of type ‘int32_t *’ {aka ‘int *’}
  165 |     socklen_t *__restrict __addr_len);
      |     ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
gcc -Wall -DUNIX -DNEED_BSDCOMPAT -DENABLE_CHROOT -DNEED_ERRTABLE     -c -o directory.o directory.c
directory.c: In function ‘_load_directory’:
directory.c:663:45: warning: ‘%s’ directive output may be truncated writing up to 255 bytes into a region of size between 0 and 255 [-Wformat-truncation=]
  663 |   snprintf(statpath, sizeof(statpath), "%s%c%s", dirh->path, FILEINFO_PATHSEPARATOR, entry->d_name);
      |                                             ^~
directory.c:663:3: note: ‘snprintf’ output between 2 and 512 bytes into a destination of size 256
  663 |   snprintf(statpath, sizeof(statpath), "%s%c%s", dirh->path, FILEINFO_PATHSEPARATOR, entry->d_name);
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gcc -Wall -DUNIX -DNEED_BSDCOMPAT -DENABLE_CHROOT -DNEED_ERRTABLE     -c -o tnfs_file.o tnfs_file.c
gcc -o bin/tnfsd main.o datagram.o log.o session.o endian.o directory.o errortable.o tnfs_file.o chroot.o fileinfo.o strlcpy.o strlcat.o

I copied in the resulting tnfsd to the correct location:

pi@pi3bp2:~/spectranet/tnfs/tnfsd/bin $ sudo cp tnfsd /usr/local/sbin/

And edited the tnfsd.service file:

pi@pi3bp2:~/spectranet/tnfs/tnfsd/bin $ more /etc/systemd/system/tnfsd.service
[Unit]
Description=TNFS Server
After=remote-fs.target
After=syslog.target

[Service]
User=tnfs
Group=tnfs
ExecStart=/usr/local/sbin/tnfsd /tnfs -c tnfs

[Install]
WantedBy=multi-user.target

I got a complaint when I started the tnfsd server:

pi@pi3bp2:~/spectranet/tnfs/tnfsd/bin $ sudo systemctl start tnfsd 
Warning: The unit file, source configuration file or drop-ins of tnfsd.service changed on disk. Run 'systemctl daemon-reload' to reload units.

Then another complaint after the daemon-reload:

pi@pi3bp2:~/spectranet/tnfs/tnfsd/bin $ sudo systemctl daemon-reload 
pi@pi3bp2:~/spectranet/tnfs/tnfsd/bin $ sudo systemctl start tnfsd
pi@pi3bp2:~/spectranet/tnfs/tnfsd/bin $ sudo systemctl status tnfsd
● tnfsd.service - TNFS Server
     Loaded: loaded (/etc/systemd/system/tnfsd.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2023-02-23 00:53:50 WET; 41s ago
   Main PID: 14252 (tnfsd)
      Tasks: 1 (limit: 1596)
        CPU: 12ms
     CGroup: /system.slice/tnfsd.service
             └─14252 /usr/local/sbin/tnfsd /tnfs

Feb 23 00:53:50 pi3bp2 systemd[1]: Started TNFS Server.
Feb 23 00:53:50 pi3bp2 tnfsd[14252]: Starting tnfsd version 23.0207.1 using root directory "/tnfs"
Feb 23 00:54:22 pi3bp2 systemd[1]: tnfsd.service: Current command vanished from the unit file, execution of the command list won't be resumed.

So tried disabling/enabling it, but am now getting a failed state:

pi@pi3bp2:~/spectranet/tnfs/tnfsd/bin $ sudo systemctl stop tnfsd
pi@pi3bp2:~/spectranet/tnfs/tnfsd/bin $ sudo systemctl disable tnfsd
Removed /etc/systemd/system/multi-user.target.wants/tnfsd.service.
pi@pi3bp2:~/spectranet/tnfs/tnfsd/bin $ sudo systemctl enable tnfsd
Created symlink /etc/systemd/system/multi-user.target.wants/tnfsd.service → /etc/systemd/system/tnfsd.service.
pi@pi3bp2:~/spectranet/tnfs/tnfsd/bin $ sudo systemctl start tnfsd
pi@pi3bp2:~/spectranet/tnfs/tnfsd/bin $ sudo systemctl status tnfsd
● tnfsd.service - TNFS Server
     Loaded: loaded (/etc/systemd/system/tnfsd.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Thu 2023-02-23 01:01:38 WET; 6min ago
    Process: 14929 ExecStart=/usr/local/sbin/tnfsd /tnfs -c tnfs (code=exited, status=255/EXCEPTION)
   Main PID: 14929 (code=exited, status=255/EXCEPTION)
        CPU: 13ms

Feb 23 01:01:38 pi3bp2 systemd[1]: Started TNFS Server.
Feb 23 01:01:38 pi3bp2 tnfsd[14929]: chroot: Operation not permitted
Feb 23 01:01:38 pi3bp2 systemd[1]: tnfsd.service: Main process exited, code=exited, status=255/EXCEPTION
Feb 23 01:01:38 pi3bp2 systemd[1]: tnfsd.service: Failed with result 'exit-code'.
pi@pi3bp2:~/spectranet/tnfs/tnfsd/bin $ ls -l /usr/local/sbin/tnfsd 
-rwxr-xr-x 1 root root 52704 Feb 23 00:53 /usr/local/sbin/tnfsd

It looks like it was working when I got the Warning about command vanished, as I tested loading an ATR from the tnfsd server. It looks like the fujinet-PC buffered the tnfsd sector data, when I Control-C'd the FujiNet-PC, I got:

01:12:25.487467 > Signal received (2)
01:12:25.490064 > Shutdown handler called
01:12:25.491111 > FileHandlerLocal::close
01:12:25.494045 > delete FileHandlerLocal
01:12:25.494361 > FileHandlerLocal::close
01:12:25.494571 > delete FileHandlerLocal
01:12:25.494814 > FileHandlerTNFS::close
01:12:27.497121 > Timeout after 2000 milliseconds. Retrying
01:12:30.499119 > Timeout after 2000 milliseconds. Retrying
01:12:33.503668 > Timeout after 2000 milliseconds. Retrying
^C01:12:36.508273 > Timeout after 2000 milliseconds. Retrying
01:12:39.509921 > Timeout after 2000 milliseconds. Retrying
01:12:40.510429 > Retry attempts failed
01:12:40.510683 > delete FileHandlerTNFS
01:12:42.517908 > Timeout after 2000 milliseconds. Retrying
01:12:45.518805 > Timeout after 2000 milliseconds. Retrying
01:12:48.520928 > Timeout after 2000 milliseconds. Retrying
01:12:51.521685 > Timeout after 2000 milliseconds. Retrying
01:12:54.525429 > Timeout after 2000 milliseconds. Retrying
01:12:55.525712 > Retry attempts failed
01:12:55.525985 > Stopping web service

The /tnfs directory looks OK:

pi@pi3bp2:~/spectranet/tnfs/tnfsd/bin $ ls -ld /tnfs
drwxr-xr-x 8 tnfs tnfs 4096 Jun 17  2022 /tnfs

So I'm not what the problem is with the chroot. This is on a Raspberry Pi 3B+:

pi@pi3bp2:~/spectranet/tnfs/tnfsd/bin $ uname -a
Linux pi3bp2 5.15.84-v7+ #1613 SMP Thu Jan 5 11:59:48 GMT 2023 armv7l GNU/Linux

mozzwald · February 23

1 hour ago, E474 said:

[Service]
User=tnfs
Group=tnfs
ExecStart=/usr/local/sbin/tnfsd /tnfs -c tnfs

This ^ is the issue with your systemd script. To use the chroot capability it must be run by root user instead. See the example systemd script in my first post.

Kenshi · February 23

After compiling, in addition to the expected tnfsd executable, I also have a tnfsd.linux64 in bin that I don't recall being there with the previous version. I'm guessing the former is a 32-bit version and the latter would be the ideal file to copy in 64-bit Linux.

And thanks for the chroot info. My TNFS server isn't public, but just changing three measly lines in the startup script is still worth the security.

TNFSD Directory Listing Vulnerability

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members