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
Fix reverse_tcp listener's handling of disconnects before staging #6499
Conversation
I'll take this one on today as I have a case where I can repro. |
Confirmed breakage on master using @bcook-r7's testing technique as well as in $PRODUCTION. Testing fix now. |
From my testing on my local machine, and in $PRODUCTION, this fix doesn't appear to resolve the issue. I'm still unable to connect (both after the intenstive scan or during). I have to restart the handler to get anything to function again. |
Confirmed - it happened to survive on my Mac earlier (YMMV), but broke on Linux at home too. |
You're not my dad! Looks like we shoot ourselves twice - updated with a more robust (and hopefully less noisy on the logs as well) version. |
Testing! |
Wow, you're quick @zeroSteiner, beat me to the label removal! Thanks for the awesome work Brent. Looking good now. |
For the label change, I think we have a web hook to remove those tags automatically; not sure why or how zeroSteiner's avatar shows up there, but I don't think it's correct. I put in a support query to find out. It's part of a trial integration we're testing out to help manage and sort PRs and issues better: https://waffle.io/rapid7/metasploit-framework |
Ah! Waffle.. yup. Nice. |
If we get a tcp disconnect before we finish accepting the socket, the reverse_tcp handler thread breaks out of its internal loop, and we end up with a zombie handler that accepts at the TCP level, but does not actually work any more. Fix #6497
This PR changes the behavior to continue instead. While I was poking around, I also included a commit to tidy up some of the odd ruby style.
Verification