file? method from Msf::Post::File module returns "false" with a big file

[BorjaMerino]

Steps to reproduce

How'd you do it?

1. Gain a meterpreter on a Windows machine with a windows/meterpreter/reverse_tcp
2. Try to check if a big file (for instance 5 GB) exists by using the file? method from Msf::Post::File

Tested on a Windows 10 Pro 64 bits.

Expected behavior

It should return true

Current behavior

Returns false

Metasploit version

metasploit v4.13.21-dev-cba5e26

OS

Running Metasploit from a Debian 8 (Linux 3.16.0-4-amd64) x86-64

[bwatters-r7]

This is bug in windows meterpreter, as we use _wstat in metasploit-payloads/c/meterpreter/source/extensions/stdapi/server/fs/fs_win.c

Switching to _wstat64 should solve the problem, but it looks like we dump the output into a custom structure, and we'll need to make sure that the meterp_stat struct will handle any changes in output.

[bwatters-r7]

Testing:

meterpreter > ls
Listing: C:\Users\bwatters\Downloads
====================================

Mode              Size     Type  Last modified              Name
----              ----     ----  -------------              ----
0000/---------    346      fif   1969-12-31 18:00:00 -0600  English_2012.7z
100666/rw-rw-rw-  0        fil   2017-04-06 11:10:44 -0500  crap.txt
100666/rw-rw-rw-  282      fil   2017-03-15 08:36:03 -0500  desktop.ini
100777/rwxrwxrwx  1312376  fil   2017-02-24 16:24:23 -0600  python-3.6.0-amd64-webinstall.exe

meterpreter > background
[*] Backgrounding session 1...
msf exploit(handler) > use exploit/windows/local/example 
msf exploit(example) > run

[*] LOOKING FOR C:\Users\bwatters\Downloads\English_2012.7z
[-] DID NOT FIND IT
[*] LOOKING FOR C:\Users\bwatters\Downloads\crap.txt
[+] FOUND IT
msf exploit(example) > 

Code for anyone curious:

	print_status('LOOKING FOR C:\Users\bwatters\Downloads\English_2012.7z')
	if file?('C:\Users\bwatters\Downloads\English_2012.7z')
		print_good('FOUND IT')
	else
		print_error("DID NOT FIND IT")
	end
	print_status('LOOKING FOR C:\Users\bwatters\Downloads\crap.txt')
	if file?('C:\Users\bwatters\Downloads\crap.txt')
		print_good('FOUND IT')
	else
		print_error("DID NOT FIND IT")
	end

Also of note:

There is an inconsistent reporting between x64 and x86 meterpreters:
x64 meterpreter:

meterpreter > ls
Listing: C:\Users\bwatters\Downloads
====================================

Mode              Size     Type  Last modified              Name
----              ----     ----  -------------              ----
0000/---------    346      fif   1969-12-31 18:00:00 -0600  English_2012.7z

x86 meterpreter:

 meterpreter > ls
Listing: C:\Users\bwatters\Downloads
====================================

Mode              Size     Type  Last modified              Name
----              ----     ----  -------------              ----
1215/-w---xr-x    7208072  fif   1969-12-31 18:00:00 -0600  English_2012.7z

[bwatters-r7]

FYI, the payloads portion was an easy fix. I have a patched payload running on my dev machine that finds large files as expected, but it breaks framework's file size (because it now reports them in 64 bits, like it should). Working through the TLV parsing in framework now to figure out that fix.

[busterb]

If you fix the sizes, would recommend fixing the uid/gid fields to be 32-bit too.

st_ino is also way too small to be useful, but I also can't find anything in tree that uses it. It might make sense to drop it and pad too.

[busterb]

I'd kind of recommend creating a new stat64 command and have msf use it if it exists, or use normal stat if it doesn't. That way we don't break payloads in the field, and you don't have to fix all the payloads simultaneously (you can stagger a bit). Just take advantage of the command auto-detection we do in stdapi, all meterpreters should support command enumeration now.

[bwatters-r7]

@busterb that's a much better plan than I had, consider it stolen adopted.

[github-actions]

Hi!

This issue has been left open with no activity for a while now.

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.