是否可以检测不受信任的程序集中的递归函数（c#）？
我正在编写一些 C# 来加载第三方程序集。
如果第三方决定是恶意的，他们可以编写一个递归函数，该函数最终会出现 StackOverflowException，从而导致我的应用程序崩溃。
是否可以检测递归函数？
更新： 对于像 while(true) 或 for(;;) 这样的不良情况，我已经有了解决方案。本质上，我在单独的线程中运行第三方代码，如果该线程花费的时间超过固定的持续时间，我就会拔掉插头。这对于递归来说效果不佳，因为很快就达到了堆栈限制。
更新： 也许我歪曲了我所追求的解决方案。如果我最终收到大量故意恶意代码，我将更改应用程序以在单独的进程中运行第三方代码。然而在这个阶段，我假设代码只会因为写得不好而导致问题。
接受答案 我决定最好的方法是在单独的进程中运行第三方库。我可以运行多个进程实例，甚至可以跨进程对第三方库进行某种负载平衡。如果执行的恶意代码杀死了其中一个进程，我应该能够检测到哪个库杀死了它，将该库标记为恶意，并使用所有非恶意库重新启动该进程。
感谢大家提出的很好的建议！
I'm writing some c# that will load a third party assembly.
If the third party decided to be malicious, they could write a recursive function that would end up in a StackOverflowException, bringing down my application.
Is it possible to detect a recursive function?
Update:
For undesirable sitations like while(true), or for(;;), I already have a solution. Essentially, I run the third party code in a separate thread, and if the thread takes longer than a fixed duration, I pull the plug. This doesn't work well with recursion since the stack limit is reached extremely quickly.
Update:
Perhaps I've misrepresented the solution that I'm after. If I end up getting a lot of intentionally malicious code, I'll change the application to run the third party code in a separate process. However at this stage, I'm assuming that the code will only cause problems because it's poorly written.
Accepted Answer
I've decided that the best approach would be to run the third party libraries in a separate process. I can have multiple instances of the processes running, and even do a sort of load balancing of my third party libraries across the processes. If malicious code is executed that kills one of the processes, I should be able to detect which library killed it, mark that library as malicious, and relaunch the process with all of the non-malicious libraries.
Thanks for everyone's great suggestions!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
在一般情况下做到这一点并不容易。此外，递归是一种有用的编程工具，完全禁止它并不是一个好主意。
更好的想法是在另一个进程中运行程序集，并使用进程间通信机制从受信任的进程中调用方法。
It's not easy to do that in the general case. Besides, recursion is a useful tool for programming and it's not a good idea to ban that completely.
A better idea is to run the assembly in another process and use an interprocess communication mechanism to call methods from the trusted process.
假设您找到了一种方法来完成不可能的任务并检测递归。伟大的。这有帮助吗？不会。没有什么可以阻止敌对程序集简单地用 throw 语句抛出异常。
此外，这是最不重要的问题。如果您有不受信任的恶意代码，它们会做比简单地抛出异常来停止进程更肮脏的事情。他们将试图窃取秘密信息、安装 rootkit，等等。敌对代码最不想做的就是抛出异常；这样做会引起人们对敌对代码的注意。它会触发将被分析的自动报告。敌对代码的作者希望避免被发现，而不是大声呼吁注意攻击！
如果您有部分受信任的第三方程序集，则使用我们为您提供的针对该具体场景的工具。与其尝试自己解决不可能的问题，不如将宝贵的时间用于使用代码访问安全系统，以实现其设计目的：处理部分信任的代码。
也许您想要研究的是 MEF，它是 VSTO 团队设计的一个框架，用于处理可能具有部分信任的托管加载项。 （多年前，我为 MEF 做过一些早期设计和安全审查工作，但我很早就离开了团队，而且无论如何都不是这方面的专家。）
Suppose you found a way to do the impossible and detect recursions. Great. Does that help? No. Nothing is stopping the hostile assembly from simply throwing the exception with a throw statement.
Besides, this is the least of your problems. If you have untrusted hostile code they are going to do a whole lot more nastiness than simply throwing an exception to take down the process. They're going to be trying to steal secret information, install rootkits, you name it. The last thing hostile code wants to do is throw an exception; doing so calls attention to the hostile code. It triggers automatic reports that will be analyzed. Authors of hostile code wants to avoid detection, not loudly call attention to the attack!
If you have a partially trusted third-party assembly then use the tools we have put at your disposal for that exact scenario. Rather than trying to solve impossible problems yourself, spend your valuable time using the Code Access Security system for what it was designed for: to handle partial-trust code.
Probably what you want to study up on is MEF, which is a framework designed by the VSTO team for handling managed add-ons that might have partial trust. (I did some of the early design and security review work for MEF many years ago but I left the team early on and am not an expert on it by any means.)
如果您真的担心的话，可以在程序集上使用反射并反编译它以查看代码。
http://www.red-gate.com/products/dotnet-development/反射器/
另一种选择是从本质上测试程序集并对其运行一些单元类型测试。
You could use reflection on the assembly and decompile it to see the code if you are really worried.
http://www.red-gate.com/products/dotnet-development/reflector/
Another alternative is to essentially test the assembly and run some unit-type tests against it.
如果您在 Visual Studio 中调试应用程序并禁用“仅我的代码”，您将能够在“调用堆栈”中看到递归调用。这是在 .net 中查找 stackoverflow 异常根本原因的一般建议
If you debug your application in visual studio and disable "Just my code" you will be able to see the recursive calls in the "call stack". That is the general recommendation for finding root cause of stackoverflow exceptions in .net
那么，在单独的线程中运行恶意程序集可能会降低此类问题的风险。但是，敌对线程可能很难或不可能关闭，因此您最好在单独的进程（由您自己的代码托管）中运行敌对代码。这为您提供了一些能力：
话虽这么说，我通常不认为拒绝服务攻击等是加载不受信任的代码时的主要问题，因为如果邪恶代码导致我的应用程序停止工作，我将停止使用邪恶代码。当邪恶的代码正在做一些我不知道的非常肮脏的事情时，我会感到担心。
最后，始终存在不允许用户将 C# 代码附加到您的应用程序的核心选项。您始终可以使用自己的特殊脚本语言来让用户访问他们需要的应用程序的任何部分。
Well, running the hostile assembly in a separate thread may reduce the risk of this kind of issue. However, a hostile thread may be difficult or impossible to shut down, so you would be better off running the hostile code in a separate process (hosted by your own code). This gives you a few abilities:
All that being said, I generally don't consider Denial of Service attacks and the like to be a major concern when loading untrusted code, since if evil code is causing my application to stop working, I'll just stop using the evil code. It's when the evil code is doing something really dirty that I am not aware of that I would get concerned.
Finally, there's always the nuclear option of not allowing users to attach C# code to your application. You could always just use your own special scripting language to give the user access to any parts of your application they need.