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.

 

[bwahahahaha]

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

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.

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.

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.

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

 

[Jeffrey Tan[MSFT]]

Hi David,

For your IIS question, I think the main concern of the IIS is security and
performance.
While the .Net is mainly used as Web application, so its executive
performance is not fit for IIS.
For your security concern, you can refer to the IIS 6.0, it expose many new
features for the customer.
It helps you to achieve goals of performance, reliability, scalability, and
security for Web sites.

For more details of IIS6.0 new features, please refer to the link below:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechn
ol/windowsserver2003/proddocs/standard/gs_features_top.asp

Thanks for your feedback. If you still have any question, please feel free
to let me know.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

--------------------
| From: "David Sworder" <[email protected]>
| Subject: Are buffer overrun exploits impossible in managed code?
| Date: Wed, 15 Oct 2003 13:33:30 -0700
| Lines: 29
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
| Message-ID: <#[email protected]>
| Newsgroups:
microsoft.public.dotnet.general,microsoft.public.dotnet.languages.csharp
| NNTP-Posting-Host: rrcs-west-66-27-51-213.biz.rr.com 66.27.51.213
| Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.phx.gbl
| Xref: cpmsftngxa06.phx.gbl
microsoft.public.dotnet.languages.csharp:191637
microsoft.public.dotnet.general:112035
| X-Tomcat-NG: microsoft.public.dotnet.languages.csharp
|
| 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
|
|
|
|