tcache attacks on glibc2.27 no longer work on ubuntu 18.04

[balbassam]

Was testing in an ubuntu 18.04 docker container and found that I had to downgrade the libc version to get them working.

ldd (Ubuntu GLIBC 2.27-3ubuntu1.4) 2.27
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.
root@ebae5017bf23:/how2heap# cd glibc_2.27/
root@ebae5017bf23:/how2heap/glibc_2.27# ./tcache_dup 
This file demonstrates a simple double-free attack with tcache.
Allocating buffer.
malloc(8): 0x55bbb95f6670
Freeing twice...
free(): double free detected in tcache 2
Aborted (core dumped)

root@ebae5017bf23:/how2heap/glibc_2.27# cd ..
root@ebae5017bf23:/how2heap# DEBIAN_FRONTEND=noninteractive dpkg -i libc6_2.27-3ubuntu1.2_amd64.deb 
dpkg: warning: downgrading libc6:amd64 from 2.27-3ubuntu1.4 to 2.27-3ubuntu1.2
(Reading database ... 12312 files and directories currently installed.)
Preparing to unpack libc6_2.27-3ubuntu1.2_amd64.deb ...
Unpacking libc6:amd64 (2.27-3ubuntu1.2) over (2.27-3ubuntu1.4) ...
Setting up libc6:amd64 (2.27-3ubuntu1.2) ...
Processing triggers for libc-bin (2.27-3ubuntu1.4) ...

root@ebae5017bf23:/how2heap# cd -
/how2heap/glibc_2.27

root@ebae5017bf23:/how2heap/glibc_2.27# ./tcache_dup 
This file demonstrates a simple double-free attack with tcache.
Allocating buffer.
malloc(8): 0x5592d164a670
Freeing twice...
Now the free list has [ 0x5592d164a670, 0x5592d164a670 ].
Next allocated buffers will be same: [ 0x5592d164a670, 0x5592d164a670 ].

I got the deb file from here https://security.ubuntu.com/ubuntu/pool/main/g/glibc/libc6_2.27-3ubuntu1.2_amd64.deb

[mdulin2]

Does Ubuntu backwards apply LibC patches? At some point, I had a similar issue with 16.04 Ubuntu.

[Kyle-Kyle]

@mdulin2 it does. that's why we have a testing system for how2heap

[Kyle-Kyle]

I double-checked. They did backport the tcache-key patch to new 2.27. At this point, I think there is no way to make simple tcache dup work. I just moved it to a folder called obsolete. However, it doesn't mean double free is not exploitable. It is still exploitable through some other methods like house_of_botcake

[mdulin2]

The backport is put into new 2.27 but that's not from the original release of course. So, should it just stay in 2.27 but make a note on the POC of the backport?

To me, the original 2.27 LibC version is what we should be basing the repository off of. Otherwise, all security based backports for Malloc would cause a bunch of weird scenarios like this. I usually check https://elixir.bootlin.com/glibc/glibc-2.27/source/malloc/malloc.c for source code when I need it.

[mdulin2]

One option would be to include an original compiled version of the LibC and Loader for that version of GLibC? This way, people would have a way to run all of the techniques with a known version of LibC.

Recently, I started compiling my own versions of LibC with no optimizations within Malloc and with debugging symbols. I would be happy to share these builds.

[Kyle-Kyle]

the problem is it is troublesome to set up an environment that uses the particular initial libc release. For the original release, maybe you can use pocs from the obsolete folder?

[mdulin2]

To run the 2.27 techniques in general, the users will need to have a 2.27 release. Besides the case when people run it on the base system, I would expect people trying out different techniques for different versions, which would require other versions of LibC. It would be easier to just include the versions of the library here. You're right though, setting up an ENV to use a different version of LibC can be annoying.

I would be happy to write up some docs on LD_PRELOAD, pwntools and other things here to make this work though! I've already got my own tools for this; I could just tidy them up and add them here.

[Kyle-Kyle]

For gold-standard, currently what we are doing is using ubuntu's releases as the golden-standard. For running different versions of libcs, we have the glibc_build.sh and glibc_run.sh scripts.

[Kyle-Kyle]

accidentally clicked close... oops.

[mdulin2]

Ahh, I see the issue now. The gold-standard backported the version and we expect people to compile things themselves.

[mdulin2]

I think an argument could be made for either case then.

• Have pre-compiled versions of LibC with the techniques at the time of release
• Have an obsolete folder for techniques that are made bad by the backport

At this point, it probably makes sense to use the obsoleted version as this is the current setup of the repo.

[Kyle-Kyle]

btw, you can get the source for ubuntu release by running apt source. I think this should be documented.

[Kyle-Kyle]

I think it is safe to close this issue now. If you still have questions, feel free to reopen it.