gef: heap arenas NoneType + heap-view doesn’t find heap

  • Did you use the latest version of GEF from dev branch?
  • Is your bug specific to GEF (not GDB)? - Try to reproduce it running gdb -nx
  • Did you search through the documentation first?
  • Did you check issues (including the closed ones) - and the PR?

Step 1: Describe your environment

  • Operating System / Distribution: 5.15.49-1-MANJARO
  • Architecture: amd64
  • GEF version (including the Python library version) run version in GEF.
gef➤  version
GEF: (Standalone)
Blob Hash(/home/raven/.gef-430d9d3f7efab6e55215c07bd1694c3a4c4cb6cd.py): 0653da00ca754d9580d60a330907c988d6468dee
SHA256(/home/raven/.gef-430d9d3f7efab6e55215c07bd1694c3a4c4cb6cd.py): f14771fa2cafaf7bca7f8b2a53db54c85f6612f42ac8ff80aaaa476fd7553e69
GDB: 12.1
GDB-Python: 3.10

Step 2: Describe your problem

Steps to reproduce

  1. gdb -q ./a.out
  2. start
  3. break *puts
  4. c
  5. Check heap

Minimalist test case

// test.c
// clang test.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>


int main(int argc, char **argv) {
  void *p = malloc(0x64);
  void *r = malloc(0x28);
  void *q = malloc(0x64);

  puts("Just some filler content to break on");
  fflush(stdout);

  return 0;
}

Observed Results

gef➤  heap chunks
Chunk(addr=0x555555559010, size=0x290, flags=PREV_INUSE)
    [0x0000555555559010     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................]
Chunk(addr=0x5555555592a0, size=0x70, flags=PREV_INUSE)
    [0x00005555555592a0     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................]
Chunk(addr=0x555555559310, size=0x30, flags=PREV_INUSE)
    [0x0000555555559310     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................]
Chunk(addr=0x555555559340, size=0x70, flags=PREV_INUSE)
    [0x0000555555559340     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................]
Chunk(addr=0x5555555593b0, size=0x410, flags=PREV_INUSE)
    [0x00005555555593b0     4a 75 73 74 20 73 6f 6d 65 20 66 69 6c 6c 65 72    Just some filler]
Chunk(addr=0x5555555597c0, size=0x20850, flags=PREV_INUSE)
    [0x00005555555597c0     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................]
gef➤  heap arenas
Arena(base=0x7ffff7f8a400, top=0x0, last_remainder=0x0, next=0x0, next_free=0x0, system_mem=0x0)
[!] Command 'heap arenas' failed to execute properly, reason: 'NoneType' object has no attribute 'cast'
gef➤  heap-view
[!] The heap has not been initialized
gef➤  vis
[!] The heap has not been initialized
gef➤  

What happened? This could be a description, log output, etc.

Expected results

  • heap arenas should not throw an error on a pointer deref 😄
  • heap-view should properly recognize the arena so visualization can take place

Traces

image

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 17 (10 by maintainers)

Most upvoted comments

Those bugs were confirmed to be fixed by #869 and hugsy/gef-extras#77 on Debian, Ubuntu & Fedora.

Only ArchLinux seems to fail for some reason, nonetheless we can close the issue. @0xricksanchez Feel free to open one if you get more insight as to why this fix won’t work on Arch but some more help will be needed there.

Must be an arch specific problem, ubuntu 22.04 with libc 2.35 works fine.

image

So, your problem is two-fold:

  • There was some major inconsistencies in the way GEF represents the heap. They are now addresses (branch heap_bugz). Not only the code was massively simplified, it is also faster and produces the correct output (on a ubuntu 22.04 with libc 2.35): image

  • The 2nd issue is specific to visualize-heap. So I’ll open an issue in GEF-Extras for better tracking, because there’s plenty of stuff that can be improved (not done yet).

Feel free to test on your side and let me know.

Cheers,

I can repro the bug with the Dockerfile you provided 🎉

Assumption: This all may be related to different GLIBC versions as my testing on Arch/Manjaro has been exclusively done with GLIBC 2.35, where I ran into initial issue. Other tests with GLIBC 2.31 and 2.33 above showed a sane behavior.

Backtracking

Testing on GLIBC 2.34 on an ubuntu system with the following setup:

# GLIBC 2.34
# docker build -f <this_dockerfile> -t gef_glibc234 .
# docker run -it --rm gef_glibc234 /bin/bash
FROM ubuntu:impish
ENV DEBIAN_FRONTEND noninteractive

RUN apt update && apt install -y file git binutils python3 python3-pip vim gcc gdb curl wget python-is-python3 locales && \
    sed -i -e 's/# en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/' /etc/locale.gen && \
    dpkg-reconfigure --frontend=noninteractive locales && \
    update-locale LANG=en_US.UTF-8 && \
    bash -c "$(curl -fsSL https://gef.blah.cat/sh)" && \
    wget https://github.com/hugsy/gef/raw/main/scripts/gef-extras.sh && \
    sed -i -e "s/git clone/git clone -b 'fix_heap_viz_new_api'/g" gef-extras.sh && \
    chmod 755 gef-extras.sh && \
    ./gef-extras.sh && \
    apt-get clean

ENV LC_ALL=en_US.UTF-8

Yields the following: image

arena.top is not 0x0 but the vis/heap-view command runs into another issue, while the top chunk is again listed twice in the heap chunks view

Note that I did the test with the heap-view version in the fix_heap_viz_new_api branch