[USENIX-WOOT] Introduction to Procedural Debugging through Binary Libification

1
Introduction to
Procedural
Debugging through
Binary Libification
August 2024
Pr. Jonathan Brossard
WOOT'24
18th USENIX WOOT Conference on Offensive Technologies, August 12-13th 2024 Philadelphia, PA, USA

2
Motivation
Problem Statement
Introduction to Libification
Libification Process
Automation
Validation
Conclusion & Future Work

3

4
Software Bill of Materials are becoming mandatory
Software Bill of Materials (SBOMs) contain lists
of CPEs or Package URLS (purl) describing all
the components of a given Software.
They allow to perform vulnerability
assessments by comparing the CPEs to the
dictionaries published by the NIST for each CVE.

5
Software Bill of Materials are becoming mandatory

6
6
SBOMs provide possible CVES.
For each vulnerability : is it true ?

7

8
Industry standard to Prove exploitability : Write an exploit
This bar is too high.
If we decompose an exploit into 3 problems:
- Reach the vulnerable function
- Trigger the vulnerability
- Achieve code execution/Weaponize
The first step alone is already undecidable ("reachability problem").
Undecidable

9
Let's do only step 2:
If we decompose an exploit into 3 problems:
- Reach the vulnerable function
- Trigger the vulnerability
- Achieve code execution/Weaponize
This a reasonable heuristic to determine vulnerability of the application.
We'd like to be able to call the vulnerable function directly.
Problem : How to do this out of context ?
Proposal : Let's turn the vulnerable application into a shared library !

10

11
Source Code Compiler Assembly
Code (.S)
Assembler
Static Link Editor
Shared Libraries
Executables
Object Files (.o)

12
Code (.S)
Assembler
Static Link Editor
Executables
Object Files (.o)
Disassembly
Shared Libraries
Undecidable

13
Code (.S)
Assembler
Static Link Editor
Shared Libraries
Executables
Object Files (.o)
Decompilation
Undecidable

14
Code (.S)
Assembler
Static Link Editor
Shared Libraries
Executables
Object Files (.o)
Libification
(wld)

Same headers, same segments, same
sections. They mostly differ through
their metadata (various ELF headers)

Same headers, same segments, same
sections. They mostly differ through
their metadata (various ELF headers)
Modify the various ELF headers to
turn an Executable into a Shared
Library
The work to be done:

17

Libification Oracle
Let's modify a test binary
(ls) until we manage to
load it in memory...

typedef struct elf64_hdr {
unsigned char e_ident[EI_NIDENT]; /* ELF "magic number" */
Elf64_Half e_type; = ET_DYN
Elf64_Half e_machine;
Elf64_Word e_version;
Elf64_Addr e_entry; /* Entry point virtual address */
Elf64_Off e_phoff; /* Program header table file offset */
Elf64_Off e_shoff; /* Section header table file offset */
Elf64_Word e_flags;
Elf64_Half e_ehsize;
Elf64_Half e_phentsize;
Elf64_Half e_phnum;
Elf64_Half e_shentsize;
Elf64_Half e_shnum;
Elf64_Half e_shstrndx;
} Elf64_Ehdr;
Modify the ELF type from ET_EXEC
to ET_DYN in the ELF header.

typedef struct elf64_shdr {
Elf64_Word sh_name; /* Section name, index in string tbl */
Elf64_Word sh_type; SHT_DYNAMIC
Elf64_Xword sh_flags; /* Miscellaneous section attributes */
Elf64_Addr sh_addr; /* Section virtual addr at execution */
Elf64_Off sh_offset; /* Section file offset */
Elf64_Xword sh_size; /* Size of section in bytes */
Elf64_Word sh_link; /* Index of another section */
Elf64_Word sh_info; /* Additional section information */
Elf64_Xword sh_addralign; /* Section alignment */
Elf64_Xword sh_entsize; /* Entry size if section holds table */
}
Parse the array of section headers,
identify the section with .dynamic
section with type SHT_DYNAMIC
If section headers are missing,
parsing the array of segments and
identifying the PT_DYNAMIC
segment leads to the same
.dynamic content.

typedef struct {
Elf64_Sxword d_tag;
union {
Elf64_Xword d_val;
Elf64_Addr d_ptr;
} d_un;
} Elf64_Dyn;
The .dynamic section contains an
array of Elf64_Dyn entries.
Replace any optional DT_BIND_NOW entry with a d_tag = DT_NULL
entry and a pointer of value d_ptr = –1.
If the binary features a DT_FLAGS_1 entry, remove the flags Remove
DF_1_NOOPEN and DF_1_PIE flags if present:
dyn->d_un.d_val = dyn->d_un.d_val & ~DF_1_NOOPEN;
dyn->d_un.d_val = dyn->d_un.d_val & ~DF_1_PIE;
Optionally ignore constructors and destructors by zeroing the d_val
values associated with DT_INIT_ARRAYSZ, DT_INIT_ARRAY and
DT_FINI_ARRAYSZ, DT_FINI_ARRAY respectively.

22

https://zenodo.org/doi/10.5281/
zenodo.11298208
URL: https://github.com/endrazine/wcc
License: MIT/BSD-2

24

25
Test Repository:
https://github.com/endrazine/wcc-tests
Test Plan:
Libify The 435 binaries of a default Ubuntu 24.04 amd64 LTS distribution
Time taken (total) : 3 seconds
Libification Test Count
Passed 435
Failed 0
https://zenodo.org/doi/10.5281/
zenodo.11301408

26

27
Code (.S)
Assembler
Static Link Editor
Executables
Object Files (.o)
Libification
Decompilation
Disassembly
Shared Libraries
Undecidable

28
Code (.S)
Assembler
Static Link Editor
Shared Libraries
Executables
Object Files (.o)
Unlinking
(wcc)

29
- Libify ELF executables
- Make ELF executables scriptable
- Call arbitrary functions
(procedural debugging)
URL: https://github.com/endrazine/wcc
License: MIT/BSD-2

30
The ability to turn ELF
executables into libraries
will allow us to create
partial proofs of
vulnerabilities in the form
of WSH test scripts.

31

[USENIX-WOOT] Introduction to Procedural Debugging through Binary Libification

More Related Content

Similar to [USENIX-WOOT] Introduction to Procedural Debugging through Binary Libification (20)

More from Moabi.com (20)

Recently uploaded (20)

[USENIX-WOOT] Introduction to Procedural Debugging through Binary Libification