Exploitation on Debian 10 cloud image

[MattyAgain]

Hi,

I was wondering if you have looked into exploitation strategies for systems based on Debian 10 cloud images, such as OpenStack. Many cloud providers use these images to deploy Debian instead of the standard downloads.

On these systems, the nscd service is running by default, so I'm unable to use any of the nss-based exploits. However, exploit_timestamp_race doesn't seem to work either; the exploit fails with this message, and the gg user is nonexistent:

...[truncated]
sudoedit: ././././././././././././a: command not found
Failed. can cleanup
sudoedit: ././././././././././././a: command not found
Failed. can cleanup
su: user gg does not exist
now can use "su - gg" with 'gg' password to become root

The version of glibc seems new enough that it's not tcache related, but I could be wrong. Here is some information about the system in question. I also created a VirtualBox VM here if you ever want to play around with the cloud image I'm testing on.

$ ldd --version
ldd (Debian GLIBC 2.28-10) 2.28
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
$ uname -a
Linux debian10 4.19.0-14-cloud-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 GNU/Linux
$ 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://deb.debian.org/debian buster/main amd64 Packages
        500 http://security.debian.org/debian-security buster/updates/main amd64 Packages
 *** 1.8.27-1+deb10u2 100
        100 /var/lib/dpkg/status
$ apt policy libc6
libc6:
  Installed: 2.28-10
  Candidate: 2.28-10
  Version table:
 *** 2.28-10 500
        500 http://deb.debian.org/debian buster/main amd64 Packages
        100 /var/lib/dpkg/status

[worawit]

You were running an exploit from user that can sudo without password.
My exploit does not cover this case because you can become root without an exploit.

[MattyAgain]

@worawit My apologies, silly mistake of mine. Thank you for the quick reply. However, running the timestamp race on a user without sudo privileges now results in "out of dir name" after many attempts (full log attached if it matters).

log.txt

[worawit]

From your log, a race is almost success ("Failed to create 2nd symbolic" message).

Do you assign only 1 CPU to VM?
If yes, try assign at least 2 CPUs to VM and run the exploit again.

Note: to rerun the exploit after "out of dir name", you have to remove tmp directories with "rf -rf /tmp/gogogo*" with root user

[MattyAgain]

Adding another core worked! Is it fair to say this exploit requires more than one CPU for success, or is it possible to make it work with only one?

[worawit]

I expect at least 2 cores when writing an exploit but forgot adding it in requirement.
With only 1 CPU, it is almost impossible that an exploit preempt an sudo at the right time.