After quite some time and work, I’m happy to announce the new release of the
Linux
Heap
Analysis
Plugins, which are now part of the Rekall
project, but not yet part of an official Rekall release, so you have to grab
them manually.
This release fixes several bugs and adds the following features:
- Support for Glibc version 2.26 (tcache chunks) and 2.27
- Heapsearch now includes Rekall’s yara scan functionality
- x86 Glibc versions with a modified MALLOC_ALIGNMENT value of 16 (as done in arch’s glibc package 2.26) are now supported
- Improved retrieval of main_arena and new automated retrieval of malloc_par struct; so for the majority of cases, the corresponding cmd line options are not necessary anymore and hence no debug information have to be retrieved.
- main_arena and malloc_par struct retrieval now also applies for statically linked binaries; there might however be cases, where it is necessary to specify the malloc_par struct offset and the used glibc version number
While Glibc version 2.27 does not really change much for the heap from a
forensics point of view, version 2.26 introduced a new feature called tcache
(per thread cache). Those caches are essentially just a new type of bin, holding
freed chunks, but
seem to improve the performance.
Sadly,
only two days after its
first commit,
there was already a blog post explaining
the functionality (not so sad 😉 ) and also some discovered vulnerabilities
(here we go with the sad part).
Besides introducing a new landscape for attackers, this feature added two new
heap management structs and one additional chunk per thread-heap (each thread
has its own heap, up until an upper limit). This chunk is located at the
beginning of each heap and hence, part of a raw heap dump (so be aware of that,
if you are doing a raw analysis without the plugins).
The chunk holds the content of the tcache_perthread_struct, which has to
members:
counts: The number of chunks for each “tcache bin”, which is kept for performance reasons.entries: The pointers to the first tcache chunk for each “tcache bin”.
Both are arrays of size 64. counts is of type char and entries of type
pointer. The index for each array corresponds to the other one.
The following figure illustrates the connection between counts, entries and
the referenced tcache chunks:
index counts entries
0 \x01 0x1230 -------> tcache_chunk
1 \x02 0x1290 -------> tcache_chunk -------> tcache_chunk
2 \x00 0x0
3 \x01 0x1350 -------> tcache_chunk
...
For details on how bins work, see our DFRWS Paper here or the more detailed Tech Report here.
The other management struct is tcache_entry and contains only one member:
next , which (surprisingly) points to the next chunk in the tcache bin.
The maybe a bit more surprising part is the fact that, unlike with all other
heap pointers (fd, bk, fd_nextsize, bk_nextsize), the “tcache bin” pointers
point not to the beginning of the next chunk of the tcache bin, but to the
beginning of its data part (located at the fd member, where the next
tcache_entry struct is stored). This is the main difference (from a forensics
point of view) between a fastbin chunk and a tcache chunk. While they both are
freed chunks, whose next chunk’s size field has not the PREV_INUSE bit set and
both contain a pointer to the next freed chunk, the target location of that
pointer differs:
fastbin chunk next fastbin chunk
+-----------------+ -----------> +-----------------+
| prev_size | | | prev_size |
+-----------------+ | +-----------------+
| size | | | size |
+-----------------+ | +-----------------+
| fd |----------- | fd |------ ...
+-----------------+ +-----------------+
| data | | data |
| ... | | ... |
tcache chunk next tcache chunk
+-----------------+ +-----------------+
| prev_size | | prev_size |
+-----------------+ +-----------------+
| size | | size |
+-----------------+ +-----------------+
| next |---------------------> | next |------- ...
+-----------------+ +-----------------+
| data | | data |
| ... | | ... |
So far for details about the new glibc versions.
Also: Johannes Stadlinger presented his new Plugins for Rekall (based on the Heap Analysis Plugin) at this years IMF Conference with our Paper: “Linux Memory Forensics: Expanding Rekall for Userland Investigation“. These plugins allow to extract information for the following applications from Linux Memory:
cUrl
gnome-keyring-d
seahorse
ssh
sshfs
sqlite
pwsafe
owncloud
See the presentation for more details. There will soon be a release of those plugins, compatible with this new release, so stay tuned!
\x00
Frank