in reply to Re: Extending a perl program with Scheme, Lua, or JS
in thread Extending a perl program with Scheme, Lua, or JS

Another possible option that comes to my mind is to shell out to the bc Unix or Linux utility. bc can be used in non-interactive mode in various ways, including piping (echo "42/7" | bc), shell redirections, and Un*x heredocs.

How to make things even worse. I smell shell injection: "Dear script, please evaluate 1 + $(rm -rf /) or 1 + ";rm -rf /;echo " for me." (echo "1 + $(rm -rf /)" | bc resp. echo "1 + ";rm -rf /;echo "" | bc) Shelling out ain't that easy if you want to do it right: The problem of "the" default shell

And even if you shell out safely, the program you feed the input into may have security issues. See Morris_worm for a really old example, or CVE-2012-1165 for a younger one.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Replies are listed 'Best First'.
Re^3: Extending a perl program with Scheme, Lua, or JS
by Laurent_R (Canon) on Feb 08, 2019 at 08:35 UTC
    Yes, you're absolutely right, the type of security problems I mentioned about eval also apply to shelling out, I should have mentioned that explicitly. I actually don't like much the idea of shelling out, my point in that paragraph was only to say that if one decided to shell out, it might be simpler to use bc rather than heavy artillery such as an interpreter, compiler, or VM for Lisp, Lua, or JS.
Re^3: Extending a perl program with Scheme, Lua, or JS
by bcrowell2 (Friar) on Feb 09, 2019 at 20:17 UTC
    Thanks for the warning, but as mentioned in the OP, it's not a web app.

      That's OK. Injection attacks are equally plausible against non-web apps too. Indeed the very example to which Brother afoken drew your attention did not attack web apps, predating the web as it did. If you are writing scripts of any sort and not using taint mode you will reap what you sow.

        That's OK. Injection attacks are equally plausible against non-web apps too. Indeed the very example to which Brother afoken drew your attention did not attack web apps, predating the web as it did. If you are writing scripts of any sort and not using taint mode you will reap what you sow.

        I guess you're referring to the Morris worm? Hm...if I try to imagine an exploit using this functionality in my GUI app, I don't really think it would have much to do with shelling out or code injection. The purpose of this extension mechanism is to let the user execute their own arbitrary code. So I guess I could do a kind of Trojan horse attack, where I would put malicious code in the file containing my students' grades, then send the file to other people and try to get them to open the file. This seems a little implausible both because my user base is extremely small and because normally people aren't showing other people their students' grades, unless it's something like a TA showing them to the main instructor for a course.

        But in principle you're right, and that's probably an argument for using either a small, non-Turing complete language or a language that can be sandboxed. It looks like I'm going to use Guile, and Guile does have a sandboxing method in versions 2.2.1+.

      Forget attacks protect against stjpix typos that cost you data