in reply to Re: The importance of avoiding the shell
in thread The importance of avoiding the shell

here code sample that helped me identifying which shell is used by system et al.

> perl -e 'print ` ls -l /proc/\$\$/exe `'
lrwxrwxrwx 1 lanx lanx 0 2014-09-27 12:13 /proc/25970/exe -> /bin/dash

[download]

HTH! :)

Cheers Rolf

(addicted to the Perl Programming Language and ☆☆☆☆ :)

Replies are listed 'Best First'.
Re^3: The importance of avoiding the shell
by ikegami (Patriarch) on Sep 29, 2014 at 06:36 UTC

    The shell used by system is actually given by perl -V:sh. 

    $ perl -V:sh
sh='/bin/sh';

    [download]

    If you want to find out if that's bash, you can use 

    $ ls -l /bin/sh
lrwxrwxrwx 1 root root 9 Apr 10 17:08 /bin/sh -> /bin/bash

    [download]

    Like your code, that only works if and only if /bin/sh is a symlink. A more reliable check is 

    $ /bin/sh --version
GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu)
...

    [download]
[reply]
[d/l]
[select]
      I think in world of multiple forks and vendors the most reliable way is just testing for the exploit itself, like it's done (used to be?) with JS-features in different Browsers.

      The situation is similar, since alternative shells come as a compatible replacement for bash they try to mimic authentication. I.e. version number or env-vars are not that reliable.

      For instance does my dash not even support the --version option 

      lanx@nc10-ubuntu:~$ dash --version
dash: Illegal option --
lanx@nc10-ubuntu:~$ dash -version
dash: Illegal option -r

      [download]

      I already tested for symlink without success, but seems like I had a typo ...

      Cheers Rolf

      (addicted to the Perl Programming Language and ☆☆☆☆ :)

[reply]
[d/l]
[select]

        I think in world of multiple forks and vendors the most reliable way is just testing for the exploit itself,

        Most definitely.

        For instance does my dash not even support the --version option

        Then it's not bash.

[reply]
[d/l]
Re^3: The importance of avoiding the shell
by parv (Parson) on Sep 27, 2014 at 12:04 UTC

    I was trying to create an example for FreeBSD 8-STABLE, and found that one cannot rely on (from system) ...

    ... If there is only one scalar argument, the argument is checked for shell metacharacters, and if there are any, the entire argument is passed to the system's command shell for parsing (this is "/bin/sh -c" on Unix platforms, but varies on other platforms). If there are no shell metacharacters in the argument, it is split into words and passed directly to "execvp", which is more efficient. ...

    ... as I could not find any trace of a shell for system q[date 2>&1] & ktrace via ... 

    ktrace -di perl -e 'print system q[date 2>&1]' \
&& kdump -d | fgrep /bin/sh

    [download]

    ... had to use ... 

    ktrace -di perl -e 'print system q[date 2>&1 </dev/null]'

    [download]

    ... to invoke the shell (/bin/sh). Apparently 2>&1 does not qualify as shell metacharacters (here).

    (An actual example has yet to be produced.) date 2

[reply]
[d/l]
[select]

      Perl has special logic to recognize 2>&1 to make this idea work on Windows. The Windows default shell (cmd.exe) does not understand 2>&1, but (too) many programmers use this idiom.

[reply]
[d/l]
[select]
        The Windows default shell (cmd.exe) does not understand 2>&1

        Say what?

        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

        Thanks much Corion; that helps in my understanding.

[reply]

In Section Meditations