Randall R Schulz wrote:
On Friday 08 February 2008 11:53, Aaron Kulkis wrote:
Wolfgang Woehl wrote:
Other than *very* *old*, uncorrected code with buffer-overflow vulnerabilities, due to calls to strcat(3) instead of strncat(3), and similar pitfalls which are now very well understood since the first use in th 1987 Morris Worm, you have to provide some hard documentation (i.e. code sections) to make your point here. Aaron, buffer-overflows were a problem because applications can do
Aaron Kulkis: pretty much anything. No, they can't.
Programs can pretty much do what the object code files tell them to do. And nothing more.
That was one of the points I kept trying to make, but there is one exception:
You'll note in the description of buffer overflow vulnerabilities that accompany the patches that fix them it usually says something like "carefully crafted inputs could in principle allow an attacker to execute arbitrary code."
This is because if the attacker can put just the right stuff in the local buffer that can overflow (*) so as to replace the return address recorded in the stack frame to point into the buffer itself at a point where the nefarious binary instructions reside. Then, when the subroutine returns, instead of going back to its caller, it executes the attacker's code.
Which was the attack method used by the Morris Worm, and which also made strcat() and friends essentially obsolete in favor of the related length-limited equivalents such as strncat().
As you can see, this is tricky business and exploits have to be crafted for specific applications or libraries where unchecked buffers get filled from input received over the network (image data and the code that processes it have been the vector for many vulnerabilities exposed over the past few years).
(*) It has to be in an activation record / stack frame, since overflowing a buffer in the data area can't change the code now matter how far it overflows 'cause the instruction text is shared an unwritable in virtuall all modern Linux / Unix applications.
Randall Schulz
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org