Metasploit-framework: Exploit/multi/handler output strange

[cacaocaca]

Steps to reproduce

Error Output when press enter on exploit/multi/handler the meterpreter session work right but i would like know what depend this error .
https://youtu.be/L9nQeqkwNhM
This section should also tell us any relevant information about the
environment; for example, if an exploit that used to work is failing,
tell us the victim operating system and service versions.

Expected behavior

What should happen?

Current behavior

What happens instead?

You might also want to check the last ~1k lines of
/opt/metasploit/apps/pro/engine/config/logs/framework.log or
~/.msf4/logs/framework.log for relevant stack traces

System stuff

Linux kali 4.8.0-kali1-686-pae #1 SMP Debian 4.8.5-1kali1 (2016-11-04) i686 GNU/Linux

Metasploit version

metasploit v4.13.0-dev

Get this with the version command in msfconsole (or git log -1 --pretty=oneline for a source install).

I installed Metasploit with:

• [X ] Kali package via apt
• [ ] Omnibus installer (nightly)
• [ ] Commercial/Community installer (from http://www.rapid7.com/products/metasploit/download.jsp)
• [ ] Source install (please specify ruby version)

OS

Linux kali 4.8.0-kali1-686-pae #1 SMP Debian 4.8.5-1kali1 (2016-11-04) i686 GNU/Linux

What OS are you running Metasploit on?

Linux kali 4.8.0-kali1-686-pae #1 SMP Debian 4.8.5-1kali1 (2016-11-04) i686 GNU/Linux

[pbarry-r7]

I tried this out earlier on my setup (Ubuntu 16.04 VM running MSF off master), didn't see the same behavior. This evening we've had a second report of this behavior on MSF version v4.13.1-dev-5fdd5a7. My money would be on the recent ANSI escape sequences we've landed, but only a thought at this moment...

[bcook-r7]

Could be related to language. What does echo $LANG say?

[pbarry-r7]

I had wondered the same, @bcook-r7, but it sounds like two other folks who I believe would have LANG settings similar to mine have also bumped into it (Tim and OJ). But I'm no ANSI escape expert or anything... ;)

[pbarry-r7]

Sorry, I'm not trying to muddy the water here with any assumptions on my part (dangerous!). @cacaocaca, could you share what $LANG is set to in your environment? Here's mine:

$ echo $LANG
en_US.UTF-8

[OJ]

$ echo $LANG
en_AU.UTF-8

And this is what I'm seeing quite often in my console:

[bcook-r7]

Easy to see in gnome-terminal (or Kali's default setting). It definitely doesn't like the new escape sequences.

[pbarry-r7]

Oof...

[cacaocaca]

http://imgur.com/a/Yq48s

[OJ]

This looks exactly like what we were discussing on IRC yesterday.

[cacaocaca]

How can i solve it ?

[vvalien]

I am also seeing this, thought it was a issue with my install.

It's most likely a issue with the latest update to rex-text/lib/rex/text/unicode.rb

A little more info shows its injecting \x01\x02 which has to do with pre_color \ post_color as those are set to \x01 and \x02 respectively.

[pbarry-r7]

I was able to repro in Kali (I pulled the latest ISO and updated the metasploit-framework package), but only if I gave the -L argument when starting the console (e.g. msfconsole -L) to use the system Readline Library. If do that, I see the exact same behavior others are bumping into.

If I revert the recent "nicer async output" PR from the framework code in my Kali instance, then I no longer see the unexpected characters.

[OJ]

+1 to this. Same story on my home machine.

I do see the issue in async cases, it's fine in sync.

[bcook-r7]

I have a fix for this. I can land it with the windows fix PR #7596

[bcook-r7]

Fixed by 34aa79ca27211b06678e0aaf22f78a1b32ae5387 - let me know if you encounter any other issues.

CC @dmaloney-r7 - we need to make sure we at least check out future console behavior changes on Linux too 🎱

[thelightcosine]

@bcook-r7 I actually did test this on linux, with and without Readline and it worked as expected, not sure what the difference in environments was

[busterb]

Cool, what terminal emulator did you use? I tried xterm, gnome-terminal on Kali, Ubuntu, and Debian. Same bug on all of them.

Did you instead ssh to a Linux box from a Mac? That might not have shown the problem since it had to do with what characters the terminal emulator displayed, not the literal underlying OS (if that makes sense :)