Предотвращение извлечения вредоносных файлов gzip

Question

Каталог, в котором пользователи имеют свои резервные копии для своих файлов, находится в каталоге, к которому они могут обращаться и загружать.

Если они получают правильную схему именования и намеренно вызывают ошибку, которая делает системупопытайтесь восстановить последние 5 или около того резервных копий, они могли бы потенциально поместить файлы, которые они хотят, на сервер, используя gzip-файл с абсолютным путем, такой как ../../../../../etc/passwd или любой другой.

Какие проверки я могу выполнитьчтобы это не происходило программно в BASH

Следующая команда - это то, что запускается пользователем root (он запускается пользователем root, потому что я использую webmin):

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

Где $BACKUP_FILE будет именем резервной копии, которую он пытается восстановить

---

edit 1:

Это то, что я придумал до сих пор.Я уверен, что этот способ мог бы быть значительно улучшен:

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

Мне интересно, будет ли достаточно запретить его с / и не разрешить .. будет достаточно?также символ 50+ нормальный для вывода tar -ztvf?

Answer 1

Обычно tar реализации убирают ведущий / и не извлекают файлы с .., поэтому все, что вам нужно сделать, это проверить вашу tar справочную страницу и не использовать-P switch .

Еще одна вещь, которая tar должна защитить вас от атак по символическим ссылкам: пользователь создает файл $HOME/foo/passwd, создает его резервную копию, удаляет его и вместо него символические ссылки $HOME/foo до /etc, затем восстанавливает резервную копию.Подписание архива не поможет с этим, хотя запуск с правами пользователя будет.

Answer 2

Попробуйте восстановить каждую резервную копию как владельца резервной копии, используя su:

su $username -c tar xzvf ...

(в некоторых случаях вам также может понадобиться опция -l.)

Убедитесь, что вы действительно понимаете требования программы для запуска от имени пользователя root. Процесс, который вы запускаете, не нуждается ни в каких других привилегиях, кроме доступа на чтение к одному каталогу и записи на запись в другой, так что даже привилегия учетной записи user является излишним, даже не говоря о root. Это просто напрашивается на неприятности.

Answer 3

Я предполагаю, что резервные копии создаются вашими скриптами, а не пользователем.(Извлечение произвольных созданных пользователем файлов tar никогда не является хорошей идеей.)

Если ваши резервные копии должны храниться в каталоге, доступном для записи пользователями, я бы посоветовал вам поставить цифровую подпись для каждого файла резервной копии, чтобы обеспечить его целостностьподтверждено.Затем вы можете проверить, является ли файл tar действительным, прежде чем использовать его для восстановления.

Пример использования GPG :

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

, который создает файл подписи backup_username_110217.tar.gz.ascкоторый можно использовать для проверки файла с помощью:

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

Обратите внимание, что для запуска этого в скрипте вам нужно создать ключи без ключевой фразы.В противном случае вам придется хранить пароль в ваших сценариях в виде простого текста, что является ужасной идеей.