I work at a DoD center, and yes there are attacks that work. We have a
twice yearly examination by professional "hackers". They broke into a
Sun E4500 in 1 second via an unknown (to us) stack overflow. They were
in and out with root login, and didn't even need a user login to start with.
We had to disconnect the system. They actually broke into half the SGI
systems we had, though some of the tests carried
out failed (we mount user writable file systems "nosetuid, nosetgid") for
additional protection. NFS filesystems do not get root access. In
addition /usr/local (where we store third-party software) is exported read-only
Is it enough? no.
Does it help? definitely.
Will the vendor fix the bugs? no.
Do I still have to find workarounds to try to cover the bugs? yes.
Would a non-executable stack help? definitely
Anything that adds layers of protection is a benifit. Even if the attack
is a denial of service, it is better to not let them in, than provide
potentially lethal (to people) modifcations to data/applications to occur.
I do get paranoid about that.
>>
>> You don't quite seem to understand the mechanism of stack buffer
>> overflow exploits. The buffer overflow does not cause an
>
>I understand it exactly and precisely. It is likely that I was
>the first to demonstrate this in the late '70s.
In the early 70's it was called "load-and-go" compilation/execution. Also
known as "self-modifing-code" (and was called "bugs" too). (fastest infinite
loop was done via the stack - store a mov r0,@array in the first element
of the array (allocated on a stack of course) then do a return 1; the parameter
of the fortran call was the array, instead of the statement label. All on
a PDP10 in '72-73. The infinite loop was in the addressing component - it never
finished fetching the data from memory....)
It was designed into the PDP-11 instruction set (the MARK instruction) to
provide high performance stack unwinding. Nobody with any sense actually
used it because it could not be debugged with any certainty.
On the older PDP-8 (no hardware stack at all) the software stack was
modified on the fly to generate diagnostic code in the DDCMP network
protocol layer used by remote job entry stations. The entire RJE software
fit into 8K of 12 bit words.
It's a very old technique.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/