Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
Diactoros127916dIf love it if you would share what you learned here. I’d personally appreciate learning more about a utility I use regularly but understand little.
Root5662516dYes, please share 😊
I have only used cat to display a file’s output or pipe it into another program (cat <file>, or cat <file/script> | <program>).
I know about the function of cat with no files (just using cat standalone) but I never really saw much of a use to it. It basically just sits there, which according to the man, meant that it was reading standard input. I had no real idea why, other than proof of concept?
I am going to butcher the next bit, he tried to dumb it down for me, but not super linux savvy like some:
You can use cat to sustain a pipe that otherwise would close from the execution of a command. For example, if you were to “cat /bin/sh” -> you’d get the contents displayed. However, if you were to cat | /bin/sh, you would open a shell.
@wannabe This has to do with how in linux, everything is a file… including cat. So you effectively do have a file open, the default cat command, which has no end, sustaining a pipe indefinitely. Bash, which is on the other end of the pipe, receives this connection as a child.
This is where I got a bit lost. Apparently in the same sense that everything is a file, everything can also act as a file descriptor? Bash as the child copies the file descriptor of the parent, effectively remaining open and executable.
This was the only way to gain access to a vulnerability in an executable file that briefly opened shell, and prevent system() from closing right after it launched and exiting the program. Basically: (cat <exploit>; cat) | <program>
tldr; cat | /bin/bash opens a shell, and everything is a file.
Like I said, I don't understand it completely, but I'm going to read up a bit more on it tomorrow when I actually get awake. Corrections/assistance are super appreciated :D