[OCLUG-devel] arrays

[Hugo Samayoa]

James Colannino wrote:

>Christopher Smith wrote:
>
>  
>
>>C doesn't have any bounds checking so it's not going to stop you from
>>accessing data outside the array. Now, depending on how the allocator
>>is setup, there may be some "padding" around your array that prevents
>>really bad things from happening. In terms of what could go wrong?
>>Well, this is a classic example of how stack overflows occur. You're
>>writing past the end of the stack-allocated array, which means you're
>>writing all over the stack. I'm guessing you aren't having a problem
>>because you're exiting immediately after this. However, if this was in
>>a subroutine, then when you return, the subroutine would pop off the 5
>>bytes of your array and any arguments that were passed in, and then
>>pop off the return address. If the return address has been overwritten
>>by your array data, then it'll jump somewhere unanticipated. In most
>>cases this will be a segmentation fault because it'll be a totally
>>invalid address (which should be happening in this case). Sometimes
>>though, you can be unfortunate enough to write in an address that is
>>valid, at which your program will jump to that location and attempt to
>>execute instructions. Very, very messy.
>>    
>>
>
>
>By the way, I'm just curious, does the kernel ever do anything about a
>situation in which a process attempts to execute corrupted
>instructions?  I guess there's probably not much it could do, but does
>the kernel at least protect you from truly dangerous things that could
>result from the random contents of a variable being executed as
>instructions?  I'm guessing that since the kernel takes full control of
>the hardware it would probably protect you at least to a certain
>extent.  Perhaps such a thing could cause a kernel panic?
>
>James
>
>  
>
There's 5 ways to go about this...
1) Patch GCC to do bounds checking. > 
http://web.inter.nl.net/hcc/Haj.Ten.Brugge/
2) Use a tool to prevent smashing of the stack ie StackGuard or Stack 
Shield <- Protects EIP
3) Use a source code auditor ie RATS <- Posting your code to the list is 
also good.
4) Install a kernel patch that makes the stack non-executable. <- Just 
makes it harder to exploit.
5) Read some Buffer Overflow books, texts:
Aleph One's Smashing the Stack For Fun and Profit 
http://community.core-sdi.com/~juliano/smashing/P49-4-Smashing_the_stack.txt
Mudge's How to write Buffer Overflows 
http://community.core-sdi.com/~juliano/l0pht-howtowrite-bof.html

Good Book to start with.
Foster - Buffer Overflows ISBN - 1932266674


-Hugo Samayoa
Research Enginner @ eEye Digital Security