📜 ⬆️ ⬇️

Spring Boot - a problem with the security of executable jar files launched as an init.d service

In spring boot there was an interesting opportunity to build an “executable” jar file, which can also be an init.d service. That is, it will be sufficient to register the symbolic link from /etc/init.d/myapp to the jar-file and configure the service auto-launch via update-rc.d. Technically, the jar file becomes a bash script at the end of which binary data is located.

Description of this possibility: docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html

Studying the script file, I discovered some security issues.

The script, run through init.d, runs with root rights. If the owner of the jar file is a user, then the launch of java is already happening from the user.
')
# Determine the user to run as if we are root # shellcheck disable=SC2012 [[ $(id -u) == "0" ]] && run_user=$(ls -ld "$jarfile" | awk '{print $3}') 

But since The owner of the jar file is the same user, he can overwrite the jar file itself, which is also a shell script. And when the operating system starts, this script will run as root. This can be critical, because if there is a vulnerability in a java application, in the worst case the hacker should remain with the application rights, and here there is a possibility of elevating privileges.

I wrote to the bugtracker , but the developer suggests simply making the file unmodifiable via “chattr + i” and describe it in the documentation.

How serious do you think this vulnerability is? What should be done, how to do the right thing?
It seems to me that the init.d script should be kept separate from the jar and in another directory accessible only by root.

Script on github .

Moreover, the launch script loads the .conf file in the same directory as jar via “source”, interpreting it via bash:

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

That is, there you can write a full-fledged script code, which will also be executed with root rights when starting the service via init.d.
It turns out that in order to provide protection, it will be necessary to create a conf-file, even if it is not required, and to prohibit its modification through “chattr + i”.

Source: https://habr.com/ru/post/275203/


All Articles