Ubuntu 16.04 GLIBC 2.23

[alfax1]

Hello blasty
I'm trying to make the poc work on Ubuntu 16.04 but..
first of all the nss_load_library technique doesn't work -> turns out sudoedit never tried to load any systemd.so libraries
so this made the code unusable and I'm now trying to make it work by process_getenv method.
All of the techniques used to exploit the heap overflow relied on the fact that tcache was enabled and this made early heap allocation very easy to occur, and i think this is because the tcache bin range is too wide 0x20-0x408.
Before <glibc 2.31, Tcache wasn't implemented yet.... so the heap allocation became a problem (correct me if i'm wrong) as i couldn't allocate any chunk before the (sudo_hook_entry* struct).

Do you have any idea on how to make an early allocation with fastbins? i tried to make the LC env values as small to fit into Fastbins... but everytime i break at the set_cmnd code of reading args i never saw any free [fast]/bin before the target struct...

Also i wanted to say that using pwndbg There are no free chunks containing My LC values at all,
On the contrary Ubuntu 20.04 using your exploit i saw free chunks containing the LC environments.

PS: i used the fuzzer edited by you in lockedbyte repo but i know it relies on RIP to search for exploits. but there was no heap free chunks before the struct address in the first place... and the sanity checks of free/malloc are in the way too.
If we manage to make the poc work with Ubuntu glibc version <2.31 i think all distros with old versions too will be easy to exploit
I just want the approach and i will gladly put time to try it./ or them

Thanks for your time.

[alfax1]

actually tcache was implemented in glibc 2.26... my bad

[bl4ckh0l3z]

Hello blasty

I'm trying to make the poc work on Ubuntu 16.04 but..

first of all the nss_load_library technique doesn't work -> turns out sudoedit never tried to load any systemd.so libraries

so this made the code unusable and I'm now trying to make it work by process_getenv method.

All of the techniques used to exploit the heap overflow relied on the fact that tcache was enabled and this made early heap allocation very easy to occur, and i think this is because the tcache bin range is too wide 0x20-0x408.

Before <glibc 2.31, Tcache wasn't implemented yet.... so the heap allocation became a problem (correct me if i'm wrong) as i couldn't allocate any chunk before the (sudo_hook_entry* struct).

Do you have any idea on how to make an early allocation with fastbins? i tried to make the LC env values as small to fit into Fastbins... but everytime i break at the set_cmnd code of reading args i never saw any free [fast]/bin before the target struct...

Also i wanted to say that using pwndbg There are no free chunks containing My LC values at all,

On the contrary Ubuntu 20.04 using your exploit i saw free chunks containing the LC environments.

PS: i used the fuzzer edited by you in lockedbyte repo but i know it relies on RIP to search for exploits. but there was no heap free chunks before the struct address in the first place... and the sanity checks of free/malloc are in the way too.

If we manage to make the poc work with Ubuntu glibc version <2.31 i think all distros with old versions too will be easy to exploit

I just want the approach and i will gladly put time to try it./ or them

Thanks for your time.

Totally subscribe...moving to fastbins abuse will be valuable. Tcache is not available in every glibc < 2.26

[ghost]

Hello alfax1, try to use Worawit CVE-2021-3156, use exploit_userspec.py! If u need python3 u can go to Python2 to 3 conventer and in 2 clicks build python3 version. Im tested on UBUNTU 16.04.2, GLIB 2.23, KERNEL 4.4.0