develooper Front page | perl.perl5.porters | Postings from June 2017

More strongly discourage Safe.pm?

Thread Next
From:
Dave Mitchell
Date:
June 24, 2017 14:14
Subject:
More strongly discourage Safe.pm?
Message ID:
20170624141420.GI3074@iabyn.com
In the pod for Safe.pm, we have a general

    =head1 WARNING

About no warranty, and towards the end of the pod, we have the section

    =head1 RISKS

where we mention some of the things that could go wrong, e.g. consuming
all memory or CPU.

But one think that isn't strongly emphasised is the ability to exploit
bugs in the perl parser, of which there are traditionally many
(Perl_yylex() is over 4000 lines of hand-crafted tokeniser).

Usually we don't regard bugs in the perl core as security bugs when it
requires the attacker to be able to pass arbitrary code to the perl
interpreter, since in that case they could just as easily pass
'system("rm -rf /")' rather than exploit a bug.

However, Safe.pm breaks that assumption. If a program passes arbitrary
attacker-supplied text to Safe::reval(), then any compile-time interpreter
bugs become potentially exploitable, regardless of the opcode mask.

So, should the pod for Safe.pm be updated so that at the very beginning it
states that the module is now discouraged, and that passing arbitrary
user-supplied code to reval() must never be done?

Are there still any valid use cases for Safe?


-- 
Diplomacy is telling someone to go to hell in such a way that they'll
look forward to the trip

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About