[Phoenix-pm] perl eval and the No Execute chips

[Scott Walters]

Brock,

Each page (usually 4k or 8k) of virtual memory (which is partially
contained in real memory) has permission bits on it.  Check out 
my Sys::Mmap for a concrete example -- processes can decide how
the bits are set when they allocate memory.  Memory can be read only,
read/write, and then there's the question of executable.  So it
isn't an all or nothing thing -- the chip supports marking pages
non-executable, that's all.  If you have a memory buffer that contains
some data that a user sent you over the network that you're trying to
process as data, and the data is broken in sneaky ways that causes 
your program to try to branch execution into the middle of it, where
malicious code instead of just malicious data lies, it's to your
advantage to be able to tell the computer to never, under any 
circumstances, execute program code (machine code -- compiled
code, binary, whatever) from that buffer.  So an attempt to return into
it, or branch into it, or otherwise transfer control of execution into
that buffer would fail and be handed to the operating system to deal with.

When ld.so tries to load a shared object, it merely doesn't request the pages 
allocated to hold that shared object be no-execute.  Stack is a bit 
harder.  The stack used to contain "springboards" for signal handles
and other small pieces of code to be executed.  That had to be redesigned and
reimplemented a bit in order to mark the memory allocated for a processes stack
non-executable.  But most buffer overflows are done on data that's on the stack,
because the stack is just brimming with fixed sized buffers, data tends to
be allocated there, it's all in a known and predictable order, etc, etc.

Here's the thing though... Perl isn't compiled to machine code.  Not even if
you use perlcc, which has just been removed from the 5.9.x branch 
(dammit!).  Perl code is just data that tells another program (the perl
interpreter) what to do.  It's unreasonable to consider the possibility
that a chip vender might make a chip that tries to prevent language
interpreters from interpreting data in buffers unless some flag is set on the
memory.  High level languages generally take care of that themselves.  
In the case of Perl, you've got Safe.pm, use ops (my personal favorite --
perldoc ops, and see http://perldesignpatterns.com/?ActiveWikiPages ),
taint, and lots of other great stuff that's far more powerful and high
level.  

-scott

On  0, Brock <awwaiid at thelackthereof.org> wrote:
> Great question! Perl, as it is now, wouldn't be effected at all as far
> as I know. Though it makes me wonder about loaded modules...
> 
> So here's the trick. If this is a general purpose processor that could
> run an OS such as linux, then you have to allow dynamically linked
> libraries. If you allow dynamically linked libraries, then you can
> effectively change the program at run-time (if nothing else you can
> re-compile a changed version of the program, dynamically load it, and
> then transfer control).
> 
> But that's a bit of a side track. Really, let's expand the question to
> this -- How does "eval" work?
> 
> I think I smell a meeting topic...
> 
> --Brock
> 
> On 2006.09.12.21.44, Jerry Davis wrote:
> | I was reading an article through /. about Security, and I quote a
> | little from the article:
> | 
> | "Aitel cited the NX (No eXecute) technology being built into chips from
> | Intel and Advanced Micro Devices that will effectively prevent code
> | execution within data pages such as default heaps, stacks and memory
> | pools."
> | 
> | What if any effect will this new technology have on scripted languages
> | like perl?
> | 
> | Just wondering here.
> | 
> | Jerry
> | 
> | -- 
> | Happy Trails!
> |  
> | Hobbit Name: Pimpernel Loamsdown
> | Registered Linux User: 275424
> |  
> | Jeep Motto #2: Paved Roads Are a Fine Example of Needless Government
> | Spending!
> | _______________________________________________
> | Phoenix-pm mailing list
> | Phoenix-pm at pm.org
> | http://mail.pm.org/mailman/listinfo/phoenix-pm
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm