- trying to write data outside of "valid" buffer sizes
- get custom code to execute (shell w/ malicious programs etc.)
- or change behaviour of the program that is being exploited
- usually deamons with more privileges are targeted (ideally w/ root privileges)
- quite common because easily produced and cumbersome to protect against across a complex codebase (C and C++ are vulnerable by default)
- access to program required
- must be tailored for os'es and executable formats
- steps
- find usage of unchecked buffers in target program
- find address of code to be executed or values that will be manipulated to grant access to otherwise inaccessible resources
- write data to buffer that overwrites data beyond the intended size
- morris worm: unix fingerd vulnerability (1988)
- among the first "worms", buffer overflow in fingerd only one of the methods used (sendmail exploit and cracking too)
- infected ~6000 computers (ca. 10% of the internet then)
- fingerd uses
gets, the worm sends a request overflowing the request buffer and executing sh (bootstrapping itself on the now-infected machine and infecting other machines) - author Robert Tappan Morris, father NSA chief scientist, later founder of Y Combinator (VC firm/program) w/ Paul Graham; claims that the worm was intended to gauge the size of the internet
- 3 years probation, 400 hours community service, $10000 fine
- as a consequence founding of CERT/CC (internet security coordination center)
- running unlicensed code on the XBox (2003)
- part of the recent steam url protocol exploit (2012)
- comparitively "easy" to open a steam url without warnings
- the
retailinstallcommand loads asplash.tgafile into memory and that file could be crafted to execute malicious code (because of a buffer overflow)
-
use of "safer" library functions (i.e. checking bounds on array/buffer writes):
strncat, fgets, ... -
use of programming languages with array bounds checking (probably just about any "modern" language such as Java, C#, most interpreted languages, ...)
checks in languages have performance overhead, some of them can be eliminated with static analysis
-
running potentially vulnerable programs with lowest possible privileges (and/or sandboxing)