Bitvise Limited, 2024-08-04 SECURITY NOTIFICATION: USERS MAY BE ABLE TO MOVE MOUNT POINT DIRECTORIES We have identified an issue in Bitvise SSH Server where file transfer users who are configured with access to more than one mount point, can move the real root directory associated with a mount point inside another mount point, if this is permitted by Windows filesystem permissions. The user must also have SSH Server mount point permissions to move items, which are granted by default. This can have a security impact; it can have a reliability impact; or it can have no impact, depending on a user's mount point configuration. This issue can be addressed by updating to SSH Server version 9.39; by using Windows filesystem permissions to prevent unwanted directory moves; or by identifying that the SSH Server is already used in a way where this issue is not significant. EXAMPLE OF SECURITY IMPACT: Consider a user with mount point mappings: /foo => C:\SftpRoot\Foo /bar => C:\SftpRoot\Bar /foo/inaccessible => configured as hidden In this setup, the administrator is blocking access to C:\SftpRoot\Foo\Inaccessible, by configuring /foo/inaccessible as a hidden mount point. By default, SSH Server mount point settings grant permission to move items between /foo and /bar. If so, the user can send an SFTP rename request to move /foo to /bar/foo. If Windows filesystem permissions also allow this, C:\SftpRoot\Foo would be moved to C:\SftpRoot\Bar\Foo. The mount point /foo would now be empty, the hidden mount point /foo/inaccessible would not block access, and the user can access /bar/foo/inaccessible. EXAMPLE OF RELIABILITY IMPACT: Consider a user with mount point mappings: /foo => C:\SftpRoot\Foo /bar => C:\SftpRoot\Bar By default, SSH Server mount point settings grant permission to move files between /foo and /bar. If Windows filesystem permissions also allow this, the user can rename /foo to /bar/foo. The user does not gain access to anything the user could not already access. However, other users or programs accessing C:\SftpRoot\Foo would find it missing. EXAMPLES OF LIMITED OR NO IMPACT: (a) A user with a single mount point: / => C:\SftpRoot\Foo The user has a single mount point and has no other mount point to which to move it. (b) A user with unlimited access: / => unlimited filesystem access The user already has unlimited filesystem access, restricted only by Windows filesystem permissions. The user cannot gain more access due to this issue. (c) The administrator may have configured mount point permissions in Advanced SSH Server settings so that the user cannot move files or directories. The user then cannot move the mount point, either. SSH Server settings permit moving items if the user has Read Existing and Delete Existing access on the source mount point, and Read/Write/Delete New access on the destination mount point. If the user lacks some of these permissions, moving items can still be allowed using "Permit Move Existing". RECOMMENDED STEPS: (A) The simplest way to address this issue is to update to SSH Server version 9.39. This version requires a license which is UP TO DATE with upgrade access: https://bitvise.com/ssh-server-version-history-9 Version 9.39 blocks attempts to move mount-point mount-paths, regardless of other permissions. See the subsequent section, "UPGRADE ACCESS", if you would like to extend upgrade access for one or more existing licenses for which it has expired. (B) It is also possible to address this issue without updating the SSH Server version. In this case, identify the Windows account(s) which provide the security context for file transfer users who may be configured to access more than one mount point. Then, examine Windows filesystem permissions and ensure that appropriate Windows accounts are denied Delete access on any mount point root directories. For Windows accounts, the account which provides the security context is the Windows account itself. For virtual accounts, the default security context is provided by the BvSsh_VirtualUsers account. This is a local Windows account created and managed by the SSH Server. This account will have a different name if you are using a named SSH Server instance. Virtual accounts can also be configured to use a different security context in Advanced settings. Bitvise cannot assist with configuring Windows filesystem permissions. The Windows permission system is complex and must be mastered by the administrator to configure the system securely. UPDATING THE SSH SERVER: You can update to SSH Server version 9.39 using the built-in update feature, on the About tab of the SSH Server Control Panel. Before updating, ensure that upgrade access for your license is up to date. You can also download the latest version installer and run it to update an existing installation: https://bitvise.com/ssh-server-download An update is intended to fully preserve your settings and their function. The update stops the SSH Server and restarts it automatically if it was previously running. This usually takes about a minute. A Windows restart is not needed if the previous SSH Server version is at least 7.21. SCRIPTABLE CONFIGURATION: A notable difference between major versions is that this is where we've made changes to scriptable settings. Scriptable configuration is an advanced feature which is not used by most users. If you are using scripts to manage the SSH Server, they will need attention to upgrade to a new major version: https://bitvise.com/ssh-server-guide-scriptable#changes UPGRADE ACCESS: If upgrade access for your license(s) has expired, but it expired less than 4 years ago, it is more cost-effective to EXTEND UPGRADE ACCESS than to purchase brand new license(s). For Bitvise SSH Server per-installation licenses, you can add license-years of upgrade access using the "Place a New Order" section in your License Overview: https://bitvise.com/actv/ To extend upgrade access, add ONLY license-years of upgrade access. Do NOT add new licenses, unless you want additional license coverage as well. Upgrade extensions are a form of discount for upgrades to new versions. They are NOT a service, so upgrade access is extended from its last expiry. The cost is 20% of the license price per year. If you wish to extend upgrade access for only some licenses, but they are currently grouped together with other licenses so that they share the same upgrade access expiry date and activation code, contact Bitvise to split or rearrange the licenses. OLDER LICENSE REPLACEMENT: If upgrade access for your existing license(s) expired more than 4 years ago, it becomes more cost-effective to replace such licenses with new ones. If you would like to replace such older licenses, use our main Purchase page: https://bitvise.com/purchase In this case, you will receive an activation link which will allow you to associate the new order with either a new or existing activation account. If you associate the new order with an existing activation account, make sure to use the option to "CREATE A NEW LICENSE GROUP". This way, the new license(s) will receive an independent activation code and upgrade access expiry date, unaffected by any older licenses in your License Overview. APPLYING A NEW ACTIVATION CODE: The SSH Server uses an offline activation system. Any new activation code needs to be applied manually. If you extend upgrade access, or purchase one or more new licenses, you will find a new activation code in your License Overview, under the license details. Select the activation code, copy it to clipboard, and apply it using the "Apply new activation code" dialog. This is found on the About tab in the SSH Server Control Panel. LARGE-SCALE LICENSES: If you are using a large-scale license, contact Bitvise to extend upgrade access or check license status. Large-scale licenses are NOT managed using the online activation interface.