security vulnerabilities in bash script - Security

This is a discussion on security vulnerabilities in bash script - Security ; Hello everyone, I have this simple bash script that reads from standard input and executes some work depending on the input that it has read. The input lines are meant to be in the form of a command followed by ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: security vulnerabilities in bash script

  1. security vulnerabilities in bash script

    Hello everyone,

    I have this simple bash script that reads from standard input and executes
    some work depending on the input that it has read. The input lines are
    meant to be in the form of a command followed by an argument.

    #!/bin/bash

    read input

    #these two lines divide input in a first word and the rest; are they safe?
    command=`echo ${input%% *}`
    rest=`echo ${input#* }`

    case $command in

    print)
    echo $rest
    ;;

    *)
    echo "wrong command"
    ;;

    esac


    Is is possible for the user to provide something to the standard input and
    make this script do something different from what it was meant?

    I often see that the argument of case statement is enclosed in a pair of
    inverted commas ( case "$command" in ... ); what is the purpose of the
    inverted commas?


    Thanks

  2. Re: security vulnerabilities in bash script

    * Ggds
    | #these two lines divide input in a first word and the rest; are they safe?
    | command=`echo ${input%% *}`
    | rest=`echo ${input#* }`

    Not really 'unsafe', but some versions of echo interpret
    e.g. backslashes in the arguments, so the output might not match the
    input.

    It would probably be safer to use set/shift here:

    set -- $input
    command="$1"
    shift
    rest="$@"

    | I often see that the argument of case statement is enclosed in a
    | pair of inverted commas ( case "$command" in ... ); what is the
    | purpose of the inverted commas?

    The double quote prevent the script from failing if $command is unset
    or the empty string.

    HTH
    R'

  3. Re: security vulnerabilities in bash script

    Ralf Fassel wrote:

    > * Ggds
    > | #these two lines divide input in a first word and the rest; are they
    > | #safe?
    > | command=`echo ${input%% *}`
    > | rest=`echo ${input#* }`
    >
    > Not really 'unsafe', but some versions of echo interpret
    > e.g. backslashes in the arguments, so the output might not match the
    > input.
    >
    > It would probably be safer to use set/shift here:
    >
    > set -- $input
    > command="$1"
    > shift
    > rest="$@"
    >

    This could be a nice modification, but without a clear reason, I don't think
    I'll propose the change. You say that it could probably safer...

    > | I often see that the argument of case statement is enclosed in a
    > | pair of inverted commas ( case "$command" in ... ); what is the
    > | purpose of the inverted commas?
    >
    > The double quote prevent the script from failing if $command is unset
    > or the empty string.
    >


    Ok, thanks. However it prevents the words $command and $rest to be expanded
    by bash, right? Even in that case, I don't see any security risks (because
    the expanded string is used internal by the script - I'm referring to
    $command and $rest). Do you agree?


    > HTH
    > R'



  4. Re: security vulnerabilities in bash script

    * Ggds
    | This could be a nice modification, but without a clear reason, I
    | don't think I'll propose the change. You say that it could probably
    | safer...

    I'm no bash expert, but thinking again: why use echo here at all?
    Why not just
    command=${input%% *}
    ?

    | Ok, thanks. However it prevents the words $command and $rest to be
    | expanded by bash, right?

    Seems so. I wasn't aware that an unquoted $variable is indeed
    filename-expanded by the shell/bash...

    | Even in that case, I don't see any security risks (because the
    | expanded string is used internal by the script - I'm referring to
    | $command and $rest). Do you agree?

    Hard to tell. If you have too many files in the expansion, a * could
    overflow the max commandline length, resulting in an runtime error,
    but other than that? It depends on the context in which this is
    used. Flight control for the Mars-shuttle? Better safe than sorry
    ;-)

    R'

  5. Re: security vulnerabilities in bash script

    Ggds writes:

    >Ralf Fassel wrote:


    >> * Ggds
    >> | #these two lines divide input in a first word and the rest; are they
    >> | #safe?
    >> | command=`echo ${input%% *}`
    >> | rest=`echo ${input#* }`
    >>
    >> Not really 'unsafe', but some versions of echo interpret
    >> e.g. backslashes in the arguments, so the output might not match the
    >> input.
    >>
    >> It would probably be safer to use set/shift here:
    >>
    >> set -- $input
    >> command="$1"
    >> shift
    >> rest="$@"
    >>

    >This could be a nice modification, but without a clear reason, I don't think
    >I'll propose the change. You say that it could probably safer...


    >> | I often see that the argument of case statement is enclosed in a
    >> | pair of inverted commas ( case "$command" in ... ); what is the
    >> | purpose of the inverted commas?
    >>
    >> The double quote prevent the script from failing if $command is unset
    >> or the empty string.
    >>

    >
    >Ok, thanks. However it prevents the words $command and $rest to be expanded
    >by bash, right? Even in that case, I don't see any security risks (because
    >the expanded string is used internal by the script - I'm referring to
    >$command and $rest). Do you agree?


    No. Single quotes prevent expansion, double quotes do not.



  6. Re: security vulnerabilities in bash script

    Ralf Fassel wrote:
    > * Ggds
    > | This could be a nice modification, but without a clear reason, I
    > | don't think I'll propose the change. You say that it could probably
    > | safer...
    >
    > I'm no bash expert, but thinking again: why use echo here at all?
    > Why not just
    > command=${input%% *}
    > ?


    True. But they could also use read to split the words:

    read -r command rest

    I'm aware that this was not the question (and I'm too lazy to think
    about possible security problems, so maybe I should refrain from useless
    nit-picking).

    Regards...
    Michael

  7. Re: security vulnerabilities in bash script

    * michael.mauch@gmx.de (Michael Mauch)
    | True. But they could also use read to split the words:
    | read -r command rest

    Even simpler.

    R'

+ Reply to Thread