C# 中是否可能存在缓冲区溢出漏洞?
假设 C# 程序仅使用托管 .NET 代码,该程序中是否可能存在缓冲区溢出安全漏洞?如果是这样,这种漏洞怎么可能存在?
Assuming that a C# program uses only managed .NET code, is it possible to have a buffer overflow security vulnerability within that program? If so, how would such vulnerability be possible?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
是的,但它们的生产要困难得多。仅当您使用某些不安全的构造(而不是“正常”的 C# 代码)时,才会出现缓冲区溢出。当您的代码以较低的信任度运行时,内存损坏代码根本不可能发生。
缓冲区溢出的一些可能性:
unsafe
关键字。不安全的代码与 C 或 C++ 中基于指针的代码一样容易出错。Marshal
类中的方法除了缓冲区溢出。
StructLayoutKind.Explicit
(运行时本身是用 C++ 编写的,因此运行时中的错误也可能损坏内存或溢出缓冲区,但我认为这超出了此范围问题)
Yes, but they are much harder to produce. You can only get buffer overflows if you use certain unsafe constructs, not with "normal" C# code. Memory corrupting code shouldn't be possible at all, when your code is running with lowered trust.
A few possibilities for buffer overflows:
unsafe
keyword, which allows pointers. Unsafe code is just as easy to get wrong, as pointer based code in C or C++.Marshal
classThere are also a few other ways to corrupt memory apart from buffer overflows.
StructLayoutKind.Explicit
(The runtime itself is written in C++, so a bug in the runtime can also corrupt memory or overflow a buffer, but I consider that out of scope for this question)
是的,在不安全的环境中:
必须检查“允许不安全代码”才能编译。
您不能使用数组来实现传统的缓冲区溢出。它会在访问数组之前进行边界检查,除非它(CLR)可以保证它是安全的。
Yes, in unsafe environments:
"Allow unsafe code" has to be checked for this to compile.
You can't a traditional buffer-overflow with an array. It will do bounds-checking before accessing an array unless it (CLR) can guarantee it is safe.
仅当您使用
不安全
关键字。
Only if you use the
unsafe
keyword.从绝对意义上来说,是的,由于 .NET 运行时中的错误,缓冲区利用是可能的。然而,.NET 可以防止大多数最终用户代码(“不安全”使用除外)出现此类问题,因此在现实生活中风险较小。
在现实生活中,大多数此类问题都是由托管代码调用的本机调用(COM dll 等)引起的。
In an absolute sense, yes a buffer exploit is possible due to bugs in the .NET runtime. However .NET prevents most end user code (except 'unsafe' usage) from these sorts of problems so in real life it's less risky.
In real life, most problems like this will occur from native calls (COM dlls etc) invoked from managed code.