Exploiting wildcards on Linux

[Snowhog]

http://www.net-security.org/article.php?id=2061

Is this a real concern for most Linux users or not?

[Feathers McGraw]

Am I right in thinking that this is only likely to be a problem on shared servers, as you wouldn't be likely to create those files yourself by accident?

[MoonRise]

Agreed Feathers McGraw!

[GreyGeek]

From my POV, if you are the only user of your machine this "security risk" is no risk at all. You are not likely to create files with the names of shell command parameters.

Tar has the following privileges:
-rwxr-xr-x 1 root root 353840 Feb 4 07:16 /bin/tar
It shows that world has execute privileges only, and doesn't need sudo unless paths are outside the home account.

If the machine in question is a server then the * wild card will be a problem if one or more people who have access to an account on that server creates those malicious file and the shell.sh file. In the example given below, from the article, "leon" created the malicious files and the shell.sh file. His account name will be on the malicious files in the archive.tar file, revealing him as the culprit. Leon being able to hijack the tar command to execute a shell script as root is the least of his employer's problems.

Running [B]tar cf archive.tar *[/B] on a folder with these files seems pretty straightforward and benign.
 
[root@defensecode public]# ls -al
drwxrwxrwx.  2 user user  4096 Oct 28 19:34 .
drwx------. 24 user user  4096 Oct 28 18:32 ..
-rw-rw-r--.  1 user user 20480 Oct 28 19:13 admin.php
-rw-rw-r--.  1 user user    34 Oct 28 17:47 ado.php
-rw-rw-r--.  1 user user   187 Oct 28 17:44 db.php
-rw-rw-r--.  1 user user   201 Oct 28 17:43 download.php
 
The problem arises if the user created a couple of fake files and a shell script that contains any arbitrary command.
 
[root@defensecode public]# ls -al
drwxrwxrwx.  2 user user  4096 Oct 28 19:34 .
drwx------. 24 user user  4096 Oct 28 18:32 ..
-rw-rw-r--.  1 user user 20480 Oct 28 19:13 admin.php
-rw-rw-r--.  1 user user    34 Oct 28 17:47 ado.php
-rw-r--r--.  1 leon leon     0 Oct 28 19:19 [B]--checkpoint=1[/B]
-rw-r--r--.  1 leon leon     0 Oct 28 19:17 [B]--checkpoint-action=exec=sh shell.sh[/B]
-rw-rw-r--.  1 user user   187 Oct 28 17:44 db.php
-rw-rw-r--.  1 user user   201 Oct 28 17:43 download.php
-rwxr-xr-x.  1 leon leon 12 Oct 28 19:17 [B]shell.sh[/B]
 
By using the * wildcard in the tar command, these files will be  understood as passed options to the tar binary and shell.sh will be  executed as root.

[kubicle]

His account name will be on the malicious files in the archive.tar file, revealing him as the culprit.

Sure, in this case, but there is no guarantees of that. The shell.sh could potentially do anything...including removing all traces of itself left on the machine (and in the archive.tar)

But surely all good admins know to avoid (and how to avoid) bare wildcards in their commands (or any automated backup scripts they might use)...for a multitude of reasons and not just this one.

[Feathers McGraw]

If you were hosting a shared server with shell access, how would you prevent this attack?

Would you have to build tar yourself and remove those options (has anyone used them?), or is there another way of doing things?

Kubicle, this sounds like I may be about to learn something ... can you see anything wrong with the way I have used wildcards in this script?

#! /bin/bash
# Backup script for www.samhobbs.co.uk
 
# USE FULL PATH
BACKUP_DIR="/media/backup/website/"
DRUPAL_DIR="/var/www/samhobbs/"
ENCRYPTION_KEYWORDFILE="/home/sam/.mcryptpasswordfile"
 
# External email address to send monthly encrypted backup files to
EXTERNAL_EMAIL="you@yourexternalemail.com"
 
# redirect errors and output to log file
exec 2>&1 1>>"${BACKUP_DIR}backup-log.txt"
 
NOW=$(date +"%Y-%m-%d")
 
 
# Headers for log
echo ""
echo "#==================================================== $NOW ====================================================#"
echo ""
 
# Back up Drupal with Drush
drush archive-dump default -r $DRUPAL_DIR --tar-options="-z" --destination=$BACKUP_DIR$NOW.tar.gz
 
# clean up old backup files
# we want to keep:
#               one week of daily backups
#               one month of weekly backups (1st, 8th, 15th and 22nd)
#               monthly backups for one year
#               yearly backups thereafter
 
# seconds since epoch (used for calculating file age)
SSE=$(date +%s)
 
[B]FILES_LIST=( "$BACKUP_DIR"* )[/B]
 
for file in "${FILES_LIST[@]}"; do
  if [[ $file = *20[0-9][0-9]-[0-9][0-9]-[0-9][0-9].tar.gz ]]; then
    FILENAME=$(basename "$file")
    FILENAME_NO_EXTENSION=${FILENAME%%.*}
    FILE_YEAR=$(echo $FILENAME_NO_EXTENSION | cut -d'-' -f 1)
    FILE_MONTH=$(echo $FILENAME_NO_EXTENSION | cut -d'-' -f 2)
    FILE_DAY=$(echo $FILENAME_NO_EXTENSION | cut -d'-' -f 3)
    SSE_FILE=$(date -d "$FILE_YEAR$FILE_MONTH$FILE_DAY" +%s)
    AGE=$((($SSE - $SSE_FILE)/(24*60*60))) # age in days
     
    # if file is from the first day of a year (yearly backup), skip it
    if [[ $file = *20[0-9][0-9]-01-01.tar.gz ]]; then
      echo "file $file is a yearly backup: keeping"
 
    # if file is from the first day of a month (monthly backup) and age is less than 365 days, skip it
    elif [[ $file = *20[0-9][0-9]-[0-9][0-9]-01.tar.gz ]] && [ $AGE -lt 365 ]; then
      echo "file $file is a monthly backup, age < 1yr: keeping"
 
    # if day of month is 08, 15 or 22 (weekly backup) and age is less than 30 days, skip it
    elif [ $FILE_DAY -eq 08 -o $FILE_DAY -eq 15 -o $FILE_DAY -eq 22 ] && [ $AGE -lt 30 ]; then
      echo "file $file is a weekly backup, age < 30 days: keeping"
 
    # if age is less than seven days, skip it
    elif [ $AGE -lt 7 ]; then
      echo "file $file is a daily backup, age < 7 days: keeping"
     
    # if it hasn't matched one of the above, it should be deleted
    else
      echo "removing file $file"
      rm $file
    fi
  else
    echo "file $file does not match the expected pattern: skipping"
  fi
done
 
DAY=$(date +%d)
 
if [[ $DAY = 01 ]]; then
  echo "encrypting a copy of today's backup to send by email"
  # encrypt today's backup file using mcrypt
  mcrypt -F -f $ENCRYPTION_KEYWORDFILE $BACKUP_DIR$NOW.tar.gz
   
  # if the encryption is successful, email the file to an external email address
  if [[ -f $BACKUP_DIR$NOW.tar.gz.nc ]]; then
    echo "Monthly backup created $NOW, encrypted using mcrypt" | mutt -s "Monthly backup" -a $BACKUP_DIR$NOW.tar.gz.nc -- $EXTERNAL_EMAIL
    echo "Email sent, removing encrypted file"
    rm $BACKUP_DIR$NOW.tar.gz.nc
    echo "Done"
  else
    echo "Something went wrong with mcrypt: the encrypted file was not found"
    exit 1
  fi
fi

Feathers

[kubicle]

Would you have to build tar yourself and remove those options (has anyone used them?)

That would be both overkill (the options themselves are not the problem, and many of them are actually quite useful features) and a lot of work (you probably don't wish to hair-comb every command you could use for potentially exploitable options).

There are many ways you can avoid filenames interpreted as options, one is using the '--' (end of options) in your commands, for example 'tar cf archive.tar -- *'.
But generally you'll want to stay away from bare wildcards (just '*'), in this example you could use 'tar cf archive.tar ./*'

Depending on the globbing options you have set for your shell, wildcard matching can also lead to unexpected results (dot-globbing or no-match, are just a few examples), but this is a bit too extensive topic to handle in a short post...you'll likely find good tutorials/guides for your shell (bash, zsh etc.) online.

Kubicle, this sounds like I may be about to learn something ... can you see anything wrong with the way I have used wildcards in this script?

I see no bare wildcards there, on quick glance.

[Feathers McGraw]

It's here:

FILES_LIST=( "$BACKUP_DIR"* )

unless that's not what a bare wildcard is?

[kubicle]

It's here:

FILES_LIST=( "$BACKUP_DIR"* )

unless that's not what a bare wildcard is?

Yeah, that's not a bare wildcard as it includes the path element ( it's not '*', it's '/media/backup/website/*' )

[Feathers McGraw]

Thanks!

[GreyGeek]

Yeah, that's not a bare wildcard as it includes the path element ( it's not '*', it's '/media/backup/website/*' )

And, your reg expression parses for correct file names:

  ...
 # if it hasn't matched one of the above, it should be deleted
    else
      echo "removing file $file"
      rm $file
    fi
...

[SteveRiley]

Nice discussion. When one's philosophy is to treat everything as a file, it can indeed become difficult to understand where to draw the line.

The Reddit post in the linked article had a humorous entry:
./* &
Very clever. Anyone care to venture a guess?

And the DefenseCode advisory was rather illuminating.