Skip to content
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

MSFCONSOLE -X Multiple Instance Failure #4549

Closed
T-S-A opened this issue Jan 7, 2015 · 8 comments · Fixed by #4615
Closed

MSFCONSOLE -X Multiple Instance Failure #4549

T-S-A opened this issue Jan 7, 2015 · 8 comments · Fixed by #4615
Assignees

Comments

@T-S-A
Copy link

T-S-A commented Jan 7, 2015

Due to msfcli going away soon, I've started upgrading automation code to use msfconsole -x. This new method has a serious issue that needs to be overcome.

For example, if you run msfconsole -x "use auxiliary/scanner/snmp/snmp_login;set rhosts 127.0.0.1;run;exit -y;" by itself, the msfconsole loads and runs the module fine, but if you try to run that same command three times, causing multiple msfconsole instances to load at the same time, msfconsole will start throwing errors like, "[-] Failed to load module: auxiliary/scanner/snmp/snmp_login" and "[-] Unknown command: run."

With msfcli, I could run 10+ instances at the same time with no problems, but with msfconsole -x, trying to run a few instances at the same time causes serious issues which results in most of the instances failing.

Thanks!

@wchen-r7 wchen-r7 added the bug label Jan 8, 2015
@todb-r7
Copy link

todb-r7 commented Jan 8, 2015

I bet you're hitting #4340. That needs to be resolved before fulling kicking out msfcli, and the sooner the better.

Try this, drop a sleep 3; use auxiliary... in the -x and see if that resolves. msfconsole loads significantly faster than msfcli so there's a race in there on module indexing.

@todb-r7
Copy link

todb-r7 commented Jan 8, 2015

If the sleep trick works this is a dupe of #4340 for sure. It's a lame workaround, but I'll close this as a dupe of that if you confirm, @T-S-A .

@todb-r7 todb-r7 self-assigned this Jan 8, 2015
@T-S-A
Copy link
Author

T-S-A commented Jan 8, 2015

It seems that your recommendation fixed it. I can run multiple instances of the command below without experiencing the issues mentioned previously. Thanks!

msfconsole -x "sleep 3;use auxiliary/scanner/snmp/snmp_login;set rhosts 127.0.0.1;run;exit -y;"

@todb-r7
Copy link

todb-r7 commented Jan 20, 2015

Okay. I'm going to drop a temp fix in for -x that always drops a leading sleep in there. It's lame but it works until the module counting/indexing/caching is solid.

@todb-r7
Copy link

todb-r7 commented Jan 20, 2015

Hah, this is more complicated than expected. I'm trying to induce the behavior, and it's stubbornly avoiding it. I will get into periods where all the modules load fine, then not, then again, and I'm not seeing any obvious differences in framework.log after some instrumentation. It's very streaky and is starting to feel like a Baccarat game.

@todb-r7
Copy link

todb-r7 commented Jan 20, 2015

For example, no changes between runs:

todb@mazikeen:~/git/rapid7/metasploit-framework$ ./msfconsole -Lqx "use auxiliary/test/slow_module;exit"
[-] Failed to load module: auxiliary/test/slow_module
[ruby-2.1.5@metasploit-framework](temp) 
todb@mazikeen:~/git/rapid7/metasploit-framework$ ./msfconsole -Lqx "use auxiliary/test/slow_module;exit"
[ruby-2.1.5@metasploit-framework](temp) 
todb@mazikeen:~/git/rapid7/metasploit-framework$

I'm going to wrap cmd_use with a try-again, I believe.

todb-r7 pushed a commit to todb-r7/metasploit-framework that referenced this issue Jan 20, 2015
This is a weak attempt to solve a race condition between modules loading
and cmd_use being fired. Upon startup, saved configurations, running
resource scripts, and running commands will sometimes jump ahead of the
module loading procedure.

I have not discovered where the race actually is and how to cause the
race to happen. However, the timing seems to be fairly close to a second;
by waiting three seconds after trying use again, we seem to be in the
clear, at least according to testing.

Fixes rapid7#4549, but better solutions are welcome!
@todb-r7
Copy link

todb-r7 commented Jan 20, 2015

Hey @T-S-A I have a fix up that seems effective. Hopefully @wvu or @kernelsmith or someone will test and land, or see that the fix is kinda silly and complain about it. :)

@T-S-A
Copy link
Author

T-S-A commented Jan 20, 2015

Thanks!

@wvu wvu closed this as completed in #4615 Jan 21, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants