I'm currently working on a .NET 5.0 Blazor Server project that imports and utilizes user-uploaded .NET assemblies (in either DLL or NUPKG form). Currently, these assemblies are loaded using Collectible AssemblyLoadContexts which, if I understand correctly, is a major security hazard for both my user-base and the server itself. That said, I'm searching for methods that can sandbox the inclusion/execution of those assemblies. The main concerns that I can think of are:
Access to sensitive system information/environment variables
Access to processes
Access to internet (sockets/clients)
File System access
but I probably haven't thought about a plethora of other factors I should be aware of.
How could I achieve such feat?
ps: The server runs on a Linux machine and all uploaded assemblies must be valid architecture-irrelevant .net5 or .netStandard2.0 in order to be loaded.
Related
(If this question is poorly worded, could someone please help me clear it up?)
I have an Azure Function (2.0) which relies on some System.Drawing code. I've added a NuGet reference to System.Drawing.Common (4.5.0).
After publishing the app, however, when the function is called, it produces the error:
System.Private.CoreLib: Exception while executing function:
[MyFunctionName]. System.Drawing.Common: System.Drawing is not
supported on this platform.
As far as I'm aware, System.Drawing.Common is supported on .NET Core now, which I believe is the environment in which my Azure Function is running. The actual project is a .NET Standard 2.0 project, though.
I am confused as to how to resolve this. I've tried converting the project to a .NET Core 2.1 project but that led to bizarre errors related to "Metadata generation failed" and an inability to find System.Runtime.
My project references Microsoft.Azure.WebJobs.Extensions.EventGrid (2.0.0-beta2) if that's relevant.
It's not about the CLR, it's about the sandbox.
System.Drawing relies heavily on GDI/GDI+ to do its thing. Because of the somewhat risky nature of those APIs (large attack surface) they are restricted in the App Service sandbox.
Win32k.sys (User32/GDI32) Restrictions
For the sake of radical attack surface area reduction, the sandbox prevents almost all of the Win32k.sys APIs from being called, which practically means that most of User32/GDI32 system calls are blocked. For most applications this is not an issue since most Azure Web Apps do not require access to Windows UI functionality (they are web applications after all).
Try to find an different library that doesn't rely on System.Drawing/GDI, like ImageSharp.
A little update can help a lot of people.
Now you can switch your Azure Function to v3:
in Function app settings panel -> Runtime version ~3
With this setup, your code run in a sandbox that support Core 3, (you don't need to rebuild your dll to Core3, i run my .net core 2.1 dll without errors), and surprise... you don't get this exception anymore:
System.Drawing.Common: System.Drawing is not supported on this platform.
Because the CLI can found GDI/GDI+ that need in the subsystem.
Now i can convert html to pdf without go crazy.
When I "publish" or "package" the Azure "cloud service" WCF that I have, does the publish or package actually include the source codes for my application or is just the binary that is getting published. Is there a way that Microsoft can see the code of my application? Is it safe to assume that the actual C# codes are not being published or be seen in the Microsoft server? If binary is being published, there is no way for a binary to be reverted back to source code right? I'm just trying to protect my intellectual property.
The binaries get deployed.
Any .NET library can be decompiled pretty trivially, though there are obfuscation tools that make the decompiled code more difficult to read (See Open Source Alternatives to Reflector? for a discussion on open source decompilers).
Personally I wouldn't be concerned about Microsoft decompiling and stealing your IP. Anyway, any hosting provider would have similar access to your deployments.
In a normal ASP.NET Website there is a Web Deployment Project that we can use to pre-compile our entire website and then we can safely upload this project to our production server in order to protect our code.
What can we do for ASP.NET MVC 2?
Link to it as is available today (RTM version)
Visual Studio® 2010 Web Deployment Projects - RTW
Make sure you install the latest security patches for your operating system and hire a good network administrator. No kidding. No matter what you do if a hacker gains control over the server he will get the code under one form or another even if it is precompiled. This being said it is a good idea to precompile the application and deploy only the assemblies instead of the source code. You could also consider obfuscating it also but this is something usually done for client applications which you deploy to your users computers and less frequently done in server side applications because you control the server.
I was going to try Subsonic, you can generate DAL with buildProvider element in an ASP.NET website project. But I get curious why Web applications or windows applications do not support BuildProvider.
PS: I know for Subsonic there is one other option to use it with other than BuildProvider, but I just get curious.
It doesn't work because of the different way things are compiled in web application projects vs. website projects. From what I read on MSDN, it has to do with the fact that in web app projects, all your code files are compiled into a single assembly using MSBuild before deployment, but Build Providers are used to generate code that is compiled at runtime (from your App_Code folder).
In website projects, all of your code is compiled at runtime so it all plays nicely together.
You could possibly hook it into your pre-build event, and call the sonic.exe with the proper command line.
This is related to the this question and the answer maybe the same but
I'll ask anyways.
I understand that we can start managed executables from the network from .NET
3.5 SP1 but what about assemblies loaded from inside the executable?
Does the same thing apply?
You have been able to load Assemblies from the network at leasst from .NET 2.0. I have used this on a previous project. The only thing to watch is the size of the assembly and the number and size of the dependancies that it is loading.
If you are using a seperate AppDomain, then you will need to take special consideration of the dependancies.
My understanding is yes, you're trying to load an untrusted module into your local app domain.