Can there be an exploitable buffer overrun in the CLR ?
last June, at the Q&A session at the Pakistan Developer Conference in Karachi, an attendee asked : "Can there be an exploitable buffer overrun in the CLR?". My answer was that it is always possible in theory... I was really tired after five sessions back to back. I did not develop my answer enough. I am not an expert on the CLR, so I post this in hope to get some comments from more knowledgeable people on the subject.
Here are my thoughts :
- The CLR is definitely unmanaged, and thus, in theory it can have a buffer overrun. No Developer is beyond making mistakes, and there certainly could be a buffer overrun. the problem is whether it can be exploited, and if so, how...
- One shouldn't confuse the CLR with the .Net Framework : we develop in managed code against the built-in classes of the .Net Framework. this means that any exploitable buffer overrun that would surface in our applications would have to be there on the classes we develop. This means that if a buffer overrun on CLR is to be exploited through managed code, it has not only to be there on the CLR, but also to re-surface through some of the .Net Framework classes (calls to managed heap allocation for example, without validating values before making the call to the CLR). then, our own code would have to have the same flaw again... that means that the same flaw, applying to the very same value, would have to exist in three separate layers. The probability is so low that, even if it is theoritically possible, it remains so improbable that one should dismiss its possibility. There is a higher chance of having a class in the .Net framework itself having a buffer overrun in a native call, than having a CLR buffer overrun re-surface.
- Can there be an unmanaged call to the CLR exploiting a possible buffer overrun ? I will address this in a coming post
Anyway, I realize the question's main objective is to find out whether it is possible to defeat the managed code security messaging. No matter whether there is a possible theoritical buffer overrun exploit (which will be, in any case so improbable that it is virtually impossible), it is very clear that the managed code is hundreds of times more secure than unmanaged...
.Net | main
8/6/2004 3:15:22 PM UTC 
|
|