Open MattyAgain opened 3 years ago
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.
@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).
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
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?
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.
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: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.