undefined | Better HN

0 pointsptx1y ago0 comments

The use of "eval" stands out, or at least it should stand out – but there are two more instances of it in the same script, which presumably are not used maliciously.

A while back there was a discussion[0] of an arbitrary code execution vulnerability in exiftool which was also the result of "eval".

Avoiding casual use of this overpowered footgun might make it easier to spot malicious backdoors. Usually there is a better way to do it in almost all cases where people feel the need to reach for "eval", unless the feature you're implementing really is "take a piece of arbitrary code from the user and execute it".

[0] https://news.ycombinator.com/item?id=39154825

0 comments

bonzini1y ago

Unfortunately eval in a shell script has an effect on the semantics but is not necessary to do some kind of parsing of the contents of a variable, unlike Python or Perl or JavaScript. A

    $goo

line (without quotes) will already do word splitting, though it won't do another layer of variable expansion and unquoting, for which you'll need

    eval "$goo"

(This time with quotes).

jwilk1y ago

eval in autoconf macros is nothing unusual.

In (pre-backdoor) xz 5.4.5:

  $ grep -wl eval m4/*
  m4/gettext.m4
  m4/lib-link.m4
  m4/lib-prefix.m4
  m4/libtool.m4

lyu072821y ago

> Usually there is a better way to do it in almost all cases where people feel the need to reach for "eval"

unfortunately thats just standard in configure scripts, for example from python:

``` grep eval Python-3.12.2/configure | wc -l 165 ```

and its 32,958 lines of code, plenty of binary fixtures as well in the tarball to hide stuff.

who knows, but I have feeling us finding the backdoor in this case was more of a happy accident.

j / k navigate · click thread line to collapse