rapid7/meterpreter — pull request #90 by jvazquez-r7 (2014-07-08 17:21:26+00:00)
Title: Return errno when fopen fails on request_fs_file_channel_open

On Windows environments ```request_fs_file_channel_open``` returns the ```GetLastError``` result code when ```fopen``` fails. But, on linux environment, there isn't ```GetLastError```, and ```request_fs_file_channel_open``` fails to return the ```errno``` code. Because of that, the (client) ```PacketDispatcher``` fails to find an error on the response, not handling the error, which ends with unhandled exceptions. It's easy to reproduce by trying to update a file to a nonexisting remote directory on linux meterpreter:

```
[*] Started reverse handler on 172.16.158.1:4444
[*] Starting the payload handler...
[*] Transmitting intermediate stager for over-sized stage...(100 bytes)
[*] Sending stage (1228800 bytes) to 172.16.158.188
[*] Meterpreter session 1 opened (172.16.158.1:4444 -> 172.16.158.188:57584) at 2014-07-08 12:01:01 -0500

meterpreter > upload /tmp/pwned.txt /nonexistent
[*] uploading : /tmp/pwned.txt -> /nonexistent
[-] Error running command upload: NoMethodError undefined method `value' for nil:NilClass
meterpreter >

```

By turning ```errno``` on non-winidows environments, the meterpreter ```PacketDispatcher``` is able to catch the error, and unhandled exceptions not happen anymore:

```
[*] Transmitting intermediate stager for over-sized stage...(100 bytes)
[*] Sending stage (1138688 bytes) to 172.16.158.188
[*] Meterpreter session 1 opened (172.16.158.1:4444 -> 172.16.158.188:57586) at 2014-07-08 12:03:20 -0500

meterpreter >
meterpreter >
meterpreter > upload /tmp/pwned.txt /nonexistent
[*] uploading : /tmp/pwned.txt -> /nonexistent
[-] core_channel_open: Operation failed: 2
```

On the other hand, the linux meterpreter (client) doesn't solve errno codes atm, showing just the error identifier. When handling with windows machines, the meterpreter (client) is able to handle ```GetLastError() ``` codes, showing more user-friendly errors. It's on my TODO, but out of scope change for this pull request, which just tries to solve unhandled exceptions when dealing with ```request_fs_file_channel_open```.