HonorDrivePolicy not fully functional

The registry setting HonorDrivePolicy = (REG_DWORD) 1 should hide drives that are supposed to be hidden and not accessible by GPO. When WinSCP is launched, the dropdown box for the left and right Commander panes indeed do not show any of the hidden drives. Unfortunately, hidden drives are still accessible through Left > Go To > Open Directory/Bookmark..., in the following dialog "Open Directory" it is possible to type the drive letter of a hidden drive in the dropdown box "Open directory" (e.g. C:\, D:\), then click "OK" and the contents of the hidden drive is shown in the left Commander pane. The same goes for Right > Go To > Directory/Bookmark.... When the application is closed and restarted, all the supposedly hidden drives are selectable in the dropdown box for the left and right Commander panes. The drives become hidden again, when a different drive is selected which normally is not hidden to the user and only when the application is restarted.

I have been using WinSCP 6.3.3 and 6.3.4.

But you can browse those drives even in Windows File Explorer, if you type their path in the Explorer's address bar.

The NoDrives policy does not make the drives inaccessible. It just makes them hidden.

Hi,

When setting Windows GPO to hide local drives and prevent access for specific user, the user will not be able to browse the files and directories through Explorer. I have 2 servers running WinSCP where in one of them WinSCP seems to respect the policy and doesn't allow the selection of C drive while in the other server WinSCP allows to select C drive through the commander interface although the GPO prevents it. I can see that when using WinSCP browsing options, the GPO settings are respected and the user cannot browse the folders in the local drive that the GPO prevents access to (C). I have checked the registry settings for WinSCP in both servers and didn't notice a change that can affect the described behavior. Can you update if there are other settings that can be checked to find out the difference in the behavior between the 2 serves? Note that the settings are not saved to file but only to the registry.

Update:
After additional analysis, I have noticed that there is a regression in the behavior that started from version 6.2 beta and up to the latest version 6.3.4. WinSCP version 6.1.2 respects the GPO settings as expected, while in version 6.3.3 I can see the hidden local drives in the commander and the explorer view. Are you aware of that behavioral changes and is there a setting for versions newer than 6.1.2 that can preserve the expected behavior?
From a comparison between version 6.1.2 and 6.3.3 it seems that the changes in the file IEDriveInfo.pas in the addition of the function TDriveInfo.OverrideDrivePolicy and the change in the logic of the function TDriveInfo.ReadDriveBasicStatus might be related to the behavioral change.
Please advise.

Thanks,
Eyal

So what happens in Explorer, then the drive is hidden by GPO and the user types the drive path into the Explorer's address bar?
If I disable the drive using the NoDrives registry value, the drive is still accessible in the Explorer.
In any case, the drive is clearly accessible. Otherwise WinSCP won't be able to browse it. So even if you would not be able to access it with WinSCP, you could access it with other applications or command-line.

If you will configure the registry value NoViewOnDrive in addition to NoDrives, when you will type the drive letter through Explorer, Windows will block the operation with a message that it is not allowed for the user.
The relevant group policy settings is located at the same place as the NoDrives and the title of it is "Prevents users from using My Computer to gain access to the content of selected drives".

Update if you need more information on how to configure this GPO setting.

I've never heard about NoViewOnDrive until now. And you haven't mentioned it so far yet either. So this is not about NoDrives at all, right? WinSCP does not follow NoViewOnDrive.

Until version 6.1.2 if the NoDrives was defined, WinSCP respected this setting and didn't show the drives that were set in the policy in the internal explorer. This setting just hides the drives, but as you mentioned, it didn't prevent a user from typing the drive into a Windows Explorer page to view the data. I have mentioned the addition of the NoViewOnDrive in order to let you know that there is such a drive policy setting that can also prevent the ability of a user to bypass the restriction by typing the drive letter.
Is it possible that WinSCP will continue to respect the system drive policy as in versions older than 6.1.2 (including) and, if possible, support the enforcement of NoViewOnDrive as well?
Even if it is about a configuration setting that can control this behavior.

That the drive hidden by NoDrives could not be visited was never by purpose. It was just an unintended side effect.

I can implement NoViewOnDrive, if there's a demand for it. But what's the point? The user can visit the drive using other application or commandline.

As an example of the need, assume WinSCP is running in a kiosk mode environment where no other programs or command lines are allowed. In that case, it would be expected that WinSCP will also respect the environmental restrictions. Is it possible to support such a mode even by a configuration setting?

Can you give me an example what would you use WinSCP in kiosk mode for?

Also, would running WinSCP in kiosk mode disallow it from running commands? (e.g. via custom commands or command-line bar)?

The kiosk mode was an example for you to understand a legitimate requirement.
For example assume using WinSCP in a kiosk mode environment where the server have drives C and D and the server administrator want to restrict access to C drive while allowing access to D drive. Using Windows GPO there is a way to achieve such requirement while with WinSCP versions that are newer than 6.1.2 the internal file browsing implementation doesn't adhere to the GPO settings letting the user to browse the C drive as well according to the user's permissions.

In regards to your second questions, there are other mechanisms that can prevent the user from running commands.

Sorry, but I do not consider a kiosk mode a legitimate example of use of WinSCP.
WinSCP is way too flexible and powerful too for you to allow random visitors to mess with it on your system, even if it followed your drives policy.

I apologize for the delay in my response to this thread.

We are using WinSCP in a Corporate Environment from within an Administrative domain to upload files from one domain to the other. Even in the Administrative domain, users are not allow to browse certain drives (e.g. C:\, D:\, Y:\). Access has been blocked through the Windows Explorer and/or "File Open/Save"-, "Browse for folder"- and/or "Commander"-like dialogs of applications. Users are allowed to browse other drives, like their homedrive, from Windows Explorer and/or applications.

I kindly request you to implement the NoViewOnDrive in the next release of WinSCP.

Hi Martin,

Note that the kiosk mode was just used as an easy-to-understand environment with restrictions for accessing local drives.
It seems that Paul presented a more adequate use case for such restrictions and I am joining the request to implement the NoViewOnDrive in the next release of WinSCP if possible

Bth, I do not believe you can configure Windows to really prevent users from accessing your would-be hidden drives. This all seems to me like a Security through obscurity.

Also, how did you prevent your users for example from using WinSCP scripting to access the drives?

Anyway, I have added this request to the tracker:
Issue 2310 – Optionally follow NoViewOnDrive policy
You can vote for it there.

I hope you will consider to implement NoViewOnDrive as we want to update WinSCP to the latest version, because of "CVE-2024-31497".

The Administrators of our Corporate Environment have blocked access to specific drives, using GPO, on all of our platforms (Citrix Session Hosts and Windows 10/11 client PC's). The Workspace Environment and Menu Start is controlled. Users cannot start processes like cmd.exe, regedit.exe, powershell.exe, etc.. Users (and even Administrative User) receive an error message when they try to launch processes using "Start | Run..." or shortcut they created themselves on the desktop. These processes are captured and blocked unless they are authorized or a specific shortcut is presented to them by the Controlled Workspace Environment.

Thank you for creating the Request Tracker for this particular issue. I will issue my vote immediately.

Although the Administrative Environment has limited (close to none) Internet Access, we would like to continue using WinSCP and maintain our security standards. I have already entered by vote and sincerely hope for more votes.

I don't know how many votes are needed for the enhancement to be implemented. The enhancement is necessary for us to be able to update to the latest version of WinSCP and solve CVE-2024-31497.

@vansomerenp and @eyal: I'm sending you an email with a development version of WinSCP to the addresses you have used to register on this forum.

Hi Martin,
Once again: Sorry! I haven't been watching this topic for a week. I will test the version you have send me and inform you about the results.

Hi Martin,

As previously replied through mail, I am writing here as well, that I have tested the provided version and it provides the requested functionality.
Can you provide a rough estimation of when the fix will be available in a GA version?

Thanks,
Eyal

Thanks. It's still at least few months away.