Exploit fails on Debian cloud image

[MattyAgain]

Hi,

Thanks for this really convenient exploit. I was able to get it working on my Debian 10 and Ubuntu 20.04 machines.

However, I noticed it failed on one of my Debian Cloud (OpenStack) virtual machines. The VM in question is running the linux-image-4.19.0-13-cloud-amd64 kernel, which is used by many cloud providers.

When I execute sudo-hax-me-a-sandwich 1 on this system, it prompts for a password, even though the user account has no sudo access and was created using --disabled-password (it has no password associated with it):

usernopass@debian10-2:~/CVE-2021-3156$ uname -a
Linux debian10-2 4.19.0-13-cloud-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64 GNU/Linux
usernopass@debian10-2:~/CVE-2021-3156$ apt policy sudo
sudo:
  Installed: 1.8.27-1+deb10u2
  Candidate: 1.8.27-1+deb10u3
  Version table:
     1.8.27-1+deb10u3 500
        500 http://security.debian.org/debian-security buster/updates/main amd64 Packages
 *** 1.8.27-1+deb10u2 500
        500 http://deb.debian.org/debian buster/main amd64 Packages
        100 /var/lib/dpkg/status
usernopass@debian10-2:~/CVE-2021-3156$ ./sudo-hax-me-a-sandwich 1

** CVE-2021-3156 PoC by blasty <[email protected]>

using target: 'Debian 10.0 (Buster) - sudo 1.8.27, libc-2.28'
** pray for your rootshell.. **

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for usernopass:
Sorry, try again.
[sudo] password for usernopass:
sudoedit: 1 incorrect password attempt

Running the exploit from a user that does have a password also causes the prompt. When I enter the password, the message "userwithpass is not in the sudoers file. This incident will be reported." is returned. And I made sure the installed version of sudo is vulnerable; sudoedit -s '\' $(perl -e 'print "A" x 65536') causes a crash.

[Ayush-Walia]

I was trying with docker image of ubuntu 20.04 and facing same issue, its first asking for password then giving this message

user@36994e126440:~/CVE-2021-3156$ ./sudo-hax-me-a-sandwich 0
** CVE-2021-3156 PoC by blasty [email protected]
using target: 'Ubuntu 20.04.1 (Focal Fossa) - sudo 1.8.31, libc-2.31'
** pray for your rootshell.. **
[sudo] password for user:
user is not in the sudoers file. This incident will be reported.

[blasty]

@MattyAgain is there an easy way to get access to a Debian Openstack VM? I tried converting the qcow2 to vdi using qemu-img convert.. but it stops somewhere early in the kernel boot, eg. I don't see any userland init stuff.

[Ayush-Walia]

@blasty have you tried this exploit with ubuntu 20.04 docker image?

[MattyAgain]

@blasty Here's a zip of a VirtualBox folder for a Debian OpenStack VM:

https://drive.google.com/file/d/1GeaE3jNmmBecHfUIrKBgSKeCJqX9nwsk/view?usp=sharing

Unfortunately, I wasn't able to export it as an OVA because of how the disk is configured, but you should be able to copy the folder to your VirtualBox VMs folder and run it from there. Worst case if it doesn't work, I can spin up a VPS with the same cloud kernel and grant you access to it.

It uses NAT networking. The port forwarding rule is Host 2222 -> Guest 22, so ssh debian@localhost -p2222. The admin user is "debian" with the password "debian". There's also a low privileged user called "test" and I cloned this repository into both users' home folders.

[blasty]

@MattyAgain thanks for the zip file, VM works a charm. Unfortunately I was not able to get the exploit working so far. I might investigate more but no promises when. (Being flooded with "look into support for distro/version XYZ" at the moment)

[MattyAgain]

Understood @blasty. I was perplexed because the binary and shared libraries seem to be identical on both systems. Something I recently noticed is that libnss_files-2.28.so, sudoers.so, and libpam.so.0.84.2 are ordered differently in the address space. Also the cloud version loads several files under /usr/lib/locale/ while the desktop version only loads /usr/lib/locale/locale-archive.