Spring Boot — проблема с безопасностью исполняемых jar файлов запускаемых как init.d сервис

в 15:23, , рубрики: java, security, spring, spring boot, метки:

В spring boot появилась интересная возможность собрать «исполняемый» jar файл, который также может быть init.d сервисом. То есть достаточно будет прописать символьную ссылку из /etc/init.d/myapp на jar-файл и через update-rc.d настроить автозапуск сервиса. Технически jar файл становится bash-скриптом в конце которого находятся бинарные данные.

Описание данной возможности: docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html

Изучая скрипт файл, я обнаружил некоторые проблемы с безопасностью.

Скрипт, запускаемый через init.d, запускается с root правами. Если владелец jar-файла пользователь, то запуск java уже происходит от пользователя.

# Determine the user to run as if we are root
# shellcheck disable=SC2012
[[ $(id -u) == "0" ]] && run_user=$(ls -ld "$jarfile" | awk '{print $3}')

Но т.к. владелец jar-файла тот же пользователь, он может перезаписать сам jar-файл, который одновременно является shell-скриптом. И при старте операционной системы этот скрипт запустится с правами root. Это может быть критично, т.к. если в java-приложении есть уязвимость, в худшем случае взломщик должен остаться с правами приложения, а здесь появляется возможность повышения привилегий.

Я написал в багтрекер, но разработчик предлагает просто делать файл немодифицируемым через «chattr +i» и описать это в документации.

Как вы думаете, насколько эта уязвимость серьезная? Что стоит сделать, как правильно поступать?
Как мне кажется, надо init.d скрипт держать отдельно от jar и в другом каталоге, доступном только root.

Скрипт на github.

А ещё, launch-скрипт загружает .conf файл, лежащий в том же каталоге где и jar, через «source», интерпретируя его через bash:

[[ -r "${jarfolder}/${configfile}" ]] && source "${jarfolder}/${configfile}"

То есть там можно писать полноценный скриптовый код, который также будет исполняться с правами root при запуске сервиса через init.d.
Получается, чтобы обеспечить защиту, надо будет обязательно создавать conf-файл, даже если он не требуется, и запрещать его модификацию через «chattr +i».

Автор: ivnik

Источник

Поделиться новостью

* - обязательные к заполнению поля