Security Basics mailing list archives
RE: Re[2]: Stack Overflow
From: "Rocky Heckman" <rocky.he () g-wizinnovations com>
Date: Tue, 11 Jan 2005 16:14:06 +1100
Hello list, "... that the memmory handling is the operating systems job. for .NET i know, that there are possibilities 4 overflows, because some functions have a quite "open" memmory handling. and " This is not entirely correct. The original reason for buffer overflows is due to array and variable mis-management by the application, not the OS. An OS can help monitor BOs but it is not the sole guardian. This is how BOs can be exploited on 'secure' platforms. Windows Server 2003 and BSD all have built in BO protection. However if an application is not compiled with the proper switches to enable it to be monitored, you can still exploit a vulnerable application on a secure OS. If you write a C/C++ program with a stack allocated array, and do not perform bounds checking on that array, you have a BO vulnerability. There is very little the OS can do about this until you overwrite the array to the point of affecting the stack frame. If you have a C/C++ function that has a locally allocated variable which is a pointer to an object and then an array with no bounds checking, that array can be overflowed just enough to change the value of that pointer variable. This is a successful overflow which the OS can not prevent because you haven't overwritten anything the OS is monitoring. The OS itself monitors canary regions around the stack frame. If the entire overflow happens between the canaries, the OS will never know that a problem occurred. Java, and .NET handle this differently. Arrays, which are most commonly associated with overflows, are checked by the JVM and CLR respectively. So if something attempts to write 12 items into an array designed to hold 10, the JVM/CLR throws an exception. This is NOT the Operating System. This is a layer above that. The 'Open' memory handling in .NET is not a problem because the CLR is constantly monitoring memory allocations and making sure that .NET based code is not writing to locations that are not dedicated to the code. All those memory locations are monitored, and destroyed/cleaned up by the garbage collection system. While the GC doesn't have much to do with preventing Overflows, it does prevent "memory leaks" although .NET can leak memory if interacting with unmanaged code as I've discovered. However, like I said previously, if you incorporate unmanaged C++ into your .NET applications, you can create BO problems because unmanaged memory is not monitored in this way. As long as you are using managed code, be that Java, or .NET you should not have Overflow problems. "... in my opinion, this is important because a programming language must gave you all possibilities it can, and not restrict you in any way." (drags out soapbox) That may be true, and if you feel that way you should stick to C/C++. In my opinion, there is an epidemic of fresh graduates out there that have never seen a secure coding course. They do not know what a buffer overflow is nor how to prevent them. In the industry rush to get code to market they are being put on the front lines and forced to cut code to impossible deadlines. There is little if any security checking in code reviews. It is this world we live in and it is ripe for causing sloppy code. By having systems such as .Net and Java that monitor this kind of thing, you give up some freedom and functionality for security and simplicity. While .Net and Java may restrict what you can do, they help curb the problematic code leaking into the market today. They won't help to create unbreakable code, but they can help stem the tide a bit. (steps off soapbox) We now return you to your regularly scheduled program. Rocky Rocky Heckman G-Wiz Innovations Pty Ltd http://www.g-wizinnovations.com IT Peace of mind! -----Original Message----- From: P. Schmiel [mailto:secfoc () cybernox net] Sent: Tuesday, 11 January 2005 10:48 Early To: security-basics () securityfocus com Subject: Re[2]: Stack Overflow Hello list, I don't have much knowedge about java, but i'm quite sure that there can be overflows. the reason for this is, that the memmory handling is the operating systems job. for .NET i know, that there are possibilities 4 overflows, because some functions have a quite "open" memmory handling. and in my opinion, this is important because a programming language must gave you all possibilities it can, and not restrict you in any way. maybe the chance to create an overflwable code has decreased, but it's not impossible. well... thats my point of view, but i'm open for other perspectives and other opinions. (sorry 4 my bad english ;)) Original message Monday, January 10, 2005, 10:23:54 PM: BZ> Hi, BZ> I have done some Java programming but not an expert. I'd be interested in BZ> knowing how this can be accomplished, since you cannot manipulate pointers BZ> in Java and arrays are bound-checked. Do you have any examples? BZ> Best Regards BZ> Beilin Zhang BZ> -----Original Message----- BZ> From: P. Schmiel [mailto:secfoc () cybernox net] BZ> Sent: Monday, January 10, 2005 12:29 PM BZ> To: security-basics () securityfocus com BZ> Subject: Re: Stack Overflow BZ> Hello list, BZ> well, sure they can. it's the coders job to make a good code. and the BZ> OSs job to manage the memory correct. BZ> Original message Monday, January 10, 2005, 2:11:03 PM: NS>> Hi list, NS>> My question is: can programs made with newer languages (Java and NS>> .NET) have buffer overflow exploits? NS>> Tnx, NS>> Nelson Santos BZ> --- BZ> Best regards, BZ> Pascal Schmiel BZ> schmiel () cybernox net --- Best regards, Pascal Schmiel schmiel () cybernox net
Current thread:
- Stack Overflow Nelson Santos (Jan 10)
- Re: Stack Overflow P. Schmiel (Jan 10)
- RE: Stack Overflow Rocky Heckman (Jan 10)
- <Possible follow-ups>
- RE: Stack Overflow Beilin Zhang (Jan 10)
- RE: Stack Overflow lists (Jan 10)
- Re[2]: Stack Overflow P. Schmiel (Jan 10)
- RE: Re[2]: Stack Overflow Rocky Heckman (Jan 11)
- RE: Re[2]: Stack Overflow jnf (Jan 11)
- RE: Re[2]: Stack Overflow Rocky Heckman (Jan 12)