Are buffer overrun exploits impossible in managed code?

[David Sworder]

Hi there,

I come from a Visual C++ background. When writing a service that's
exposed to the Internet, I had to check the incoming data stream (from the
client) VERY carefully. If a hacker was able to overflow one of the memory
buffers in my app, he was then able to execute code of his choosing within
the security context of the service. This led to all sorts of precautionary
measures such as ensuring that the service ran in a low-access context,
checking and double-checking all the char[] buffers, etc.

In C#, certainly I can overflow a buffer:

char[] chars=new char[5];
chars[666]='c';

....but while an exception will be thrown, I shouldn't have to worry
about a hacker intentionally corrupting the call stack and executing his own
code, correct? Now certainly there might be OTHER vulnerabilities in my
service, but I just want to ensure that if my code is fully managed (no
unsafe code), I shouldn't have to worry about buffer overrun exploits...

As a secondary question, does MSFT have any plans to rewrite IIS using
..NET? IIS is, after all, the grandfather (or perhaps, great aunt) of the
buffer overrun error.

David

[Bruno Jouhier [MVP]]

If your code is 100% managed code, you do not need to worry about buffer
overruns. You are on the safe side!

Only problem could be if there is a bug in the .NET VM itself, or in a non
managed component that your application may call.

You should be careful about infinite recursion. Normally, the VM should
throw a StackOverflowException in this case but there are cases where it
does not catch it early enough and where it crashes (does not contradict my
previous statement, this is a bug in the VM). This leaves a door open for
hackers (probably a difficult one to exploit but who knows).

Bruno.

"David Sworder" <ds******@cts.com> a écrit dans le message de
news:%2****************@TK2MSFTNGP12.phx.gbl...

Hi there,

I come from a Visual C++ background. When writing a service that's
exposed to the Internet, I had to check the incoming data stream (from the
client) VERY carefully. If a hacker was able to overflow one of the memory
buffers in my app, he was then able to execute code of his choosing within
the security context of the service. This led to all sorts of precautionary measures such as ensuring that the service ran in a low-access context,
checking and double-checking all the char[] buffers, etc.

In C#, certainly I can overflow a buffer:

char[] chars=new char[5];
chars[666]='c';

....but while an exception will be thrown, I shouldn't have to worry
about a hacker intentionally corrupting the call stack and executing his own code, correct? Now certainly there might be OTHER vulnerabilities in my
service, but I just want to ensure that if my code is fully managed (no
unsafe code), I shouldn't have to worry about buffer overrun exploits...

As a secondary question, does MSFT have any plans to rewrite IIS using
.NET? IIS is, after all, the grandfather (or perhaps, great aunt) of the
buffer overrun error.

David

[bwahahahaha]

or something that MS wrapers, since its unmanaged code theyre wrapping isnt
it. Thats all the libraries are, wrappers to the unmanaged side.

"Bruno Jouhier [MVP]" <bj******@club-internet.fr> wrote in message
news:u5*************@TK2MSFTNGP11.phx.gbl...

If your code is 100% managed code, you do not need to worry about buffer
overruns. You are on the safe side!

Only problem could be if there is a bug in the .NET VM itself, or in a non
managed component that your application may call.

You should be careful about infinite recursion. Normally, the VM should
throw a StackOverflowException in this case but there are cases where it
does not catch it early enough and where it crashes (does not contradict my previous statement, this is a bug in the VM). This leaves a door open for
hackers (probably a difficult one to exploit but who knows).

Bruno.

"David Sworder" <ds******@cts.com> a écrit dans le message de
news:%2****************@TK2MSFTNGP12.phx.gbl...

Hi there,

I come from a Visual C++ background. When writing a service that's
exposed to the Internet, I had to check the incoming data stream (from the client) VERY carefully. If a hacker was able to overflow one of the memory buffers in my app, he was then able to execute code of his choosing within the security context of the service. This led to all sorts of

precautionary

measures such as ensuring that the service ran in a low-access context,
checking and double-checking all the char[] buffers, etc.

In C#, certainly I can overflow a buffer:

char[] chars=new char[5];
chars[666]='c';

....but while an exception will be thrown, I shouldn't have to worry
about a hacker intentionally corrupting the call stack and executing his

own

code, correct? Now certainly there might be OTHER vulnerabilities in my
service, but I just want to ensure that if my code is fully managed (no
unsafe code), I shouldn't have to worry about buffer overrun exploits...

As a secondary question, does MSFT have any plans to rewrite IIS using .NET? IIS is, after all, the grandfather (or perhaps, great aunt) of the
buffer overrun error.

David

[Eric Gunnerson [MS]]

If all your code is verifiable code, then you don't have to worry about
buffer overruns in your code. If you use unsafe code in C#, you can end up
buffer overruns as you can in C++.

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.
"Bruno Jouhier [MVP]" <bj******@club-internet.fr> wrote in message
news:u5*************@TK2MSFTNGP11.phx.gbl...

If your code is 100% managed code, you do not need to worry about buffer
overruns. You are on the safe side!

Only problem could be if there is a bug in the .NET VM itself, or in a non
managed component that your application may call.

You should be careful about infinite recursion. Normally, the VM should
throw a StackOverflowException in this case but there are cases where it
does not catch it early enough and where it crashes (does not contradict my previous statement, this is a bug in the VM). This leaves a door open for
hackers (probably a difficult one to exploit but who knows).

Bruno.

"David Sworder" <ds******@cts.com> a écrit dans le message de
news:%2****************@TK2MSFTNGP12.phx.gbl...

Hi there,

I come from a Visual C++ background. When writing a service that's
exposed to the Internet, I had to check the incoming data stream (from the client) VERY carefully. If a hacker was able to overflow one of the memory buffers in my app, he was then able to execute code of his choosing within the security context of the service. This led to all sorts of

precautionary

measures such as ensuring that the service ran in a low-access context,
checking and double-checking all the char[] buffers, etc.

In C#, certainly I can overflow a buffer:

char[] chars=new char[5];
chars[666]='c';

....but while an exception will be thrown, I shouldn't have to worry
about a hacker intentionally corrupting the call stack and executing his

own

code, correct? Now certainly there might be OTHER vulnerabilities in my
service, but I just want to ensure that if my code is fully managed (no
unsafe code), I shouldn't have to worry about buffer overrun exploits...

As a secondary question, does MSFT have any plans to rewrite IIS using .NET? IIS is, after all, the grandfather (or perhaps, great aunt) of the
buffer overrun error.

David