The typeinfo module used a static global tempdir location of /tmp/pwndbg
that an attacker may control and prepare symlinks of the predictable
files that are then written to.
Package glibc-debuginfo, which is a requirement,
requires repo-debug to be enabled, which is not enabled
by default.
This commit enables this repo when installing if it is
not already enabled.
TL;DR: With .splitlines() we splitted over universal splitlines which did not correspond to GDB's target code line splitting...
As a result we got `context code` to produce bogus out of sync lines that didn't correspond to GDB's `line` command.
See also https://docs.python.org/3/library/stdtypes.html#str.splitlines
Addresses #957 by enclosing anonymous map names printed by vmmap in square brackets.
Search still works & xinfo plays nice, but please let me know if you find anything this breaks.
Revert the change from 3e4ad60 and make the `pwndbg.proc.get_file` to strip the "target:" prefix instead of the `pwndbg.proc.exe`.
This way, we will prevent bugs when pwndbg code would use `pwndbg.proc.exe` on remote targets but not pass the returned path to `pwndbg.proc.get_file` to get the real remote file and instead use the local one (if it exists in the same path).
Additionally, we assert the `path` passed to `pwndbg.proc.get_file` so we prevent incorrect use of the function when an absolute path or not a remote path is passed to it.
Before this commit the `pwndbg.proc.exe` could return a "target:" prefix when `pwndbg.proc.exe` was executed on remote targets. This could be seen by:
1. Executing gdbserver in one terminal: gdbserver 127.0.0.1:1234 `which ps`
2. Executing `gdb -ex 'target remote :1234'` in another terminal and then invoking `pi pwndbg.proc.exe`.
This resulted in `checksec` (and some other) commands crashes which were using the `pwndbg.file.get_fille` functionality as it downloaded the remote file by using the `gdb.execute("remote get %s %s")` command passing it a path prefixed with `"target:"` which this GDB command does not support.
The `pwndbg.memoize.reset_on_new_base_address` decorator is super problematic: its start event was called before `pwndbg.arch.update` event because the pwndbg/memoize.py file is executed faster than the pwndbg/arch.py file. This happens even if we import pwndbg/arch.py as first import because it imports regs.py and events.py and those import memoize.py and so on.
TL;DR: The decorator was quite redundant and made too many calls in the end which caused some problems when executing:
1. In one console: qemu-x86_64 -g 1234 `which ps`
2. In another, attaching to this via `gdb` -> `target remote :1234`
The `explore_registers` and `clear_explored_pages` functions are currently redundant as we create an empty memory page on QEMU targets.
Also, this functions are not so useful to be called automagically on real remote and embedded targets where we may not have the memory pages information (as it may be too slow to explore stuff via remote gdbstub on a real embedded target).
E.g. for calls like this:
```
► 0x555555554a57 <main+296> call ioctl@plt <ioctl@plt>
fd: 0x3
request: 0xae01
vararg: 0x0
```
We want to display the `fd` as: `fd: 0x3 (/some/path)` fetched from
`readlink -f /proc/$PID/fd/$FD`.
The ASLR command did not work properly on QEMU kernel targets: it read /proc/sys/kernel/randomize_va_space and then /proc/<pid>/personality on local filesystem which was wrong, and returned that it couldn't read personality.
Now, this commit made so that:
- the `pwndbg.file.get_file` will print a warning if it returns a local path on remote targets
- the `check_aslr` was refactored: we don't run this on `new_objfile` or cache its result; the `pwndbg.vmmap.aslr` was also removed as it was never used
- the `pwndbg.vmmap.check_aslr` and `aslr` command will now return info if we couldn't detect ASLR on QEMU targets
There is a bug when the `pwndbg.auxv.get()` and `pwndbg.vmmap.get()` caches are not resetted when the binary is restarted. This causes an error when `disable-randomization` is set to off and the binary is restarted.
TL;DR to reproduce:
1. Run `gdb /bin/ls`
2. Invoke `entry`
3. Invoke `set disable-randomization off`
4. Invoke `starti` or `entry`
Or it can be seen here:
```
dc@dc:~$ gdb /bin/ls -q
pwndbg: loaded 195 commands. Type pwndbg [filter] for a list.
pwndbg: created $rebase, $ida gdb functions (can be used with print/break)
Reading symbols from /bin/ls...
(No debugging symbols found in /bin/ls)
pwndbg> set context-sections ''
Sections set to be empty. FYI valid values are: regs, disasm, args, code, stack, backtrace, expressions, ghidra
Set which context sections are displayed (controls order) to ''
pwndbg> entry
Temporary breakpoint 1 at 0x55555555a810
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Temporary breakpoint 1, 0x000055555555a810 in ?? ()
pwndbg> set exception-verbose on
Set whether to print a full stacktrace for exceptions raised in Pwndbg commands to True
pwndbg> set disable-randomization off
pwndbg> starti
Starting program: /usr/bin/ls
Traceback (most recent call last):
File "/home/dc/src/pwndbg/pwndbg/events.py", line 165, in caller
func()
File "/home/dc/src/pwndbg/pwndbg/memoize.py", line 194, in __reset_on_base
base = pwndbg.elf.exe().address if pwndbg.elf.exe() else None
File "/home/dc/src/pwndbg/pwndbg/proc.py", line 71, in wrapper
return func(*a, **kw)
File "/home/dc/src/pwndbg/pwndbg/memoize.py", line 46, in __call__
value = self.func(*args, **kwargs)
File "/home/dc/src/pwndbg/pwndbg/elf.py", line 182, in exe
return load(e)
File "/home/dc/src/pwndbg/pwndbg/elf.py", line 220, in load
return get_ehdr(pointer)[1]
File "/home/dc/src/pwndbg/pwndbg/elf.py", line 241, in get_ehdr
if pwndbg.memory.read(vmmap.start, 4) == b'\x7fELF':
File "/home/dc/src/pwndbg/pwndbg/memory.py", line 40, in read
result = gdb.selected_inferior().read_memory(addr, count)
gdb.MemoryError: Cannot access memory at address 0x555555558000
```
This commit fixes the above problem by making sure those function caches are cleared on binary start.
Before this commit the `pwndbg.elf.get_ehdr(pointer)` function searched for the ELF header by iterating through memory pages (with a step of -4kB) until the ELF magic is found (b'\x7fELF' value).
This was most likely redundant and this commit optimized this logic to look at the begining of the page and if it doesn't have the ELF magic, to look at the first page of the given objfile. Actually, maybe there was one compelling argument to do it this way which is bare metal debugging where we don't have all vmmap info. However! This situation is likely broken anyway, so let's skip doing more work than needed.
Additionally, we refactor the `pwndbg.stack.find_upper_stack_boundary` function to use the `pwndbg.memory.find_upper_boundary` function instead of the `pwndbg.elf.find_elf_magic` function, as the last one was removed in this commit. (NOTE: this actually fixes a potential bug that we could have incorrectly set the upper stack boundary if it contained an ELF magic on the beginning of one of its 4kB pages...)
Disconnect3d
patryk4815
Arusekk
anthraxx
Przemysław Buczkowski
novafacing
Nicky Lim
SecMeant
CptGibbon
Kyle ZENG
cnwangjihe
Daniel Ebert
0x4848
Artur Cygan