RE: Re[2]: Stack Overflow

["Rocky Heckman" <rocky.he () g-wizinnovations com>]

We're pretty much on the same page. The only thing I would want to clarify
is the processor instructions you refer to.  Most processor based BO
prevention is based on a non-executable bit or NX Bit (in Intel speak) and
not the instruction set of the processor. Keep in mind that when the code
finally gets to the processor, there are no such things as arrays, there is
only addresses and offsets. 

The NX bits at the hardware level work by marking certain regions of memory
as non-executable. So if the processor retrieves an instruction from that
section of memory and that instruction is not data but an JMP or ADD or
something is will not execute it and it will raise an exception to the OS.
The problem is, if the OS is not equipped to handle these errors, the NX bit
is essentially useless. (a bit of an overstatement for emphasis). 

I agree with what you said about programming languages. If you need the powe
rand flexibility to have fine grained control over memory and register
allocation, then you should be able to do that. You can, you just have to
use C/C++ and Assembler. For those that just want to knock up programs
without being coding gurus, the higher level, less-flexible languages are
the ones they should use. 

R

 
 
Rocky Heckman
G-Wiz Innovations Pty Ltd
http://www.g-wizinnovations.com
IT Peace of mind!
-----Original Message-----
From: jnf [mailto:lists () innocence-lost net] 
Sent: Wednesday, 12 January 2005 5:22 Early
To: Rocky Heckman
Cc: 'P. Schmiel'; security-basics () securityfocus com
Subject: RE: Re[2]: Stack Overflow

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