Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Remove CAS era security checks around resource loads and stack crawls #21629
I assume everything related to
Unfortunately, there is a ton of legacy APIs that were added during netstandard2.0 push whose behavior depend on the caller. The caller is basically passed in as an implicit argument to the API. Most of these StackCrawlMarks are there to support these APIs. There may be a few that are doing this by accident, but I do not think it is possible to cleanup most of this without breaking stuff.
Yes, this one can be cleaned up probably. The flag is passed in through many layers. It should be cleaned up from all layers - it will allow us to double check that it is not used by anything important.
referenced this issue
Jan 2, 2019
I did some further analysis and found that not only the checks are quite useless security-wise, but some of them have been broken for quite a while.
Effectively the check listed in the previous comment says that private embedded manifest resources are allowed to be accessed when the caller is the within the same assembly as the resources (or a friend assembly).
The documentation says that it should be allowed to access those private resources when
So the only thing that should actually be prevented is the visibility check with
Another problem is that the stack crawl mark is not always passed through correctly. Look at the following code:
Numerous other comments suggest that the checks are not very useful (and sometimes propagate stack mark pointing into CoreLib too):
The above code in
This doesn't consider friend assemblies though, which should be allowed to access private resources.
Most of the problems went unnoticed because there are no tests for it. The private embedded manifest resources are also extremely rare. CoreRT doesn't have any of the checks.
This issue should be resolved in order to allow moving rest of
What is the preferred solution?
DisablePrivateReflection is about preventing invocation (i.e. running code). It does not prevent inspection (ie. reading stuff - getting MethodInfo for private methods, etc.). Resource reading is inspection.
I think we should remove these checks altogether.
Thanks for a great analysis!