开发者

Preventing harmful gzip files from being extracted

开发者 https://www.devze.com 2023-02-10 19:23 出处:网络
The directory of which users have their backups for their files is located in a directory which they can access and upload to.

The directory of which users have their backups for their files is located in a directory which they can access and upload to.

If they get the naming scheme right and cause an error on purpose that makes the system try to restore the last 5 or so backups, they could potentially put files they want onto the server by using a absolute path gzip file such as ../../../../../etc/passwd or whatever may be the case.

What checks can I perform to prevent this from happening programmatically in BASH

The following command is what is ran by root (it gets ran by root because I use webmin):

tar zxf /home/$USER/site/backups/$BACKUP_FILE -C /home/$USER/site/data/

Where $BACKUP_FILE wi开发者_如何学Cll be the name of the backup it's attempting to restore


edit 1:

This is what I came up with so far. I am sure this way could be improved a lot:

CONTENTS=$(tar -ztvf /home/$USER/site/backups/$BACKUP_FILE | cut -c49-200)
for FILE in $CONTENTS; do
    if [[ $FILE =~ \.\. ]] || [[ $FILE =~ ^\/ ]]; then
        echo "Illegal characters in contents"
        exit 1
    fi
done

tar zxf /home/$USER/site/backups/$BACKUP_FILE -C /home/$USER/site/data/
exit 0

I am wondering if disallowing it to begin with / and not allow the .. will be enough? also is character 50+ normal for the output of tar -ztvf ?


Usually tar implementations strip a leading / and don't extract files with .., so all you need to do is check your tar manpage and don't use the -P switch.

Another thing tar should protect you from is symlink attacks: a user creates the file $HOME/foo/passwd, gets it backed up, removes it and instead symlinks $HOME/foo to /etc, then restores the backup. Signing the archive would not help with this, although running with user privileges would.


Try restoring every backup as the backup owner using su:

su $username -c tar xzvf ...

(You might also need the -l option in some cases.)

Make sure that you really understand the requirements of the program to run as root. The process you are running has no need for any other privilege than read access to one directory and write access to another one so even the user account privilege is an overkill not to even mention root. This is just asking for trouble.


I'm assuming the backups are generated by your scripts, and not the user. (Extracting arbitrary user created tar files are never ever a good idea).

If your backups have to be store in a directory writeable by users, I would suggest you digitally sign each backup file so that it's integity can be validated. You can then verify that a tar file is legit before using it for restoration.

An example using GPG:

gpg --armor --detach-sign backup_username_110217.tar.gz

That creates a signature file backup_username_110217.tar.gz.asc which can be used to verify the file using:

gpg --verify backup_username_110217.tar.gz.asc backup_username_110217.tar.gz

Note that to run that in a script, you'll need to create your keys without a passphrase. Otherwise, you'll have to store the password in your scripts as plain text which is a horrid idea.

0

精彩评论

暂无评论...
验证码 换一张
取 消