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

Scott Walters scott at
Thu Sep 14 09:18:24 PDT 2006


On  0, Paul Balyoz <paulio10 at gmail.com> wrote:
>    Think about how Perl "runs" any Perl code:
>    1. it compiles the source code, producing a binary version really
>    really quickly

"Binary" implies "machine code", which would be incorrect in this case.
perl compiles Perl to "bytecode", which as far as the computer is concerned,
is just data.  And it is just data, really.  It's meaningless to the
computer itself, but perl understands it.  It's shorthand -- it's still
Perl source code (and can be turned back to sourcecode, minus formatting
and comments).  No-Execute protection on a page keeps the processor from
executing binary machine code in that page; it doesn't keep it from running
other programs (such as perl) that read data in that page and then do things
depending on the data read.  "Compiled" Perl is data, not x86 machine code.

>         (this implies the executable code is placed somewhere else in
>    memory -

"Executable" also has a specific meaning -- "executable by the host
processor".  Perl is not compiled to an executable. 

>         an executable block, for sure -
>         it surely wouldn't be compiled back into the same memory spot
>    where the source code lives!)

What the HELL are you talking about?  

>    2. execute the binary version that was just compiled.

No, interpret, not execute.  

>    So I don't think you have anything to worry about.

You fool!  Don't pass off a weak mistranslation of actual events as a
proof of security.  The more you understand CompSci, the more you
realize security is as fleeting as a cloud formation or a ripple in
a pond -- or a fashion movement.  At no point in history have computers
been actually effectively secured in a way that they remained secure
as technology progressed, yet people insist on talking about things
in terms of "secure" and "not secure".  That's not even adequate for
a manager's understanding.  Intruders do their work by, above all else,
discovering the exact details of how each operation works.  How is
Perl compiled?  What's the bytecode look like?  What's the interpreter
look like?  Following this path, vulnerabilities in perl itself that
lead to remote comprimise can be found -- just as they were recently
found in Flash (which has a similar arrangement) and quite frequently
are found in PHP (ditto).  The worst security strategy is to look at
something, decide (arbitrary) that its "secure", and then not take other
reasonable precautions.  The fact of the matter is that Perl *programs*
are often written horribly insecure because people don't take time to
understand the nature of the various kind sof exploits that Perl 
programs often suffer from and so go on writing them.  They tell 
themselves things like "Linux is secure, Perl is secure, therefore
my site must be secure".  Bruce Schnider famously compared sticking
out one piece of security out there in hopes of protection to "sticking
a stake in the ground hoping the bad guys run into it".  No!  It takes
one bug, one buffer off by one, one timing attack, one lapse in
validation, one of any thousands of sorts of exploits, and your whole
castle crumbles.  The bad guys go around -- and they're extremely
good at doing so.  

>    Besides, if Perl does fail on any future hardware/OS change, you can
>    bet that the Perl development team would release a patch for that
>    pretty darn quickly.  We're talkin' Open Source, here, after all.  :)

This is meaningless... your logic is entirely a mystery here.

Sorry to be so gruff about this -- this is mostly for the benefit of
anyone who might have read your post and been lead astray.  While Perl
is more helpful about security than PHP (offers tools for the programmer
to avoid common problems) and itself has a better security track record,
Perl programmers, all in all, are among the *least* well educated and
as a result, historically, companies trying to use Perl have suffered
horribly at the hands of attackers.  The Perl camp as a whole has a 
wretched security track record.  So if I'm arguing aggressively, it's
because the severity of the problem.  


>    -- paul
>    On 9/13/06, Jerry Davis <[1]jdawgaz at cox.net> wrote:
>      On Wed, 13 Sep 2006 17:37:06 +0000
>      Scott Walters <scott@> wrote:
>      > Stops executing, starts parsing/compiling again, and then
>      executes the
>      > result of that again.  I've said it before and I'll say it
>      again...
>      > 95% of the time people eval, they really want a closure instead.
>      the reason I asked, is that I do make use of eval, and in what I
>      think
>      is a legal way.
>      what I normally do in an eval, is on the command line I pass the
>      name
>      of a file which is really a short perl script which is really a
>      hash
>      full of static data.
>      sort of like:
>      our %h;
>      $h{somekey}{somesubkey} = value;
>      ...
>      I then eval this file, which sets sets up my all my data, and I
>      just
>      use that data in the program.
>      Different files hold exactly the same hash but with different
>      values.
>      This has worked really really well for me, and I was just a little
>      alarmed over what I saw on /.
>      Jerry
>     Paul BalyozFastech Learning Center[2]http://www.FastechLC.com/
> References
>    1. mailto:jdawgaz at cox.net
>    2. http://www.FastechLC.com/

> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm

More information about the Phoenix-pm mailing list