--On den 31 mars 2003 22:54 -0500 Jim Magee <jmagee@apple.com> wrote: We can make suggestions for the next architecture. Yes, this is what I meant. Apple is a big buyer and user of PPCs, and what the OS designers think of the chip should of course be fed back to the chip designers. I hope this already is the case, but the page-exec thing maybe is an issue that hasn't been brought up but should be. But we'll never have any luck changing the one that's sitting on your desk. I fully understand that you won't come over here and carve in the silicon in my box. :-) But you could change the OS to it for an, in my eyes, pretty small penalty for the programs. Others may think different. Besides, all this is on the assumption that you have to execute code on the stack. More common (from a PowerPC hack perspective) is to just change link register values saved on the stack to trick the program into running code that already exists (the blr instruction is used to both call and return from a function). The only stuff that has to be on the stack is the argument data and the stomped address. Jumping to the well-known address for the system() library routine should do nicely. ;-) As you said you have to have the argument(s) in place, but sure, there are other ways to crack it without having to deal with putting new code in the machine. So, we should also have separate data and link stacks! :-) Non-exec memory and capabilities and jails and *trusted* things and all the others are of course not elegant or The Correct Way to fix problems with software with security holes, still I think their popularity are the sad consequence of a reality that we just have to face. You may be right that the cache syncing issues makes PPC less susceptible to code insertion problems. /ragge _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.
participants (1)
-
Ragnar Sundblad