Fix insecure defaults

[jgoerzen]

Although I am not affiliated with this repo at this time, I wanted to share this security issue.

This can lead to data exfiltration and compromise

Further information at http://bugs.debian.org/1123025

[carnil]

CVE-2025-68920 has been assigned for this issue.

[jaltman]

@carnil @jgoerzen I think there is a misunderstanding of the use case implemented by C-Kermit which is to permit the end user to operate on the local system from the remote session without requiring that the user switch back to the local session to change the state of the local client. Today, this scenario is identical to the behavior of a Windows Remote Desktop, Apple Remote Desktop or VNC session where the local filesystems are shared to the remote host. That the shared filesystems can be manipulated by processes running on the remote host is by design and is not a security flaw.

It is reasonable for an end user to be required to explicitly enable sharing their local filesystems with a remote system when establishing a remote terminal session. It can be argued that the default for SET TERMINAL AUTODOWNLOAD should be OFF as it is documented in the HELP SET TERMINAL text. I do not have intermediate builds of pre-7.0 C-Kermit to examine so I cannot easily determine when the default 'autodl' value switched from 0 to 1. However, it was 1 by the time C-Kermit 7.0 was final. However, here is what @kermitfdc wrote:

     Should TERM AUTODOWNLOAD be ON by default in C-Kermit (as it is in K-95)?
     . No, because the book says it isn't.
     . No, because C-Kermit is very likely to be in middle.
    
    But then what about when it is a client of IKSD?  In that case it should be
    ON so SEND from the IKSD prompt will always work.  But then if it's in the
    middle, we'll still have trouble if the local Kermit also has it on.
    
    So what are the choices?
     . Leave it alone.  But this makes IKSD look bad.
     . Make it on by default?  Causes confusion when C-Kermit in the middle.
     . Turn it on automatically when client of IKSD?  (Save & restore)
    
    Well, yes, obviously we want it on when we're a client of IKSD.  That's not
    the question -- the question is what do we do about the other, more local,
    Kermit that might also have it on?  There's nothing we CAN do, so don't worry
    about it.  Ideally, then, we would change SET TERM AUTODOWNLOAD { ON, OFF }
    to { ON, OFF, AUTO }, with AUTO being the new default, meaning "enable
    autodownload automatically if I make a connection to an IKSD".  And I started
    to do it that way, but ran into conflicts with K95, which has a different and
    conflicting set of keywords, plus it was not obvious where the automatic
    switching should be done, nor where to undo it when the connection is broken
    or some other negotiation would change the rules.  So I simply made the
    default be ON for all C-Kermits as well as K95.  It's a lot easier to explain
    this way, and in fact the book goes into some detail about it in several
    places.  ckcmai.c, 20 Jan 99.

As @kermitfdc indicated, the reason SET TERMINAL AUTODOWNLOAD was enabled by default was to make IKSD look good. The HELP SET TERMINAL text wasn't updated and it should have been #ifdef CK_AUTODL.

The original intent is that AUTODOWNLOAD should have been OFF by default for everything but the GUI version of Kermit 95 where the user can be prompted to authorize the remote initiated operation. As I see it, 'autodl' should be 0 except when building for Kermit 95 (GUI). It ok in the GUI because there we have the ability to ASK the user if the remote initiated operation should proceed.

Another reason that its fine for AUTODOWNLOAD to be disabled by default is because IKSD never caught on.

Note that in addition to SET TERMINAL AUTODOWNLOAD there is also SET INPUT AUTODOWNLOAD which controls the operation of automatic file transfer when scripting operations with the INPUT command. There is also SET COMMAND AUTODOWNLOAD. INPUT AUTODOWNLOAD defaults to OFF but is not documented as such and COMMAND AUTODOWNLOAD defaults to ON and is not documented as such.

AUTODOWNLOAD is actually a misnomer because what it really means is "KERMIT-SERVER". However, that ship sailed decades ago.

With regards to the default values of the REMOTE commands. The ChangeLog contains:

Changed ENABLE/DISABLE commands to allow an optional trailing argument: REMOTE, LOCAL, or BOTH (default = BOTH). Server services are now enabled or disabled separately for remote and local mode. The en_xxx flags are now 2-bit fields, with values 0..3. The protocol module has a new macro, ENABLED, to check them. Changed the defaults for RETRIEVE, DELETE, HOST, and BYE to "remote-only", meaning they are enabled in remote mode, disabled in local mode, to prevent nasty surprises caused by autodownload sequences. Other services are enabled in both remote and local mode by default, as before. ckcmai.c, ckuusr.c, ckuus[56].c, ckcpro.w, 22 Sep 96.

The concern I have with changing all server commands to remote-only is that it breaks the "remote desktop" scenario where a user logs into a remote host and wants to operation on the local file system from the remote without having to toggle back to the local system. When a user shares their local file system with a remote system in that scenario they do not expect only a subset of operations to succeed.

I appreciate that there is a distinction to be made between connecting to a trusted system versus an untrusted BBS or some such thing. The question is "how might a user express that they either want or don't want to trust the remote?" Perhaps a SET HOST switch. Changing the server defaults might be the least bad option in the meantime.

The default SET FILE COLLISION mode is not specific to AUTODOWNLOAD. Since 1998, when DISABLE DELETE is executed, the FILE COLLISION mode is switched to RENAME. RENAME is the behavior most web browsers provide when downloading a file and there is a collision.

The reason that BACKUP is the default is because Kermit is often used to transfer the latest version of a set of files to the other system and have the most recently edited version be the active copy. Similar to how a backup file is created after changing the file with an editor. Changing the default to REJECT is going to break a lot of existing workflows.