INFO-VAX Sun, 24 Aug 2008 Volume 2008 : Issue 463 Contents: Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS ---------------------------------------------------------------------- Date: Sun, 24 Aug 2008 03:51:55 -0700 (PDT) From: johnwallace4@yahoo.co.uk Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: On Aug 23, 11:40 pm, Johnny Billquist wrote: > Bob Koehler skrev: > > > In article <6h5c4rFjdi7...@mid.individual.net>, billg...@cs.uofs.edu (Bill Gunshannon) writes: > >>> For VMS, only IA-64 enforces no-execution of stack space. > > >> I have always been amazed that more kernels don't implement this. Another > >> is allowing execution from the Unix /tmp (or any directory that is world > >> writable). > > > No kernel can implement this without underlying hardware support. > > IA-64 is the only hardware that I know provides it, although I hope > > there are others. > > Heck, a PDP-11 provides support for that. > Stack is in D-space. Code is in I-space... If you try to jump to the stack, you > will be executing something, but it won't be from the stack, unless you decide > to map I-space and D-space to the same memory. > > Johnny > > -- > Johnny Billquist || "I'm on a bus > || on a psychedelic trip > email: b...@softjar.se || Reading murder books > pdp is alive! || tryin' to stay hip" - B. Idol Yep, I remember that on PDP11/7x (definitely on our 11/70, and from memory probably on the processor-on-a-chip J11-based 11/73 and 11/74), subject to having an OS that understood (ours back then was IAS, which understood). AMD reinvented the data vs instructions distinction in their AMD64 architecture, with the "NX bit", back in 2004/2005 (?) [1], although the way it was done works both in 32bit and 64bit setups. Modern Linuxes and even recent Windozes (XP SP2 and later?) can make use of it. Obviously once AMD had done it, Intel's own industry standard 64bit chips (later Xeons and follow ons) had to do it too to keep up. Windows calls it "Data Execution Prevention", which is one of their more meaningful names. VMS on Alpha may not have had a "noexecute" bit in the PTE as such but there is a "fault on execute" bit, which might or might not be able to provide some kind of data execution protection, depending on what else folk decided to put around it. You can find some relevant text in the Memory Management part of the I+DS manual (on Google Books if you don't have one of your own [2]). Indeed, I have seen a normally reliable source write [3] "Alpha also has a Fault-On-Execute bit, designed to prevent an errant program from jumping off into the weeds and trying to execute data as instructions. On Alpha/VMS, the user stack is mapped with PTEs that have the Fault-On-Execute bit set, so any attempt to branch into data area on the stack results in an access violation, and the process dies. So Alpha VMS is immune to common stack-smashing buffer-overflow attacks." Note careful wording: "immune to common" rather than "completely immune from" :) Also note carefully, the author of the text is Keith Parris, not the person who posted it to comp.os.vms. Direct link to original 2002 article most welcome, I can't seem to find one right now. I'm not quite sure how that relates to the current discussion, as I have lost track of some of the important details and I'm too lazy to fight my way through 300+ posts (including a handful of mine:)) just to refresh my memory. Regards John [1] http://developer.amd.com/documentation/articles/pages/3312005143.aspx [2] http://books.google.co.uk/books?id=mTi7Whl0P98C [3] http://groups.google.co.uk/group/comp.os.vms/browse_thread/thread/ffa432e506fc0282/5836957945c277d0 ------------------------------ Date: Sun, 24 Aug 2008 05:40:10 -0700 (PDT) From: bugs@signedness.org Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <82966fce-fc10-40cd-9afa-ff011ae76f84@m3g2000hsc.googlegroups.com> On Aug 24, 11:51=A0am, johnwalla...@yahoo.co.uk wrote: > On Aug 23, 11:40 pm, Johnny Billquist wrote: > > > > > > > Bob Koehler skrev: > > > > In article <6h5c4rFjdi7...@mid.individual.net>, billg...@cs.uofs.edu = (Bill Gunshannon) writes: > > >>> =A0 =A0For VMS, only IA-64 enforces no-execution of stack space. > > > >> I have always been amazed that more kernels don't implement this. = =A0Another > > >> is allowing execution from the Unix /tmp (or any directory that is w= orld > > >> writable). > > > > =A0 =A0No kernel can implement this without underlying hardware suppo= rt. > > > =A0 =A0IA-64 is the only hardware that I know provides it, although I= hope > > > =A0 =A0there are others. > > > Heck, a PDP-11 provides support for that. > > Stack is in D-space. Code is in I-space... If you try to jump to the st= ack, you > > will be executing something, but it won't be from the stack, unless you= decide > > to map I-space and D-space to the same memory. > > > =A0 =A0 =A0 =A0 Johnny > > > -- > > Johnny Billquist =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|| "I'm on a bus > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= || =A0on a psychedelic trip > > email: b...@softjar.se =A0 =A0 =A0 =A0 =A0 =A0 || =A0Reading murder boo= ks > > pdp is alive! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 || =A0tryin' to s= tay hip" - B. Idol > > Yep, I remember that on PDP11/7x (definitely on our 11/70, and from > memory probably on the processor-on-a-chip J11-based 11/73 and 11/74), > subject to having an OS that understood (ours back then was IAS, which > understood). > > AMD reinvented the data vs instructions distinction in their AMD64 > architecture, with the "NX bit", back in 2004/2005 (?) [1], although > the way it was done works both in 32bit and 64bit setups. Modern > Linuxes and even recent Windozes (XP SP2 and later?) can make use of > it. Obviously once AMD had done it, Intel's own industry standard > 64bit chips (later Xeons and follow ons) had to do it too to keep up. > Windows calls it "Data Execution Prevention", which is one of their > more meaningful names. > As far as I understand the NX bit does not actually make a distinction between data and instructions but it gives you hardware support to mark pages readable but not executable. The pdp11 stuff I'm far too young to comment on... but making the distinction between data and instructions dates back even to the first computers, see http://en.wikipedia.org/wiki/Harvard_architecture Good luck overwriting the program tape with a "memory overflow" :) > VMS on Alpha may not have had a "noexecute" bit in the PTE as such but > there is a "fault on execute" bit, which might or might not be able to > provide some kind of data execution protection, depending on what else > folk decided to put around it. You can find some relevant text in the > Memory Management part of the I+DS manual (on Google Books if you > don't have one of your own [2]). > > Indeed, I have seen a normally reliable source write [3] "Alpha also > has a Fault-On-Execute bit, designed to prevent an errant program from > jumping off into the weeds and trying to execute data as > instructions. =A0On Alpha/VMS, the user stack is mapped with PTEs that > have the Fault-On-Execute bit set, so any attempt to branch into data > area on the stack results in an access violation, and the process > dies. So Alpha VMS is immune to common stack-smashing buffer-overflow > attacks." > > Note careful wording: "immune to common" rather than "completely > immune from" :) Not immune at all, keep in mind that what you are overwriting to gain control over the execution flow is actually "data". Just because this particular data is stored on the stack does not mean you have to return to execute your code on the stack.. You can just as easily return to heap memory, the .text segment of the program (or whatever you call it in VMS land) or return into a library function to execute code (and VMS does not randomize its address space making it trivial). > > Also note carefully, the author of the text is Keith Parris, not the > person who posted it to comp.os.vms. Direct link to original 2002 > article most welcome, I can't seem to find one right now. > > I'm not quite sure how that relates to the current discussion, as I > have lost track of some of the important details and I'm too lazy to > fight my way through 300+ posts (including a handful of mine:)) just > to refresh my memory. > > Regards > John > > [1]http://developer.amd.com/documentation/articles/pages/3312005143.aspx > [2]http://books.google.co.uk/books?id=3DmTi7Whl0P98C > [3]http://groups.google.co.uk/group/comp.os.vms/browse_thread/thread/ffa.= ..- Hide quoted text - > > - Show quoted text - ------------------------------ End of INFO-VAX 2008.463 ************************