469,929 Members | 1,413 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,929 developers. It's quick & easy.

Are buffer overrun exploits impossible in managed code?

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

Jul 21 '05 #1
3 1763
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

Jul 21 '05 #2
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


Jul 21 '05 #3
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


Jul 21 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by inkapyrite | last post: by
9 posts views Thread by Sathyaish | last post: by
1 post views Thread by John Hensley | last post: by
8 posts views Thread by Martin Eisenberg | last post: by
reply views Thread by Lonewolf | last post: by
331 posts views Thread by Xah Lee | last post: by
15 posts views Thread by raashid bhatt | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.