-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG][PRIORITY] Fix logic bug that deadlocks the server (from TODO) #36
Comments
Development towards fixing this is in fix-deadlock branch. Feel free to join me with suggestions, testing and code :) |
In the current state of the branch the second point (Killing off a perpetual or extremely long execution) has been implemented. Issuing a |
This branch has been abandoned and is lacking some main changes that are in 0.4.0_rc ... The good news is that an alternative solution might be available. Instead of .communicate() we can use a non blocking function of POPEN and poll it periodically (say each 0.1 sec). Will look into implementing this asap. |
When executing a direct command to Client's OS (through the
Execute
command), if the execution of the given command is perpetual the Server deadlocks. Also, even if the execution is not perpetual and just takes a lot of time the user is stuck looking at the blank window and waiting for client response (not being able to focus on another client for example). There is currently no way to send a keyboard interrupt. My current idea is to implement a detach feature (This will solve the long waiting time). For the perpetual execution my current approach is to move the client handling of theExecute
command in a thread and while it's executing wait for aKILL
command from the Server (somewhat like flooding functions are currently handled on the Client side).The reason this is marked as a priority is that a malicious Client can exploit this to deadlock the Server as soon as the later send it an
Exexute
command, effectively forcing the PenTester to restart the Server. It's not marked as severe as the later versions of Clients will automatically try to reconnect upon losing the Server so no Client will be lost.The text was updated successfully, but these errors were encountered: