Fix issue with execution of perl due to gsub not matching across newlines

[marcwickenden]

When using, for example, the cmd/unix/reverse payload, this exploit was not working because the remote host was returning a value for the perl path that included newlines. Example:

/usr/bin/perl
jVUgZjLq
$

The gsub was not matching across newlines and therefore the exploit files written to /var/tmp contained

/usr/bin/perl

$

as the interpreter and failed to run.

The simple fix is to match across newlines with the m modifier. Tested against Ubuntu 8.04 and Exim 4.69.

[jhart-r7]

This seems innocent enough, however I can't reproduce the issue:

irb(main):009:0> buff = `which perl;echo #{token}`
=> "/usr/bin/perl\nadfadf\n"
irb(main):010:0> buff.gsub(token, "").gsub(/\/perl.*/, "/perl").strip
=> "/usr/bin/perl"

[marcwickenden]

The output from my server doesn't look like your example. I get a newline after the token plus a dollar sign, presumably from the underlying bash shell - as in my initial example above. It may be that on different systems this is not what is returned but the m modifier should work in both cases.

[jhart-r7]

Agreed. This should work in both cases.

[jhart-r7]

All I could do for validation on this is confirm the module still loads correctly since my test targets don't reproduce the bug. The gsub is safe.