Security Basics mailing list archives
RE: Re[2]: Stack Overflow
From: jnf <lists () innocence-lost net>
Date: Tue, 11 Jan 2005 11:22:22 -0700 (MST)
While I mostly agree with everything you said- my intended point was that the 'problem' was mostly a 'flaw' with the underlying processor instruction set and it not enforcing boundries, thus given the right circumstances (a bug in the jvm for instance), would allow you to overflow an array in one of such languages. However I call it a 'flaw' instead of a flaw simply because its a trade off you kinda have to make, if the chip had to keep track of the boundries and understand that segments x through y of the stack are one logical stack frame, and array z is n through l, etc- then you would bog down the chip quite incredibly, thus the most logical reason this happens- a trade off between security and speed. /me climbs onto his soap box While I agree that the newer languages are safer and in many respects better because of the idea that you do not have to keep track of memory so closely, I also feel that its very necessary that a language allow you to hang yourself if thats what you want to do (say i want to flip bits on a string in java for whatever reason), however thats just my personal opinion in a professional sense, I'd much prefer to see programmers who enter the universities be taught the less forgiving languages first so that a concept of memory management and how memory is organized/etc is understood, and then moving onto languages where it is less important. If anything, while memory management itself falls to the OS, overflow protection logical falls to the compiler, not to the OS (think again what it would take to keep track of everything), plus there will always been 6 million ways to die, every language has its own inherant flaws (security wise), and while trying to find a bug in your given jvm and find a buffer overflow would be quite interesting, you would probably spend less time trying to find any one of the insecurities in java applications that exist simply because its so easy to learn (and thus so many poorly written applications). To reiterate my original statement, possible yes, probably no. j -- There are only two choices in life. You either conform the truth to your desire, or you conform your desire to the truth. Which choice are you making? On Tue, 11 Jan 2005, Rocky Heckman wrote:
Date: Tue, 11 Jan 2005 16:14:06 +1100 From: Rocky Heckman <rocky.he () g-wizinnovations com> To: 'P. Schmiel' <secfoc () cybernox net>, security-basics () securityfocus com Subject: RE: Re[2]: Stack Overflow 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)