MOTW implementation breaks deployment of binaries

[Cylox]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest version
• Search the existing issues.

Steps to reproduce

The MOTW implementation introduced in v9.1.0.0 (see #1964 and PowerShell/openssh-portable#614) breaks deployments of binaries through sftp.

I'm using sftp to transfer .NET binaries (.dll files) to a test machine as part of my local build process, because these binaries need to be debugged/tested/verified on that remote machine. Since v9.1.0.0 the deployed binaries are blocked by windows because they are flagged with the MOTW which causes the .NET runtime to refuse loading the assemblies. Of course, I can unblock them manually, but as soon as I build &deploy again the MOTW gets re-applied. There is no real workaround available since I cannot disable the MOTW flagging.

This could also get troublesome for configuration management tools like ansible, which transfer all files per sftp by default, including scripts and possibly binaries.

As per "definition" for MOTW here: https://www.microsoft.com/en-us/msrc/windows-security-servicing-criteria I can't see why MOTW should be applied on files that are uploaded to a server. The reasoning behind this security mechanism is to protect users from downloaded, (untrusted) files from the Internet. This is an entirely different case compared to when I open a SSH session, using my credentials to authenticate to a server and then upload a file. It just doesn't make any sense to authenticate a user, using impersonation to restrict access to the well-defined user privileges and then still handling it like it was an anonymous untrusted third party that wants to push malicious files to the system.

I also tried fiddling with the internet security zones so that the sftp server would treat the upload as trusted but since there is no documentation about how to do that, I wasn't successful.

Frankly, I don't understand why this has been implemented the way it is although there were a lot of good reasons and warning signs in this discussion here not to do it: #1964

Expected behavior

MOTW should not be applied to files that are uploaded to a sftp server.
It only should be applied for downloads executed by the sftp client. This would be in sync with files downloaded through browsers.

Actual behavior

MOTW is applied on all files I upload to the server.

Error details

When checking the file properties of the uploaded files, they are marked as blocked.

Environment data

N/A

Version

9.1.0.0p1

Visuals

No response

[PaulHigin]

The MOTW is a Windows security feature that we needed to implement to be compliant. We cannot remove it, but we will look into whether we can provide a way to opt-out. In the meantime you can use PowerShell's Unblock-File cmdlet to automate your binary upload.

[jborean93]

Ok so can we get SMB to be marked as out of compliance, it doesn't create an MOTW on any files when someone copies a file to a server through SMB. I just don't understand why the SFTP service should be dealing with any of this, it will create files as requested by the authorized user. I could understand if the sftp/scp client on the Windows side adds the mark for any files it would download locally (not that I agree with it) but the server should just be placing the file as it is and not mutating it further.

Going further PowerShell is also out of compliance as Copy-Item -ToSession won't place the MOTW on the remote file. I'm sure there are many other examples out there and it's disappointing at the lack of discourse between the team here and active community members in #1964 like @mgkuhn and @NoMoreFood who expressed concerns around this approach.

[Jaykul]

Wait, what happens if you try to scp a file to a non NTFS file system?

[jborean93]

Wait, what happens if you try to scp a file to a non NTFS file system?

Luckily it still works, the sftp service just ignores the failure.

[mgkuhn]

I still feel guilty about my overly diplomatic responses to #1964. My response should have been to argue strongly that the entire issue #1964 by @danielcunn123 was not a valid vulnerability report to begin with, and that the only correct action would have been to reject the entire report as a non-issue that does not need any action. Instead, I got distracted by an initial patch for adding a MOTW to a non-web command-line file copy tool without even consulting the Internet security zone it came from, and started to help “polish a turd” by pointing at how a slightly more correct MOTW application would look like. Sorry for being too diplomatic here. I may have unintentionally helped to create a textbook example of an organization's security bureaucracy and bug-bounty-programme having damaged the usefulness of a tool in response to an invalid vulnerability report. I still believe that scp/sftp should not add a MOTW and that the corresponding patch PowerShell/openssh-portable#614 should be removed completely.

[Cylox]

I still feel guilty about my overly diplomatic responses to #1964. My response should have been to argue strongly that the entire issue #1964 by @danielcunn123 was not a valid vulnerability report to begin with, and that the only correct action would have been to reject the entire report as a non-issue that does not need any action. Instead, I got distracted by an initial patch for adding a MOTW to a non-web command-line file copy tool without even consulting the Internet security zone it came from, and started to help “polish a turd” by pointing at how a slightly more correct MOTW application would look like. Sorry for being too diplomatic here. I may have unintentionally helped to create a textbook example of an organization's security bureaucracy and bug-bounty-programme having damaged the usefulness of a tool in response to an invalid vulnerability report. I still believe that scp/sftp should not add a MOTW and that the corresponding patch PowerShell/openssh-portable#614 should be removed completely.

I could not have phrased it better. This is exactly my point. Thanks for sharing your insight, @mgkuhn
It is so frustrating that there finally is a nice usable port of SSH that runs on Windows and you finally think "great! now I can use this to drive automation the same way as with Unix clients", but then it is "complianized" and "windowsified" in a way so that It just does not work the same anymore, which makes this entire port less useful. It is frustrating for both, the people using it and the ones spending their time to drive this project forward.

[jborean93]

Thanks @tgauth for reverting this behaviour.

[matsmcp]

I still feel guilty about my overly diplomatic responses to #1964. My response should have been to argue strongly that the entire issue #1964 by @danielcunn123 was not a valid vulnerability report to begin with, and that the only correct action would have been to reject the entire report as a non-issue that does not need any action. Instead, I got distracted by an initial patch for adding a MOTW to a non-web command-line file copy tool without even consulting the Internet security zone it came from, and started to help “polish a turd” by pointing at how a slightly more correct MOTW application would look like. Sorry for being too diplomatic here. I may have unintentionally helped to create a textbook example of an organization's security bureaucracy and bug-bounty-programme having damaged the usefulness of a tool in response to an invalid vulnerability report. I still believe that scp/sftp should not add a MOTW and that the corresponding patch PowerShell/openssh-portable#614 should be removed completely.

I did reply in that thread. Maybe I should have used stronger words too.
My concerns that this would cause issues has been confirmed.

I maintain my opinion that this should be revoked in full.

#614 makes the "Microsoft" OpenSSH behave differently than all other SSH implementations. Unix based implementations doesn't care about MTOW and I believe that the Cygwin version on Windows doesn't either. This goes against the goal of one crossplattform OpenSSH.

It was also sort of a false fix since we got different behavior between a file SFTP transferred to a Windows server and then accessed over SMB compared to doing the same thing with a Linux server with Samba.

The basic problem here isn't OpenSSH. it's that applications (like Office) allows execution of unsafe code. The fix to that is not to wrecking an industry standard application - it's fixing those apps (for example require signed macros that has been an option in office for at least 20 years).

If this can't be fully revoked. Please,please, please at least give us configsettings to disable it both on client and server side.
Else there is a risk for a forked project just to remove this.

On the brighter side.
A big thanks to @tgauth for revoking it on the server side.