ELF.libs broken on wsl1

[152334H]

Update Pwntools First

This issue was tested on both 4.2.1 and the current dev branch.

Debug Output

Linux (Ubuntu 20.04.1 LTS)

$ uname -r
5.4.0-42-generic
$ python3.8 -c 'from pwn import *; context.binary="./pwntools/examples/fmtstr/printf.native";print(context.binary.libs)'
[*] '/home/a/pwntools/examples/fmtstr/printf.native'
    Arch:     amd64-64-little
    RELRO:    Full RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled
{'/home/a/pwntools/examples/fmtstr/printf.native': 94514010189824, '/usr/lib/x86_64-linux-gnu/libc-2.31.so': 140519520264192, '/usr/lib/x86_64-linux-gnu/ld-2.31.so': 140519522349056}

Windows

$ uname -r
4.4.0-17763-Microsoft
$ python3.8 -c 'from pwn import *; context.binary="./pwntools/examples/fmtstr/printf.native";print(context.binary.libs)'
[*] '/mnt/c/Users/A/pwntools/examples/fmtstr/printf.native'
    Arch:     amd64-64-little
    RELRO:    Full RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled
{}

This appears to be a problem with wsl's execution of the shellcode used in _patch_elf_and_read_maps

>>> from pwn import *
>>> context.arch='amd64'
>>> sc = shellcraft.cat('/proc/self/maps')
>>> sc += shellcraft.exit()
>>> run_assembly(sc).recvall()
[*] '/tmp/pwn-asm-4atyhn_g/step3'
    Arch:     amd64-64-little
    RELRO:    No RELRO
    Stack:    No canary found
    NX:       NX disabled
    PIE:      No PIE (0x10000000)
    RWX:      Has RWX segments
[x] Starting local process '/tmp/pwn-asm-4atyhn_g/step3'
[+] Starting local process '/tmp/pwn-asm-4atyhn_g/step3': pid 14220
[x] Receiving all data
[x] Receiving all data: 0B
[*] Process '/tmp/pwn-asm-4atyhn_g/step3' stopped with exit code 0 (pid 14220)
[+] Receiving all data: Done (0B)
b''

gdb debugging seems to indicate that wsl just does nothing when the SYS_sendfile syscall happens.

Misc

My wsl version is somewhat outdated (4.4.0-17763-Microsoft); it is entirely possible that newer versions of wsl are functioning fine.

[Arusekk]

pwntools/pwnlib/shellcraft/templates/i386/linux/cat.asm

Line 23 in 72ca730

${sc.sendfile(fd, 'eax', 0, 0x7fffffff)}

pwntools/pwnlib/shellcraft/templates/amd64/linux/cat.asm

Line 12 in 72ca730

${syscall('SYS_sendfile', fd, 'rax', 0, 0x7fffffff)}

The issue is here that WSL1 (maybe your version) does not support sendfile syscall. You could try examining what is the errno returned by sendfile. (in gdb, p $eax or p $rax after syscall)

[152334H]

Probably a wsl issue then.

---

At syscall:

$rax   : 0x28
$rdx   : 0x0
$rsi   : 0x3
$rdi   : 0x1
$rip   : 0x000000001000003f  →  <_start+63> syscall
$r8    : 0x0
$r9    : 0x0
$r10   : 0x7fffffff

After syscall:

$rax   : 0xffffffffffffffea
$rdx   : 0x0
$rsi   : 0x3
$rdi   : 0x0
$rip   : 0x0000000010000043  →  <_start+67> push 0x3c
$r8    : 0x0
$r9    : 0x0
$r10   : 0x7fffffff
0xffffffffffffffea == -22 == EINVAL (Invalid argument)

Manpage says:

EINVAL Descriptor is not valid or locked, or an mmap(2)-like
              operation is not available for in_fd, or count is negative.
EINVAL out_fd has the O_APPEND flag set.  This is not currently
              supported by sendfile().

Nothing should be wrong with the file descriptor; running SYS_read on fd 3 works as expected.

[Arusekk]

Yeah, try to update your wsl, it may have a broken sendflie, or it may be that wsl1 `seq_file`s (the descriptive files in /proc, here `maps`) do not support mmap-like operations (on native Linux they certainly do since forever)

[Arusekk]

Works?

[152334H]

No idea. It's rather unlikely that I'll get wsl updated anytime soon, I'll reopen if/when it happens.