update and integrate libpcap for POSIX meterpreter

[bcook-r7]

I am working on automating POSIX meterpreter builds, and one step is removing the requirement to download files from external sites during the build process. So, this incorporates the latest stable libpcap source and updates the patches as needed.

The Makefile also moves (@wvu-r7 was amused that Makefile.pcap wasn't actually a pcap file :) and simplifies a little build foo.

I updated and got the 64-bit kernel + 32-bit userspace TPACKET v1 patch merged upstream, but its not in a release yet, so the patch is still needed. See https://github.com/the-tcpdump-group/libpcap/pull/421

Verification steps

• Build a clean POSIX meterpreter (I found not having the tree initially clean, e.g. running 'make distclean' would lead to loader problems) and install it.
• [ ] Fire it up and load the sniffer module
• [ ] Verify that interfaces can be enumerated, packets captured and downloaded

Here is a session that I tested with:

msf exploit(handler) > run

[*] Started reverse handler on 192.168.56.1:4444
[*] Starting the payload handler...
[*] Transmitting intermediate stager for over-sized stage...(100 bytes)
[*] Sending stage (1253376 bytes) to 192.168.56.1
[*] Meterpreter session 1 opened (192.168.56.1:4444 -> 192.168.56.1:50766) at 2015-02-25 17:55:04 -0600

meterpreter > load sniffer
Loading extension sniffer...success.
meterpreter > sniffer_
sniffer_dump        sniffer_interfaces  sniffer_release     sniffer_start       sniffer_stats       sniffer_stop
meterpreter > sniffer_interfaces

1 - 'eth0' ( type:0 mtu:1514 usable:false dhcp:false wifi:false )
2 - 'any' ( type:0 mtu:1514 usable:false dhcp:false wifi:false )
3 - 'lo' ( type:0 mtu:1514 usable:false dhcp:false wifi:false )

meterpreter > sniffer_start 1
[*] Capture started on interface 1 (50000 packet buffer)
meterpreter > sniffer_stop 1
[*] Capture stopped on interface 1
[*] There are 54 packets (4364 bytes) remaining
[*] Download or release them using 'sniffer_dump' or 'sniffer_release'
meterpreter > sniffer_
sniffer_dump        sniffer_interfaces  sniffer_release     sniffer_start       sniffer_stats       sniffer_stop
meterpreter > sniffer_dump 1 test.pcap
[*] Flushing packet capture buffer for interface 1...
[*] Flushed 54 packets (5444 bytes)
[*] Downloaded 100% (5444/5444)...
[*] Download completed, converting to PCAP...
[*] PCAP file written to test.pcap
meterpreter > meterpreter > exit
[*] Shutting down Meterpreter...

[OJ]

Is it worth considering using subrepos for the libpcap stuff?

[metasploit-public-bot]

Test PASSED. Refer to this link for build results (access rights to CI server needed): https://ci.metasploit.com//job/GPR-MeterpreterWin/150/ Test PASSED.

[bcook-r7]

If we're storing the tarballs in the subrepo, sure! I hesitated for this because this tarball is actually smaller than other blobs we already have checked in, e.g. the static windows openssl libs.

Automake/conf projects do not fare well being built straight from a git checkout (libpcap especially since they check in generated files) due to timestamp being semi-unpredictable. This will cause random failures in continuous integration systems when the git repo checkout crosses a second threshold at just the wrong moment. Can you tell I've debugged this problem before :) ?

But, a meterpreter-deps submodule would be a good idea! We could move the checked-in Windows .libs and random support executables there as well. Then when we're ready to do the final squash of the sources, it won't have to have any old binaries in it at all in the history.

[OJ]

This sounds relatively sane! I approve :)

[bcook-r7]

I'm still in the process of getting that new repo up, had to learn the right people to poke to get the privileges right. Should hopefully have it tomorrow.

[metasploit-public-bot]

Test PASSED. Refer to this link for build results (access rights to CI server needed): https://ci.metasploit.com//job/GPR-MeterpreterWin/151/ Test PASSED.

[bcook-r7]

Hopefully its still relatively sane :) The initial 'dependency' repo is at https://github.com/rapid7/meterpreter-deps.

There is a sneaky openssl update here just to unbreak the build temporarily, since the openssl mirrors seem to have rearranged themselves over the weekend. My plan is to send a separate SSL library update tomorrow, maybe this can go in after?

[bcook-r7]

Closing this for a more general 'update libs' PR. Its currently not possible to test libpcap update in isolation with a libssl update.