Background
In practicing pentesting a VM on Vulnhub I encountered an issue that is quite interesting with Brainpan. After initial access with a limited shell generated from a BoF exploit on a service running on port 9999, I did some basic enumeration and found the following :
sudo -l
revealed that the current shell user (puck) can run a programanansi_util
owned by another user (anansi) as root, a simplels -l <program>
found that I only have executable and read perm on that file, and not write perm.find / -perm -4000 -type f
revealed another programvalidate
within the/usr/local/bin
directory owned by the other user (anansi), and this program has the SUID bit set. (which should mean the program's forked child processes should inherit the parent program's uid as euid) puck also has read and executable perm on validate.
So I decided to explore finding #2 and try to exploit the SUID set program with another BoF. The shellcode I generated was from msfvenom and it was a linux/x86/exec
payload and option CMD=bash
. I was able to exec another bash
prompt after successfully exploiting the BoF issue the program had.
Issue
The bash
program forked from validate
did not give itself the euid of anansi, who owns the program/file validate
inside the usr/bin/local
directory , and the process still belonged to puck with no euid when I execute id
Question
Is this expected behavior? I always thought that if we fork a process from a parent process who's SUID bit is set, that the child process will inherit the parent process's uid as euid, isn't that what sudo
does?