1

This was covered in Linux PrivEsc, task 15, in this TryHackMe room.

I am having trouble understanding how this debugging mode is executing the commands in the PS4 variable, and why I must put /usr/local/bin/suid-env2 instead of another path at the end of the command?

Here is a copy of the room's content:

Note: This will not work on Bash versions 4.4 and above.

When in debugging mode, Bash uses the environment variable PS4 to display an extra prompt for debugging statements.

Run the /usr/local/bin/suid-env2 executable with bash debugging enabled and the PS4 variable set to an embedded command which creates an SUID version of /bin/bash:

env -i SHELLOPTS=xtrace PS4='$(cp /bin/bash /tmp/rootbash; chmod +xs /tmp/rootbash)' /usr/local/bin/suid-env2

Run the /tmp/rootbash executable with -p to gain a shell running with root privileges:

/tmp/rootbash -p

questioner
  • 181
  • 2
  • 12

1 Answers1

2

Traces that are enabled by bash -x (or the long form bash -o xtrace) are formatted according to the PS4 variable. The content of PS4 undergoes prompt expansion, and unless the option promptvars is turned off, this includes variable and command substitutions.

$ bash -x -c 'echo world'
+ echo world
world
$ PS4='$(echo hello)' bash -x -c 'echo world'
helloecho world
world

It's possible to use this as part of privilege escalation, but the circumstances where this would be useful are unusual. There has to be a bash script that runs with elevated privileges, with an environment that's under the attacker's control. When that's the case, it's usually game over: there are lots of other environment variables that can allow arbitrary command execution, such as PATH, LD_LIBRARY_PATH, LD_PRELOAD, etc. The recommended way to run a program with additional privileges is via sudo, which takes care of scrubbing the environment except for a whitelist which wouldn't include PS4 unless the administrator deliberately added it.

suid-env2 is something that was created specifically for the exploit to be possible. It's apparently a setuid root program that runs bash wihtout cleaning up the environment, which as I explained above is a well-known security hole that can be exploited in many ways. The bit about /tmp/rootbash is a convoluted and conspicuous way of making the exploit persistent (i.e. of gaining a way to elevate privileges if the original exploit is fixed without completely scrapping the existing instance of the vulnerable system).

Gilles 'SO- stop being evil'
  • 51,415
  • 13
  • 121
  • 180
  • So the reason I had to use /usr/local/bin/suid-env2 is because the suid-env2 is run with the sticky bit and when it runs bash it does not clear up the environment? In regards to the part about making the exploit persistent at the end, why did you say "without completely scrapping the existing instance of the vulnerable system"? – questioner Jul 13 '22 at 16:46
  • 1
    @questioner Setuid bit, not sticky bit, but otherwise, yes. About making the system persistent: any competent administrator will reinstall the system from scratch (“[nuke it from orbit](https://security.stackexchange.com/q/24195)”) when they detect a potential compromise. But if they don't (for example because they eliminate the potential vulnerability but don't realize it's been exploited), the attacker wants to keep a way to stay in. A setuid binary is really easy to detect though, and pretty silly when there are much more discreet off-the-shelf rootkits. – Gilles 'SO- stop being evil' Jul 13 '22 at 17:37