DavidBuchanan314
Unable to locate _dl_open symbol
I'm also having this issue on Ubuntu 20.
Searching through commits on binutils
git log --all --grep='dl_open' doesn't turn up any results since 2016
git grep -I 'dl_open' turns up none as well, which seems weird since it contains ld's source code.
From some googling around and playing with the binary itself I started to dig into GLIBC_PRIVATE I found this thread I believe something changed that now labels it private so you can use it within the library but you as an external caller can't locate the address offset. That's my current working theory but need to get some more time to play around with it.
Edit:
Shoulda grepped for dlopen multiple results... still splunking for answers.
If the symbol is no longer exported, then I have a vague idea for a workaround - which is, to locate the function via heuristics. I'll need to see if any of the exported functions reference it, and if so, disassemble them to extract its offset.
I got the same issue on Ubuntu 21. @DavidBuchanan314, Is there quick workaround to fix issue? Thanks
Tim
Note to self: investigate __libc_dlopen_mode
See also: https://github.com/apitrace/apitrace/issues/756
(might need that heuristic approach after all)
Upon further investigation, these changes were made because libdl is now directly part of libc - so I suppose we can just use dlopen directly, on newer libcs?
https://lwn.net/Articles/864920/
@DavidBuchanan314, we just moved a tool that started out as a fork of dlinject into public beta today (https://github.com/BishopFox/asminject). One of the main reasons I built it was this particular issue. In case it's helpful, I think the root cause is that different Linux distributions expose the library-loading function differently. Some of them have a function in ld called _dl_open, like dlinject is looking for. Some of them have a function in libc called __libc_dlopen_mode. Some of them have a function in libdl called dlopen. For the library-injection payloads in asminject.py, I created variations that would handle _dl_open and dlopen. Every distribution I ran across that had __libc_dlopen_mode also had one of the other two, so I haven't made a payload for that variation yet.
I've listed the variations I found in my testing here: https://github.com/BishopFox/asminject/blob/main/docs/examples-shared_library_injection.md
You only need to change 86 lines of code to ‘’if re.match(r"./libc-..so", ld_path):‘’ and change 94 lines of code to "dl_open_offset = lookup_elf_symbol(ld_path, "__libc_dlopen_mode")" and chane 33 lines to "symtab = elf.get_section_by_name(".dynsym")", then it'll be succeed.
You only need to change 86 lines of code to ‘’if re.match(r"./libc-..so", ld_path):‘’ and change 94 lines of code to "dl_open_offset = lookup_elf_symbol(ld_path, "__libc_dlopen_mode")" and chane 33 lines to "symtab = elf.get_section_by_name(".dynsym")", then it'll be succeed.
Have you tried that on several Linux distributions? As I mentioned in my reply, there seems to be at least three different models that different Linux distributions use. So I would expect your approach to work on Debian and its derivatives (although maybe not newer versions of Ubuntu), but not on OpenSUSE or Arch, for example.