Meterpreter has issues with large (> 4GB) files

[timwr]

This has actually been reported before but not on the framework repo:
rapid7/meterpreter#204
rapid7/metasploit-payloads#281

Steps to reproduce

1. Get any meterpreter session (currently python)
2. Create a 4.1 gb file: dd if=/dev/zero of=lol4gb bs=4M count=1025
3. meterpreter > ls in the directory where you created log4gb

Expected behavior

The ls command should complete and return the correct size

Current behavior

meterpreter > ls
[-] stdapi_fs_ls: Operation failed: Unknown error

[01/01/2019 19:58:21] [e(0)] meterpreter: stdapi_fs_ls: Operation failed: Unknown error
[01/01/2019 19:58:21] [d(0)] meterpreter: Call stack:
/metasploit-framework/lib/rex/post/meterpreter/extensions/stdapi/fs/dir.rb:80:in `entries_with_info'
/metasploit-framework/lib/rex/post/meterpreter/ui/console/command_dispatcher/stdapi/fs.rb:629:in `list_path'
/metasploit-framework/lib/rex/post/meterpreter/ui/console/command_dispatcher/stdapi/fs.rb:735:in `cmd_ls'

OS

Linux

[timwr]

I'm going to attempt to fix this because it caught me out trying to ls a Download directory.

Hopefully we can fix this without breaking backwards compatibility with existing stageless meterpreters, (although let me know if that makes it more fiddly than it should be).
We can create a new TLV_TYPE_STAT_BUF with an 8 byte file size, and fall back to the old one if it's not present in a response.

[OJ]

This also impacts files downloads and whatnot, so we'd need to make sure we cover it off across the board. But yes, agreed, need to fix and need to make sure we don't break existing payloads with it!

[fsacer]

actually here is the related issue which was posted before on the main repo #10871