Core: .Net 5/core strategy security patches of self contained executables

[Spelt]

Hi,

This is a question about client security.

How is client security handled in .Core 3.x ? In .NET classic the is all handled in Windows via Windows updates which works pretty well.

I mean, if you look at the slew of security patches MS released the last few years with minor and major security issues. Like this one for example.

The reason that I asked this question is that vendors/developers who in the future distribute there .NET software with the Net Core 3 framework could expose there clients to an enormous risk when a security breach in .Net Core happens. This could happen because MS is not patching anymore (which is kind of one of MS goals).

For example:
I, as a software vendor, distributes xaml .Net 4.x software to > 200 clients (some major companies). .Net security patches gets fixed by MS so all is good. My clients do not need to worry because MS watches the .Net security space. If I update the application to .Net core 3 this is not the case anymore? Do I need to watch the security bulletins about .Net and update all the time ?

If this is the case I see a potential big risk because I (an many other vendors with me) don't want to do this (takes too much time, effort) and the risk is to great when it is forgotten. Companies will also not buy my software anymore.

Maybe i'm wrong but it looks like the strategy regarding this one is very flawed and a disaster in the making.

[richlander]

Great question. We're still working on our servicing plan for .NET Core 3. We'll share more information, likely on the .NET blog, when we have a well-defined plan. I understand the crux of your question, that .NET Core today is focused on the server scenario and that client apps are different. We get it.

[Petermarcu]

@richlander do you need this issue open to track this or can it just be closed and referenced from where you are tracking it?

[Petermarcu]

@shawnro @dleeapho, you have a place you want to track this in the github. I know its listed in the larger list of important scenarios to enable but we should keep the community up to date on the plans.

[shawnro]

Thanks for tagging us, @Petermarcu. Agree. We're still working on getting everything in place for tracking and will be mindful of this as we do.

[DanJ210]

@richlander Yea I had this same concern also. I didn't know .Net Core was server focused, I see it pushed heavily but for creating web apps as those are templates in Visual Studio. I also heard the rumor was that .Net Core was named .Net 5 at one time. So as a web app developer, should I be turned off from .Net Core due to leaving clients vulnerable to possibly huge risks?

[JaredShaver]

@shawnro @richlander Is managing .NET Core patches through WSUS/SCCM in the roadmap? As an enterprise admin with responsibility for ~100,000+ PC/servers I don't want to have to reinvent the wheel. We already have lots of infrastructure/knowledge/processes invested in WSUS/SCCM for patching and compliance monitoring.

[dleeapho]

/cc @leecow

[lmgagne]

We're evaluating the possibility to install .net core on all our servers in order to ease migration of apps to Azure. Seeing all the (manual) work required this component in the field is quite significant. Is there any update on this?

[SimonCropp]

@richlander

likely on the .NET blog

please do not do this via a blog post. Blog posts rapidly get out of date and pollute search results. In some cases this is acceptable, but not for content like this. this content should be a first class citizen in the MS owned doco, and maintained/versioned over time

[Spelt]

@richlander

Hi,

It is almost a year since I started this thread. Is there any progress on the matter?

Sincerely,
Edward

[shawnro]

We have several issues tracking various aspects of this. Reassigning to the folks who own this and related issues.

[Bartolomeus-649]

Updates need to be distributed according to the standard method used by each platform. That is, on windows, all updates/patches should be distributed via Windows Update.

But that's not all, there also need to be a built in feature in the .NET Core runtime which makes sure that any application who used NuGet (or something like that) to download and include .NET Core System assemblies in their distribution, and which resulted in .NET Core System assemblies now being hosted and loaded from individual directories for each of these application. Those applications cannot be allowed to load an old, unpatched version of an assembly just because they used NuGet and now have their own version of a .NET Core system Assembly.

This, or something equivalent, need to be in place before .NET Core can be used in an Enterprise Environment.

Also, I'm a bit confused by the remark by @richlander that

.NET Core today is focused on the server scenario

Why implement WinForms and WPF for server environments?

I was under the impression, .NET Core was the future of .NET, and that .NET Framework would not get anything new and substantial added to it.
Please clarify which version of .NET is aimed for future client side development of GUI Applications, if not .NET Core, then what?
Or is the era of .NET Client side applications over, and everything on the client will be HTML in the future?

[carlossanlop]

@richlander @leecow any updates on this?

[jonconwayuk]

As a consultant who creates and maintains client builds for customers it would be very useful to understand how the .Net Core runtime will be patched in Enterprise environments.

Unless this is addressed in Microsoft documentation to which we can refer then it will be a hard sell to recommend using .Net Core to customers until it is.

[ernstscheithauer]

@richlander @leecow any updates on this?
.NET Core 3.1 is around the corner and our customers want to know how they are patching this when we ship them an application based on .NET Core.
Although the issue title is about client I am more interested in the server side, but the other issues all refer to this one for this topic.

[alexwiese]

.NET Core 3.1.1 landed today with fixes for critical security issues:

• https://github.com/dotnet/announcements/issues/148
• https://github.com/aspnet/Announcements/issues/403
• https://github.com/dotnet/announcements/issues/149
• https://github.com/aspnet/Announcements/issues/402

These CVEs include 3 remote code execution vulnerabilities.

@richlander it's previously been mentioned that critical security updates would be pushed out via Windows/Microsoft Update:

If management decides something is serious enough to use Microsoft Update then it will be used.

Will .NET Core 3.1.1 be pushed out via WSUS/Windows Update? It seems like this is a critical update that needs to be pushed out ASAP.

/cc @shawnro @leecow

[tjmoore]

Echoing what's been said in various places, and having run into this while learning a thing or two about benefits benefits and pitfalls of .NET Core distribution (ref issue).

Many .NET Framework developers are migrating to .NET Core and given .NET 5 is .NET Core, then we're forced down that route anyway long term, but many enterprise organisations aren't going to be happy with a runtime dependency that doesn't get security updates as part of their update processes.

With a Framework Dependent route, unless patches are being pushed out, they are unlikely to ever get patched by customers. FDD/FDE seemed like a good choice otherwise to pick up latest patches.

That forces use Self Contained Deployment and puts the responsibility for security updates on the application developer. This itself may not occur in a timely fashion or at all for various reasons.

There is naturally going to be some kickback to revert to .NET Framework, as an example here.

[richlander]

Totally get it and agree. I'll push on some folks to work on a proposal for updating.

[SimonCropp]

but many enterprise organisations aren't going to be happy with a runtime dependency that doesn't get security updates as part of their update processes.

Isnt this the same as the majority of off-the-shelf (non ms) software? orgs must already have processes for this.

It is also similar to the prob 100s of 3rd party packages (nuget, npm etc) that apps consume. any of these can have critical bugs or security issues. wouldnt you apply the same approach to managing netcore as you must already have in place for those other dependencies.

IMO keeping software (dependencies, full apps, or runtimes) patched is a difficult problem. I dont see the current stance by the .net team as making it any more difficult.

[tjmoore]

but many enterprise organisations aren't going to be happy with a runtime dependency that doesn't get security updates as part of their update processes.

Isnt this the same as the majority of off-the-shelf (non ms) software? orgs must already have processes for this.

Anything that depends on .NET Framework would get updates as part of an organisation's update cycle from official Windows Updates.

Anything that depends on .NET Core won't.

I wouldn't be surprised if many organisations are unaware of update policies with .NET Core. It gets a lot more complicated as it can be globally installed, installed in a non-standard location but still shared between specific apps looking for it, or bundled into the app itself and not updateable.

It is also similar to the prob 100s of 3rd party packages (nuget, npm etc) that apps consume. any of these can have critical bugs or security issues. wouldnt you apply the same approach to managing netcore as you must already have in place for those other dependencies.

If we treat it like nuget, npm etc bundled into the app, then we may as well do away with FDD and FDE deployment models as there's no point depending on shared installs of a framework if they won't get patched. Apps depending on npm components generally aren't depending on globally installed components, with the exception of tools used by developers perhaps.

IMO keeping software (dependencies, full apps, or runtimes) patched is a difficult problem. I dont see the current stance by the .net team as making it any more difficult.

It's a fundamental change from the policy with .NET Framework, and we're being asked to move to .NET Core especially as .NET 5 is the next version of Framework and Core as one under Core.

We've been given the option for framework dependent install and even suggests benefit of being able to pick up latest updates, and yet those updates seemingly won't be installed.

[Spelt]

Almost 2 years have past. Still no answer or a solution for this problem. The last year there were a bunch of security problems with .core/standard.

After watching a populair Microsoft Build presentation there was no mention at all about security of self contained executables. Still the worries are there.

My conclusion: if there is no answer after almost 2 years there will be none. This is a problem. It is a potential legal problem for liability for Microsoft that none wants. Microsoft is Libel because they know about this situation and they don't do what they can to protect (at this time).

My suggestions to Microsoft before its too late is:

A) is that every developer which deploys a ‘Self contained executable’ should be aware by every deployment via a message box popup that ‘the machine is at risk if he/she is not updating his app when there is a security patch’ and that they are subscribed to a security bulletin.

Or

B) Remove the self deploying executable feature. if explained well everyone will understand. Its not a ‘Must have’ feature.

Hope it helps!

Edward

[ernstscheithauer]

@Spelt
As I understand it, the whole thread was about framework dependent deployments and how Microsoft should/will patch the .net core installation that is used in this deployment method.

And I am as worried and frustrated about this situation not being addressed for such a long time as you are.

But I do not understand your last comment and the change of the issue title. When using self contained executables it is clear that the app developer has to manage security updates of .net core himself, as documented in https://docs.microsoft.com/en-us/dotnet/core/deploying/#publish-self-contained:

.NET Core Runtime (distributed with your app) can only be upgraded by releasing a new version of your app. You're responsible for supplying an updated version of your application for security patches to the .NET Core Runtime.

So the actual problem is, that even when using framework dependent deployments the .net core on the machine will not be patched with standard procedures using SCCM/WSUS/etc.
Could you remove the "self contained executables" from the title of this issue? Or do I miss some aspect here?

[Bartolomeus-649]

But I do not understand your last comment and the change of the issue title. When using self contained executables it is clear that the app developer has to manage security updates of .net core himself, as documented in https://docs.microsoft.com/en-us/dotnet/core/deploying/#publish-self-contained:

.NET Core Runtime (distributed with your app) can only be upgraded by releasing a new version of your app. You're responsible for supplying an updated version of your application for security patches to the .NET Core Runtime.

I don't really care how Microsoft do it, but since they are in 100% in control of the Windows Operating System and .NET, they can of course make sure to not load/use a .NET .dll with a known security problem.
Think about it, the opposite would be that Microsoft and Windows williningly and consinesuly load and use a .dll they KNOW contain a security flaw, and where they have a replacement dll without the security problem, perhaps even available directly there on the local machine.

[ckruegerkpmg]

I think its very stupid to not patch .net core and powershell 7 via normal infrastructure.
It might be easy for MS in short term but the shitstorm will be huge after the first wormable hole!
Many many people will miss the fact that both is not autopatched.

Self contained runtime is the worst idea. I'm as an admin are not able to patch the runtime because a stupid thirdparty didn't deliver patches.

[tjmoore]

So the actual problem is, that even when using framework dependent deployments the .net core on the machine will not be patched with standard procedures using SCCM/WSUS/etc.
Could you remove the "self contained executables" from the title of this issue? Or do I miss some aspect here?

Two issues really.

Framework dependent relying on installed runtime are not benefitting from a major point of framework dependency, i.e. patching.

Self contained executable deployment lacks a strategy to deal with patching or should be clear that this is entirely the responsibility of the developer.

Self contained has only become an option for me because there's also no policy on an application installing the runtime with difficulty detecting the correct runtime installed, no permalinks to runtime downloads and broken missing runtime download functionality. Pre-requisits for customers to install the runtime following instructions are frequently not followed plus it's confusing with many options to choose from.

I'm unconfortable with self contained for the above reason on patching though.

[Bartolomeus-649]

Self container or whatever, Microsoft should patch it!
If the patch introduce a breaking change, then the user/admin should need to manually opt-in to continue using the flawed assembly.

There's absolutely no excuses or reasons for not doing this!

Whenever I tell my customers that they themselves are responsible of figuring out if there's any security issues with any of the Microsoft assemblies used by a .NET Core application, and then manually figure out if Microsoft has released an update which fix that security issue. If so, they then need to manually go and find and download that update, and manually make sure they get the correct version if more than one is available. Then they need to manually figure out how to deploy this new updated assembly in the correct way for this particular .NET Core application to all the affected machines, then every single one of them decide to continue using .NET Framework where this stuff just works.

[nakarnam]

Thank you for the feedback and we understand the concerns you are bringing up. We are currently working on the feasibility analysis of servicing .NET Core through Microsoft Updates and other patching strategies as well. We hope to have a direction on this shortly and I will keep this thread posted on the progress in the coming weeks.

[Bartolomeus-649]

@nakarnam How hard can it be? It's not like you haven't done this things before, right?

Here is one way to do it, that is 1000 times better than doing NOTHING for years! And it took less than 5 min to come up with it.

1. You know which of your assemblies you have patched for security issues.
2. So one way could be to add the old, unpatched assembly to be detected by Windows Defender. That takes care of the immediate security problem. Now the user or an Admin could opt-in to use the assembly if they so choose.
3. Transfer the new patched assembly to the client machine via Windows Update.
4. Whenever a .NET application tries to load the old unpatched assembly, then just copy(overwrite) the new patched assembly to the place where the .NET Application would have loaded the old unpatched assembly from.
5. If any .NET application is installed in the future which uses the old unpatched assembly and tries to install it, then let it think it has succeeded, but either you catch the install operation of the unpathed assembly when it happens, and just replace it with the new patched version, or Windows Defender catch it and removes it. Or when the application starts and tries to load the unpatched assembly, you just do another step 4.

The important thing is that you do not under any circumstances load and use an assembly you know have a security issue!

So get it done already and then after that, you can sit down and figure out if there's a better way of doing it.

[StefanBertels]

I don't agree that applications should be patched by Microsoft in all cases.

1. Currently build default is to produce runtime-dependent applications. This means the developer relies on the installed runtime (controlled by user/admin). Microsoft indeed should give automatic security updates for this -- similar to .NET Framework patches (i.e. update mechanism of OS or e.g. enterprise environment / WSUS).

2. Applications are self-contained if developers opt for this. There are probably different reasons for this. One could be that they want to make sure that the software is stable. I think it is not ok to patch this automatically. This could introduce failure (if behaviour _depends_ on bugs). I agree that in general no one wants to have this situation, but we have to deal with it somehow. It's not clear whether the bug is relevant for this software at all. Many security bugs are not relevant if the software is running in a secure context (think about input validation).

3. I can't see that blocking DLLs with known security flaws and delivering fixed ones via Defender can be a serious solution (IMHO).

[lennybacon]

MSFT will never STOP running something - even if they know there is a security issue.

It's the same with cars. The manufacturer can tell you you should not drive, but its up to you to do it or not.

That is as it should be and fine.

I would expect MSFT to deliver patches for the installed dotnet runtimes - as with the .NET Framework.

[Indigo744]

I stumble upon this thread after scouring the web for information on how to keep the .Net Core runtime updated with the latest security patch, hoping that it was just an oversight from my part and that MS did actually offered a solution to this really important problem.

Suffice to say that after reading the whole thread (and other similar ones), I am not impressed, sadly, and I wish we knew it before moving our applications to .Net Core.

I just wish Microsoft would be more open on this, as we currently have no idea whether something will be implemented to fix this issue, or even if it's remotely considered as a slight possibility in the distant future.

I saw some people speaking about custom-made script to keep the runtimes up to date. I would love to know if they are available on Github or somewhere else. Thank you.

[lennybacon]

.NET Core refers to several technologies including .NET Core, ASP.NET Core, Entity Framework Core, and more. .NET Core provides Long Term Support (LTS) releases that get three years of free support and release every other year. You choose when to update your application with a release. Patches to LTS releases are compatible which eliminates risk adversely affecting applications.

Source: https://dotnet.microsoft.com/platform/support/policy/

So here is my summary for now:

• The runtime will be patched with hotfixes
• The patching itself is up to you

I would really like to see an opt-in way of installing the latest patches automatically.

@terrajobst to the rescue?

[ckruegerkpmg]

@lennybacon :
The question is: who is "you".

I think "you" means the developer of product X that is using .NET Core.
Result: I'm as the administrator of the system (admin of the windows server) that uses product X can't patch .NET Core.

PS: with Java or .Net Framework Classic, I'm as the server administrator be able to patch the framework, and Product X will continue to work but without a security risk

[lennybacon]

you != Microsoft

you could be:

• A developer who compiles a new version of a product against the patched SDK.
  
  
  
  • If self contained that's it
  
  
  • If not self contained the machine where the software will run needs an update to its runtime.
  
  
• An administrator who updates the .NET runtime on the machine where a product runs.
  
  
  
  • If it is a patch or minor update ({major}.{minor}.{patch}) it will be compatible.
  
  
  • The {app}.runtimeconfig.json must be edited as with the example below.
  
  

Example:

{app}.runtimeconfig.json for .NET core 3.0:

{
  "runtimeOptions": {
    "tfm": "netcoreapp3.0",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "3.0.0"
    }
  }
}

{app}.runtimeconfig.json edited for .NET core 3.0:

{
  "runtimeOptions": {
    "tfm": "netcoreapp3.1",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "3.1.0"
    }
  }
}

[ckruegerkpmg]

It's a little bit unrealistic that an administrator scans all harddrives to find self contained .net apps and modify them manually.

I've created the following app ,Net core console app, targeting core framework 3.0
`
using System;

namespace ConsoleApp
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Version: {0}", Environment.Version.ToString());
}
}
}
`

and published it that way:
dotnet publish -c Release -r win-x64 --self-contained true

I've modified the {app}.runtimeconfig.json
to this:
{ "runtimeOptions": { "rollForward": "Major" } }

The app is not running on version 3.1 but 3.0.3
If I replace additionally the published framework files in the directory the app is not starting at all
Error: An assembly specified in the application dependencies manifest (ConsoleApp11.deps.json) was not found: package: 'runtimepack.Microsoft.NETCore.App.Runtime.win-x64', version: '3.0.3' path: 'mscordaccore_amd64_amd64_4.700.20.6603.dll'

Am I missing something?

[lennybacon]

• self contained: Recompile and redeploy
• NOT self contained: Update runtime and edit {app}.runtimeconfig.json

[ckruegerkpmg]

And that is meaning for a self contained app I as an administrator can't patch the runtime, only the developer can. -> very very bad

[tjmoore]

Admins going through editing runtimeconfig.json is a non-starter.

Self-contained apps recompile & redeploy is going to result in a lot of out of date unpatched apps. From experience a lot of customers don't update their apps, even if they have prompts to do so.

Auto updating is on option, but in server environments this may not be possible and in some enterprise environments the servers are isolated from the Internet and are strictly managed by IT for updates. Some companies don't like apps auto updating as they control and certify an application for roll out to production.

Though that much control, they'd do likewise with patches to the framework, but at least they can roll out the patches they want and expect applications using them to pick them up. Just not with .NET Core.

Then there are apps that go out of support, the company that made it stops providing updates, or it's an open source app that's gone stale.

[ernstscheithauer]

@ckruegerkpmg
In Self-Contained apps the .NET Core libraries are handled the same as every other 3rd party lib and the application itself. No one is patching all the included (open source) libs and nobody is patching the .NET Core libs themselfes, other than the developer itself. As the developer opted for this packaging option, he is the one responsible for the entire package. In this case admins need to see the whole piece of software as one thing that needs to be patched, and not only the .net core within it.

In the other options, the developer relies on .NET Core installed by the admin of the machine before installing the app itself. So in this case the admin is the one responsible for updating both .NET core and the app, but can do this separately.
And in this case as an admin I expect that .NET Core is patched with the available software delivery tools (SCCM) automatically.

While Self-contained is not my first choice I see several good use cases for this option. But I do not quite understand the argument that the admin should be able to patch the .net within because he is not patching all the other libs within. Just patch the app itself. It he developers don't provide the necessary update for new .NET Core versions they are not providing update for all other libs as well, so you have to stop using the software at all.

[ckruegerkpmg]

The .Net Core framework is not any library but the foundation.
I would argue that when you watch the history of .net framework classic and especially the introduction of something like UseStrongCrypto it's a bad idea to treat the framework like a common lib.
In an ideal world every developer would patch every problem right away, in reality it won't happen and even if the developer is patching the unpatched timeframe is for the enduser is expanding.

For the NOT self contained variant it's illusory that admins are modifying {app}.runtimeconfig.json

That said and combined with the fact that .Net Core updates are not distributed through regular microsoft update channels it's only matter of time until a cluster security fuckup will happen.

PS: I assume a vunerability scanner like whitesource maybe not able to find a vunerable framework because it scans only packages.

[blakeduffey]

Trying to figure out where this thread is going. If the .Net core group isn't going to support actual patch management via common tools like SCCM, should we route the developers to using self-contained apps? (I'm asking specifically for web applications). As a sysadmin I have compliance requirements to manage, I can't spend all my time chasing down .Net core versions on dev/test/staging/prod every couple of weeks when a new release is dropped.

[tjmoore]

There are already several patches for .NET Core 3.1 runtime for security fixes (up to 3.1.5 now as of writing) since releasing a product using Framework Dependent deployment. Our installer uses a fixed link to the runtime to download and install the runtime, but this is 3.1.1 as there's no link to direct to the latest (without having the user manually choose from the runtime download page). It appears this isn't going to get patched unless the end user does it themselves and a lot will not.

So this leaves us with going the self contained route. We have a slow release cycle unfortunately so it's very unlikely we are going to be able to release patches at the frequency the runtime has been patched. This is leaving customers open to vulnerabilities.

[ckruegerkpmg]

Analyze the installer script from MS to find the latest patch:
https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script

[tjmoore]

Analyze the installer script from MS to find the latest patch:
https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script

"The install scripts do not update the registry on Windows. They just download the zipped binaries and copy them to a folder. If you want registry key values to be updated, use the .NET Core installers."

So it wouldn't appear in add/remove programs or any admin tools on auditing the system for potential patches?

[ckruegerkpmg]

@tjmoore :
Yes, that's the sad truth.

I've found .net core installations that where not added to "add/remove programs" with the execution of:
dotnet --list-sdks
dotnet --list-runtimes

If you wan't the real reality I think you have to write something like a file system scanner that enumerates all .exe and .dll files :-(

[Spelt]

I’m wondering now if future anti-virus or intrusion detection software will go off and remove the dll’s because they are out of date/insecure.

Op 16 jun. 2020 om 17:07 heeft ckruegerkpmg [e-mail] het volgende geschreven:


@tjmoore :
Yes, that's the sad truth.

I've found .net core installations that where not added to "add/remove programs" with the execution of:
dotnet --list-sdks
dotnet --list-runtimes

If you wan't the real reality I think you have to write something like a file system scanner that enumerates all .exe and .dll files :-(

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[lennybacon]

I’m wondering now if future anti-virus or intrusion detection software will go off and remove the dll’s because they are out of date/insecure.

@Spelt This will never happen. How could a anti-virus system know if the system is air gapped or isolated and maybe not a risk?
Removing *.dlls results in business processes being stopped - which will lead to the demand for payment of damages and lost profits. No anti-virus will ever do this (without the demand of customers - and business focuses on business, not security).

[rocklan]

@nakarnam - it's four months later, is it really that hard to get minor versions automatically patched by windows update? Do you have an update for us?

In the meantime, can I at least get an email sent to me when a security patch is released for dot net core 2.1 or 3.1? How else am I supposed to be able to keep these things up to date?

[blakeduffey]

We are moving to SCD as a corporate strategy. I don't even install the .net core runtimes on the web server, so it becomes an 'application issue'. Essentially we are treating the web app as a stand alone entity - security issues that arise in .net core are no different than issues that arise from jQuery or any other dependency.

This way .net core never shows up on a nessus scan as a 'system problem'. I sympathize with sysadmins or devops engineers who feel the dev teams will 'fire and forget' on apps.

[VaderConsulting]

I have been working the last year on .Net core. Initially 2.0, but recently, 3.1.

Specifically, my apps are delivered by AWS as a part of Lambda functions. Actually getting these AWS functions through multiple layers of testing and change control iterations is not a small job. Especially when you consider that this work is all for Government!

I have read all of the above, and agree that there are concerns with patching. However, I don't think there has been mention of patching in the Linux (i.e. AMI) world. Normally AWS manages all Server patching, but with .net core, that method is lost.

What now? Do I move to Python or some other terrible alternative?

[bairog]

@nakarnam @richlander - any updates for us?

I will keep this thread posted on the progress in the coming weeks.

It's almost 5 month later - to many "coming weeks" to my mind..
P. S. Our software is enterprise client side GUI application. In our enterprise environment the servers are isolated from the Internet and updates are managed by admins via WSUS.

[blakeduffey]

I mentioned our approach earlier in this thread but wanted to provide some additional details (with the hope they will help others).
My main concern on this topic has been manageability. It isn't feasible to patch dev/test/staging/prod at scale every time the .NET core folks decide to come out with a new release. In the .NET framework days this was handled by Windows Update (and we as system people could handle it via WSUS, SCCM, etc). There doesn't seem to be a straightforward way to handle .NET core (I've looked at options like Chocolatey but they weren't ideal either).

.NET core allows web applications to be built/deployed via SCD (Self Contained Deployments). By including all the .NET core goodness in the application itself, I don't have to install the .NET core runtimes on the IIS server at all. Per the documentation: https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/?view=aspnetcore-3.1#install-the-hosting-bundle

I can install IIS
Install-WindowsFeature -Name Web-Server -IncludeManagementTools
and then install the hosting bundle without any of the runtimes:
dotnet-hosting-3.1.5-win.exe OPT_NO_RUNTIME=1 OPT_NO_SHAREDFX=1 OPT_NO_X86=1

.NET Core (the runtime) isn't installed on my IIS servers and doesn't have to be managed.

Now I'm sympathetic to those who say 'what about vulnerabilities that are uncovered in .NET core'? My response is straightforward: How do you handle XSS vulnerabilities in the web application? How do you handle SQLI issues in the web application? How do you handle vulnerabilities in jQuery or Boostrap or anything else in the web application? We have to draw a line between what is maintained by the systems/devops team and what is maintained by the development team. I can't fix an injection vulnerability (nobody wants me digging through source code). My responsibilities include OS patches, IIS configuration, etc. The web application itself (including anything specific to .NET core) fall on the dev team (just like any of the vulnerability possibilities I included above).

[deathchurch]

@blakeduffey how do you keep the hosting bundle up to date, do you manually update that every time a new one is released?

[blakeduffey]

I think that's a fair question. Without the hosting bundle installed, IIS doesn't understand .NET core applications at all (you simply get a 500 error if I remember correctly). Since in this model we don't install the runtimes - I wonder if it is necessary to keep the hosting bundle updated? (if it is simply some configurations for IIS to be able to run .NET core)

I honestly haven't tried installing an older version of the hosting bundle - I can try to provide a better answer next time it is updated (oh look - a new release dropped YESTERDAY 3.1.6, dropped on 7-14).

I'll update the thread when I have more info.

[ckruegerkpmg]

Now I'm sympathetic to those who say 'what about vulnerabilities that are uncovered in .NET core'? My response is straightforward: How do you handle XSS vulnerabilities in the web application? How do you handle SQLI issues in the web application? How do you handle vulnerabilities in jQuery or Boostrap or anything else in the web application? We have to draw a line between what is maintained by the systems/devops team and what is maintained by the development team. I can't fix an injection vulnerability (nobody wants me digging through source code). My responsibilities include OS patches, IIS configuration, etc. The web application itself (including anything specific to .NET core) fall on the dev team (just like any of the vulnerability possibilities I included above).

Not using the system runtime is no option.
We are deploying .Net Core micro services to Service Fabric.
There is a huge overhead (memory & storage) if every micro service deploys it's own .Net Core framework.

[blakeduffey]

In my experience the SCD (self contained deployments) applications do indeed have larger disk footprints than FDD (framework dependent deployments) - but not substantially larger. I think the application we are using SCD was something like 150MB larger? I'd have to look. If someone is running hundreds or thousands on a system maybe it would make a difference?

I'd be interested in hearing if someone has actually profiled an application (FDD vs SCD) and can provide a comparison regarding memory overhead?

[cremor]

The last few comments all miss a main point of this issue: Client applications.
What if you users can't/won't update to newer versions of your app? Then self contained deployment doesn't help at all.

[tjmoore]

What if you users can't/won't update to newer versions of your app? Then self contained deployment doesn't help at all.

A common situation with corporate customers. Many don't like to rock the boat and won't update something that works. Some will have a complex process of test & validation on software updates which in some cases can take weeks, months or longer!

Although some may be more accepting of patch releases where only security fixes are included, but the vendor is responsible for issuing these each time the .NET runtime has a security release, yet there's no other change to the product.

Official security releases via WU/WSUS etc still may have the approval/test process but often get through IT processes quicker as they're more trusting of patches direct from Microsoft than third party software vendors, and easier to manage.

That said, what about non-Windows? Products I'm working on currently are moving to .NET Core for cross-platform support and will be deploying on Linux as well as Windows. With Linux, there are package managers, and does the same situation apply or will fixes be brought in with package updates? (and if so, why not on Windows?).

[JaredShaver]

Yes, let's not forget corporate customers. Everyone is saying how easy it is for baking it into your build process is totally ignoring .NET Core (and soon to be 5) on client PCs and corporations that purchase software from 3rd partes. An accountant who bought a .NET Core client application from a 3rd party isn't going to have a clue about what a .NET is and getting new builds of their accounting software potentially every month. With .NET Framework, we can at least patch the runtime for clients.

This is going to eventually lead to a big issue when there is some wormable RCE in the .NET Framework that causes a mass headache like what happened with Java in 2013.

[TBBle]

I assume "Framework Dependent" deployment on Linux depends on the relevant .NET Core runtime having been deployed by some other mechanism. Ideally on a general-purpose system, this would be a .deb or .rpm-based package manager. .NET Core 2.1 and .NET Core 3.1 are published either through distro repositories or MS's own repository. It seems .NET 5 previews aren't being published to repositories yet.

So coming from the other direction, it makes sense that Windows Update would be able to update a system-install of .NET Core (as used by "Framework Dependent" applications), since Linux systems can (.NET Core 2.1 and .NET Core 3.1), or will (.NET 5) be able to.

Unless the team have dropped support for system-wide installs in .NET 5, have no plans to publish .deb and .rpm files, and just haven't told anyone yet? ^_^

Personally (and addressing the ticket title) I would not expect security updates to touch Self Contained Deployments, as in that case I am taking on the responsibility of tracking updates to .NET and distributing them to users.

That said, I wouldn't use SCD for applications I give to other people to install, but it makes perfect sense when I'm building things in containers, since I'm also taking on that responsibility for every other part of the container as well. There's already a container security-scanning ecosystem which I would hope would gain support (if it doesn't have it already) for telling me that my SCD .NET applications need updating.

[Indigo744]

The thing is, this title used to be more clear (_.NET Core 3: Patching strategy of client apps_) and is now VERY misleading for newcomers.

The OP never talked about SCD, and every other issue concerning the .Net Core patching strategy leads to this one (and were closed). Yet, its name does NOT reflect that.

@Spelt I believe the name should be changed (yes, again...) to reflect the current state of the debate, which is about the patching strategy of .Net Core (either 2, 3 or 5) as a whole (including SCD, of course, but not limited to).

[nakarnam]

Based on this thread, we conducted surveys, interviews and sought further customer feedback over the past few months. As per the findings, there are three key efforts we are focusing on, for .NET Core Update acquisition, deployment and servicing strategies, in the .NET 5 timeframe:

• Offering .NET core updates via Microsoft Update Channels
• Tooling for .NET core update discovery, detection and clean up
• ClickOnce support for .NET Core Apps

Majority of the Customers were interested in .NET Core Updates being offered via the Microsoft Update Channel (MU). There was interest in the updates being offered via Automatic updates, WSUS and Microsoft Catalog channels. This plan is under review currently for the infrastructure changes, cost and timelines. This proposal for offering .NET Core updates via Microsoft Update is applicable to Framework dependent deployments only for .NET Core. We have a new issue open to track this effort and provide further details & updates as we move forward. Please post any comments/feedback on the plan here.

For customers that want greater control and do not wish to leverage Microsoft Update, we are also working on tools for update discovery, detection and uninstall, in the .NET 5 timeframe. Planning for a command line experience which utilizes release metadata to recommend updates and provide details, based on user query or what's installed on the machine and can also be deployed at scale to know what's installed across an Enterprise, aiding in uninstalling older/insecure versions. Initial scope for .NET 5 would include both desktop and server scenarios for Windows platform. I will create a new issue to provide more details and reference it here.

For Self-contained deployments, where .NET Core runtime is bundled as part of an application - the app developer will continue to be responsible for servicing this. We are working on ClickOnce support for .NET Core apps – more details are available in the Deployment Tools repo here.

Will close out this issue and track feedback on these specific efforts separately.

[jamshedd]

Thanks for the update @nakarnam, I am going to close this issue out in favor of the new, more specific ones.

[Spelt]

Hi Jamshedd,

Why did you close it? Its not solved at all.

The first option should have been there already by MS but does not address the self contained executable problem.

The second option would be nice for some corporations. Great but does not address the self contained executable problem.

The third option is where its all about. The self contained executable.
The answer is that developers are still responsible for patching MS security holes in self contained .net core apps. Click-once publishing does not make a difference at all.

Not a solution at all.

REOPEN. We need a proper solution. Do not hide this thread by reopening it somewhere else and try to mute your users.

My proposal: Because It seems that MS does Not seem to find a solution for the problem.

Raise awareness: make sure that by every deployment there is an explicit popup that warns agains security vulnerabilities. Developers are never aware.
If you are not doing this MS could be legally complicit when shit hits the fan.
I dont want to see that.

[ernstscheithauer]

I suggest you do not use SCE packaging when developing software or disallow it in your operating environment if you want or need patching capabilities using windows updates. Microsoft provides both alternatives, self-contained and runtime-dependent methods to give developers and admins the choice.

Any developer doing SCE must be aware of the responsibility of patching, and any admin rolling SCE software into his/her servers or clients must accept this (or reject it).

I am glad we have runtime-dependent publishing model starting with .NET Core 3, since I am not a big fan of SCE. However, SCE serves a purpose and is a good tool to have in your workbelt for certain scenarios.

[jamshedd]

@spelt - @ernstscheithauer summarized this well. What we're giving is options - if an enterprise or LOB developer wants Microsoft to take care of patching, then the framework dependent deployment model is what they should go with. If on the other hand they want to retain tight control over the deployment environment and want to decide when and how to patch an app then the self-contained model would be more suitable.

In the former case the Microsoft ships an update, in the second the app developer is responsible for updating the runtime bits included with their app. Lack of support for such a self-contained deployment was a drawback of the old .NET Framework update model for some of our customers like banks with highly locked down environments and we got many asks for this. We understand this model is not something that works for everyone, so we still have the Framework dependent deployment model for those that prefer something closer to the old way.

[lennybacon]

Starting in December 2020, we will be delivering .NET Core updates on Windows via Microsoft Update.

https://devblogs.microsoft.com/dotnet/net-core-updates-coming-to-microsoft-update/