Messages in this thread | | | Date | Tue, 28 Dec 1999 14:54:43 -0600 (CST) | From | Jesse Pollard <> | Subject | Re: Unexecutable stack |
| |
"Richard B. Johnson" <root@chaos.analogic.com>: ... >We have never had a known, provable break-in of any kind, not >counting the engineers blue-screening the Windows machines >by throwing funny packets at them. > shows how good they were...:) or how uninteresting your work is to the hacker community.
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/
| |