5 ms·
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 malicio
by ptx 3y ago
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 https://news.ycombinator.com/item?id=39154825
- bonzini 3y agoUnfortunately 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).
- jwilk 3y agoeval 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
- lyu07282 3y 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.