4

I understand that /bin/sh is a shell that executes commands I have typed. But the thing is that although I don't type /bin/sh, I can type any command I want.

I heard that when a cracker wants to attack someone, he or she usually wants to get /bin/sh. In particular, I have heard /bin/sh mentioned in conjunction with buffer overflows and remote shells, and that crackers can exploit programs using malicious code executing by /bin/sh such as exec ("bin/sh", ~something, something);.

I am curious about why he or she tries to "get" /bin/sh or execute it.

I am also not sure about the difference between just typing a command and typing the same command after executing /bin/sh, like seen in this terminal interaction:

johndoe@localhost $ pwd
/home/johndoe
johndoe@localhost $ /bin/sh
sh-3.2 $ pwd
/home/johndoe
sh-3.2 $ whoami
johndoe
sh-3.2 $

Although I do not execute /bin/sh, I can still type any command I want to type. So why and when would crackers want to use /bin/sh?

ArjunShankar
  • 23,020
  • 5
  • 61
  • 83
user3628636
  • 177
  • 1
  • 3
  • 8

3 Answers3

2

When you login, you are given a shell. It may be /bin/bash, or /bin/sh, or (sadly) /bin/csh, so you can type commands into that shell. If you invoke /bin/sh, you are not gaining much: you're just getting a new shell. The reason a cracker wants to execute /bin/sh is that they may not be in a shell initially. They may be running some program that is supposed to limit their ability to invoke commands, so getting /bin/sh is a huge gain. Frankly, the cracker doesn't care if they get /bin/sh or /bin/bash or even /bin/csh: the point is to get a root level shell so they can execute arbitrary commands. If they are able to make a setuid program spawn a shell, they gain root on the box. (That is, if they run a command like eject that is running as root when they trick it into spawning a shell, the shell they get has root privileges.)

William Pursell
  • 204,365
  • 48
  • 270
  • 300
2

First, about the difference between executing a command on your shell, and executing it after invoking /bin/sh (essentially no significant difference, but I'll elaborate):

When you open up a terminal on your local machine, you see a window and a prompt. The window is a terminal program, and inside it there is already a shell running. From the shell interaction you pasted in your question, it looks like your default shell is /bin/bash.

Simplistically speaking, whenever you type a command into the shell it executes it using a combination of fork and exec. So, when you type /bin/sh, your shell simply executes it the same way. i.e. one shell executes another shell. Inside that shell, you execute more commands. Nothing particularly different. It is another instance of the shell doing the same thing the previous instance was doing.

A shell isn't particularly special to you when you are already logged into a computer and sitting at it typing away. It is just another program after all. But it is a program that can conveniently execute other programs. This is why you are using it. But this very property makes it interesting to crackers because they want to conveniently execute programs on others computers. But we'll come to that in a bit. Just remember this though: A shell is a program that can conveniently execute other programs.

Now on to why crackers are interested in getting shells:

A shell is not the only program that can call exec (start executing another program). Any program can do it. A shell is, of course, the most convenient way to do so. Unfortunately for a would-be cracker, computers don't offer a shell unless they have physical access to it. The only interface they have to a computer is through public services run by that computer. e.g. a web server serving pages does indeed take input from external computers and produces output for them. In the process, the web server reads files on the server, does a bunch of other stuff, and then sends some bytes over the wire. It doesn't exec anything (or even if it does, there is no way for the attacker to directly control what it execs). i.e. you don't know what Google's web server does internally when you see their web page. You just send a query, and see the result in your browser. But if a cracker somehow tricks a web server to exec a shell program (say /bin/sh, or any of its relatives), and pass input to it, then the attacker can run any program they subsequently want on that server. And if that publicly exposed service is running as root: even better. This is what an attacker is interested in doing. Because it is a way to move towards convenient control of a system.

ArjunShankar
  • 23,020
  • 5
  • 61
  • 83
-1

When you type /bin/sh all you are doing is changing your shell to /bin/sh. If you are executing code, it will make no difference.

Paul Frederiksen
  • 384
  • 2
  • 8
  • 1
    The difference is in which shell is currently running. They support slightly different things so what you can do with them is slightly different. `/bin/sh` for example does not support process substitution so `cat < <(echo foo)` will be an error instead of outputting `foo` as it would with bash. – Etan Reisner Apr 23 '15 at 15:26
  • Sure, but in his example, running things like `whoami` and `pwd` aren't going to make any difference in execution. It also won't make any difference in compiled code. There are definitely benefits of **not** using `/bin/sh`. Even if you use `/bin/sh`, if your shell scripts specify a language to use `#!/bin/bash` for example, it'll still use bash. – Paul Frederiksen Apr 23 '15 at 15:28
  • Depends on how you run it, but yes. And yes, my point was not that you were mistaken but rather to add nuance to the answer since it does differ in some ways. – Etan Reisner Apr 23 '15 at 15:36