bash 1.x - command substitution bug

From: Michal Zalewski (lcamtufat_private)
Date: Sun Dec 12 1999 - 12:10:36 PST

  • Next message: Jon Mitchell: "HP Secure Web Console"

    Rather dangerous bug is present in output processing after "command
    substitution" in bash 1.xx. It seems to be NOT present in bash 2.0.x, but
    I haven't found any bugreport on this vulnerability. I looked for:
    'command substitution', 'ff', 'subshell' and '$(' CHANGES file, no
    effects... Seems to be one of these 'silently fixed' bugs - IMHO the most
    dangerous group ;) 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 
    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˙TEST2˙
    [root@nimue:1 /testing]# ./test.sh
    [TEST1] [TEST2] [something]
    
    ...while the proper output should be:
    
    [TEST1˙TEST2˙] [root] [something]
    
    Nothing more to say... 0xff character has deadly meaning :P
    
    Btw. has any of Midnight Commander developers an idea WHY mc is
    still vulnerable on #lslR attack I've posted days ago? Seek BUGTRAQ
    archives, people? Again, this problem does not affect Slackware, but
    seems to be present in .tar.gz official releases?
    
    _______________________________________________________________________
    Michal Zalewski [lcamtufat_private] [link / marchew] [dione.ids.pl SYSADM]
    [Marchew Industries] ! [http://lcamtuf.na.export.pl] bash$ :(){ :|:&};:
    [voice phone: +48 22 813 25 86] <=-=> [cellular phone: +48 501 4000 69]
    Iterowac jest rzecza ludzka, wykonywac rekursywnie - boska [P. Deutsch]
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:09:34 PDT