david942j / one_gadget

The best tool for finding one gadget RCE in libc.so.6

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

The filename that ends with a number might cause one_gadget to fail to find some gadgets for amd64

lebr0nli opened this issue · comments

There's a weird behavior when using one_gadget on the filename that ends with a number.
This bug can be reproduced by something like:

$ objdump --version
GNU objdump (GNU Binutils for Ubuntu) 2.38
Copyright (C) 2022 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
$ one_gadget --version
OneGadget Version 1.8.1
$ cp /lib/x86_64-linux-gnu/libc.so.6 .
$ one_gadget /lib/x86_64-linux-gnu/libc.so.6 > a
$ one_gadget libc.so > b
$ mv libc.so x.1337
$ one_gadget x.1337 > c
$ md5sum a
55a458aadc6b2c93fccc164ad5bedd6d  a
$ md5sum b
16db62efc9d108f06c6d2aecec205484  b
$ md5sum c
55a458aadc6b2c93fccc164ad5bedd6d  c

As you can see, although libc.so.6, libc.so, and x.1337 are actually the same file, the output of libc.so is different.


Seems like this bug is caused by this line:

dump = `#{@objdump.command(start: jmp_addr, stop: jmp_addr + 100)}|grep -E '[0-9a-f]+:'`

When the filename is something like: libc.so.6, grep -E '[0-9a-f]+:' will also match the filename in the objdump output:

$ objdump --no-show-raw-insn -w -d -M intel /lib/x86_64-linux-gnu/libc.so.6 | grep -E '[0-9a-f]+:' | head
/lib/x86_64-linux-gnu/libc.so.6:     file format elf64-x86-64
   28000:	push   QWORD PTR [rip+0x1f1002]        # 219008 <_GLOBAL_OFFSET_TABLE_+0x8>
   28006:	bnd jmp QWORD PTR [rip+0x1f1003]        # 219010 <_GLOBAL_OFFSET_TABLE_+0x10>
   2800d:	nop    DWORD PTR [rax]
   28010:	endbr64
   28014:	push   0x35
   28019:	bnd jmp 28000 <__abi_tag+0x27c5c>
   2801f:	nop
   28020:	endbr64
   28024:	push   0x34

Then it somehow causes some bugs and makes the candidates in jmp_case_candidates never pass.


This issue can be fixed by adding the --dward-start=0 option when running the objdump.
Since the description in the manual of the objdump is a little bit unclear for me, here's the source code reference that shows why --dward-start=0 works:
https://github.com/bminor/binutils-gdb/blob/a89e364b45a93acd20f48abd787ef5cb7c07f683/binutils/objdump.c#L6158-L6163
https://github.com/bminor/binutils-gdb/blob/a89e364b45a93acd20f48abd787ef5cb7c07f683/binutils/objdump.c#L5586-L5589