Metasploit-framework: Stacktrace for telnet_version

Created on 6 Mar 2017  路  8Comments  路  Source: rapid7/metasploit-framework

Steps to reproduce

resource (external/master.rc)> use auxiliary/scanner/telnet/telnet_version
resource (external/master.rc)> run
[-] 10.0.0.249:23      - Connection reset by peer ["<internal:prelude>:76:in `__read_nonblock'", "<internal:prelude>:76:in `read_nonblock'", "/usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/rex-core-0.1.7/lib/rex/io/stream.rb:72:in `read'", "/usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/rex-core-0.1.7/lib/rex/io/stream.rb:202:in `get_once'", "/usr/share/metasploit-framework/lib/msf/core/exploit/telnet.rb:161:in `recv_telnet'", "/usr/share/metasploit-framework/lib/msf/core/exploit/telnet.rb:147:in `recv'", "/usr/share/metasploit-framework/lib/msf/core/exploit/telnet.rb:126:in `block in connect'", "/usr/lib/ruby/2.3.0/timeout.rb:91:in `block in timeout'", "/usr/lib/ruby/2.3.0/timeout.rb:33:in `block in catch'", "/usr/lib/ruby/2.3.0/timeout.rb:33:in `catch'", "/usr/lib/ruby/2.3.0/timeout.rb:33:in `catch'", "/usr/lib/ruby/2.3.0/timeout.rb:106:in `timeout'", "/usr/share/metasploit-framework/lib/msf/core/exploit/telnet.rb:124:in `connect'", "/usr/share/metasploit-framework/modules/auxiliary/scanner/telnet/telnet_version.rb:36:in `block in run_host'", "/usr/lib/ruby/2.3.0/timeout.rb:91:in `block in timeout'", "/usr/lib/ruby/2.3.0/timeout.rb:33:in `block in catch'", "/usr/lib/ruby/2.3.0/timeout.rb:33:in `catch'", "/usr/lib/ruby/2.3.0/timeout.rb:33:in `catch'", "/usr/lib/ruby/2.3.0/timeout.rb:106:in `timeout'", "/usr/share/metasploit-framework/modules/auxiliary/scanner/telnet/telnet_version.rb:35:in `run_host'", "/usr/share/metasploit-framework/lib/msf/core/auxiliary/scanner.rb:135:in `block (2 levels) in run'", "/usr/share/metasploit-framework/lib/msf/core/thread_manager.rb:100:in `block in spawn'"]
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Metasploit version

v4.14.0-dev

I installed Metasploit with:

Kali package via apt

What OS are you running Metasploit on?
Kali 2016.2 rolling

bug newbie-friendly

Most helpful comment

You said the magic word "I already started!"

Here's the workflow I would use specifically to fix this:

  1. start msfconsole
  2. use auxiliary/scanner/telnet/telnet_version
  3. figure out how to trigger the bug

    • a lot of times, I just point the module RHOSTS at 'nc' listening on the loopback interface

    • e.g. set RHOSTS 127.0.0.1 set RPORT 2121 then run in another terminal nc -lk 127.0.0.1 2121

    • do some bad things - type some garbage, disconnect, etc.

  4. Once you can trigger the bug, type 'edit' from msfconsole - this will open $EDITOR and let you change the module, adding exception handling in this case
  5. Save and exit your text editor.
  6. This will put you back in msfconsole. Now type 'rerun' - msfconsole will reload the module and run it again.
  7. verify thing is fixed. if not GOTO 4
  8. Check out a local branch, commit your fix, push to your branch to your fork, PR
  9. Poke us to review / land, etc.

Easy as pie!

All 8 comments

This should be simple to address - add the appropriate rescue block so the failure is handle more nicely.

Hey, Can you please guide me on how to get started on this one? I am new to open source but would like to work on this. Thanks

Lots of docs available: https://github.com/rapid7/metasploit-framework#contributing - learning is at _least_ half of the fun!

@busterb Thanks mate! I had already started going through those.. I should have checked before posting that first comment... I'll keep my questions specific henceforth :) but can I take this one ? I am setting up the dev environment now.. and looks like I just need to change the exception handling code under
"metasploit-framework/modules/auxiliary/scanner/telnet/telnet_version.rb" , right?

You said the magic word "I already started!"

Here's the workflow I would use specifically to fix this:

  1. start msfconsole
  2. use auxiliary/scanner/telnet/telnet_version
  3. figure out how to trigger the bug

    • a lot of times, I just point the module RHOSTS at 'nc' listening on the loopback interface

    • e.g. set RHOSTS 127.0.0.1 set RPORT 2121 then run in another terminal nc -lk 127.0.0.1 2121

    • do some bad things - type some garbage, disconnect, etc.

  4. Once you can trigger the bug, type 'edit' from msfconsole - this will open $EDITOR and let you change the module, adding exception handling in this case
  5. Save and exit your text editor.
  6. This will put you back in msfconsole. Now type 'rerun' - msfconsole will reload the module and run it again.
  7. verify thing is fixed. if not GOTO 4
  8. Check out a local branch, commit your fix, push to your branch to your fork, PR
  9. Poke us to review / land, etc.

Easy as pie!

@leebaird I am not able to reproduce the issue.. can someone help?

Hmm, I haven't actually seen it yet either yet. I suspect that this stack trace is actually getting caught and formatted oddly here. The trace log message should probably be a vprint_* rather than a print_*

From whatever I tried, I can say that it handles connection termination with proper message and without printing the stack trace... And it seems to be working fine..

Was this page helpful?
0 / 5 - 0 ratings

Related issues

fluit105 picture fluit105  路  3Comments

adrianmihalko picture adrianmihalko  路  3Comments

wvu-r7 picture wvu-r7  路  3Comments

ejholmes picture ejholmes  路  3Comments

miholtz picture miholtz  路  3Comments