A large number of exploits have been due to sloppy software development.
Exceeding array bounds is referred to in security circles as "Buffer Overflow."
Buffer Overlows are targetted on Stack and Heap.
As a Researcher, where should you look at the BufferOverflows in the target programmes ?
- Stack allocation - Is it randomised ??
- Unchecked array index usage
- Copying a given argument into a local array - Is the code checking the length of input ??
- Supplying a carefully constructed string argument - Is the code restricting malicious inputs??
- The string has the executable machine code -- Does the memory have executable permissions ??
How to Detect the Buffer Overflow Scenarios
- Checking the caller of
execv system call - Deep packet inspection - monitong for payloads
- Tools: Chaperon, Valgrind, CCured, CRED, Insure++, ProPolice and TinyCC, many more.
ProActively Prevet your programme to get exploited.
- CPU/MMU: Separate address spaces for Data and Machine Instructions
- noexec-user-stack
- Never-eXecute (NX) bit http://en.wikipedia.org/wiki/NX_bit
- Intel: XD bit, eXecute Disable
- AMD: Enhanced Virus Protection
- ARM: XN for eXecute Never
- Stack top randomization
- ASLR Address space layout randomization
- Run-time Check for Input Taintedness
- Run-time Check for Array Bounds
In SDLC LifeCycle, where can you have the Buffer Overflows identified and fixed ?
1. Source Code Development stage
2. Product alidation stage