COMMAND

    bash

SYSTEMS AFFECTED

    bash 1.x

PROBLEM

    Michal Zalewski found following.  Rather dangerous bug is  present
    in output  processing after  "command substitution"  in bash 1.xx.
    As bash 1.14.x is shipped with most of the distributions and seems
    to be widely used - here's an advisory.

    It's nothing than a possible  reason of 'unexplainable' bugs -  as
    long as  we're talking  about unprivledged  scripts/commands.  But
    with scripts at uid 0 (no  matter, launched by root or via  sudo),
    it seems to be deadly harmful  - if only attacker has any  control
    on output  of one  of the  nested commands  - and  usually he has.
    Real-life example:

        HEADER="`head -1 $INPUT_FILE`"

    If  we  can  put  'magic'  content  into  input  file,  we can put
    arbitrary output on EVERY subsequent nested command - for  example
    (yep, another real-life example):

        SAFEFILE=`mktemp /tmp/secure-XXXXXX`

    ..in this case,  we can alternate  rendered SAFEVALUE to  anything
    we  want  -  what  about  making  /etc/passwd  our 'safe temporary
    file'?)

    Believe  or  not,  usually  it's  wonderful  weapon  again  custom
    'anti-hacker' scripts  launched from  crontab, as  it process  OUR
    files, OUR processes  and almost always  subshells are called  for
    some  purposes  (awk/sed/tr  combos=20  are  lovely)... Let's see,
    some ideas  on malicious  attacker-dependent values  used in  root
    scripts:

        - argv[]s (on sudo scripts)
        - /proc entries (against home-made /proc scanners)
        - file names (against home-made fs scanners)
        - file contents
        - hostnames (remote scanners)
        - service banners (remote scanners)
        - and much more...

    Ok, ok, an experiment follows - no comments necessary:

        [root@nimue:1 /testing]# cat test.sh
        #!/bin/sh

        FIRST="`cat $1`"
        SECOND=`whoami`
        THIRD=`echo something`

        echo "[$FIRST] [$SECOND] [$THIRD]"

        [root@nimue:1 /testing]# od -v -t x1 -A n test
         54 45 53 54 31 ff 54 45 53 54 32 ff
        [root@nimue:1 /testing]# cat test
        TEST1=FFTEST2=FF
        [root@nimue:1 /testing]# ./test.sh
        [TEST1] [TEST2] [something]

    ..while the proper output should be:

        [TEST1=FFTEST2=FF] [root] [something]

    Nothing more to say... 0xff character has deadly meaning.

SOLUTION

    It seems to be NOT present in  bash 2.0.x.  Just to make it  clear
    - vulnerability described here seems  to be almost similar to  one
    described in CERT advisory (CA-96.22).  But in fact bug  addressed
    there (bash -c 'command1(0xff)command2') has been fixed years  ago
    in bash 1.14.7 release, while one described by me (0xff in command
    substitution)  -  hasn't  been  fixed  (till  silent  fix in 2.0.x
    releases).

    Ambrose Li  added following.   He found  out that  the problem  is
    caused by a one-line bug, as follows (line numbers are off):

        +++ general.c	Thu May 11 18:23:54 2000
        @@ -1150,7 +1155,7 @@
 	        }
               local_index = 0;
             }
        -  return (localbuf[local_index++]);
        +  return (unsigned char)(localbuf[local_index++]);
         }
        
         int

    Basically, bash is using a char[] to save int values. When the int
    value  is  extracted  back,  we  get the usual signedness problem.
    The experiment no longer works after this single line is patched.