![](https://seccdn.libravatar.org/avatar/31cd99395e30a53f253916c2227a4e14.jpg?s=120&d=mm&r=g)
On Sunday 19 January 2003 6:24 pm, Carlos E. R. wrote:
The 03.01.19 at 07:52, zentara wrote:
... grsecurity kernel patch ... make the stack non-executable. BUT it breaks alot of programs, notably X. ...
Now that makes me wonder... why would the stack need to be executable? It should only be needed for local data and return address for subroutines, and things lke that, no? Or does somebody uses hacks like selfmodifying code?
hence the point of my original comment on program vs. data segmentation -- "self modifying code" has never [in my book at least], been "good", and with the advent of virii, I've downgraded such actions as "very bad indeed" [OTOH, I do recall once making a text editor macro for a mini/mainframe that essentially worked as a mail-merge operation in which the only way to practically create it was to make it self modifying, but that doesn't really count :) :) :) ] My point is that DATA should never be considered EXECUTABLE CODE -- if that simple restriction were built into various OS's [and/or Unix in particular], then an entire segment of "buffer overrun" cracks would never exist to be reported in the various security/bug tracking reports. [OTOH, "buffer overruns" might cause a program to do something unexpected, like build, purge, or just plain access the wrong file, but you couldn't "execute arbitrary code" because of such an attack] Tom minor point: "return addresses for subroutines" -- you'd have to be very clever indeed to modify a "return address" so that a different function gets called to "do the dirty work" you intend "as a trojan" and yet still appear to "function normally" so far as the end-user is concerned -- most likely any such attempt would make the program simply abort, which would raise suspicion...