Corrupted packet capture files, and a small GUI bug
-
Running an almost-but-not-quite-up-to-date copy of 2.0-RC on an i386, and I was having a lot of trouble opening packet capture files in Wireshark. The captures always run through to completion, I download the .cap files through the webgui, but Wireshark frequently reports "The capture file appears to be damaged or corrupt. (pcap: File has 1885958755-byte packet, bigger than the maximum of 65535)". It seems that the more packets I include in the capture… 500, 1,000, 10,000... the higher the probability of seeing the error.
Out of curiosity, I scp'd /root/packetcapture.cap directly off the router and onto my machine, and surprisingly the file opened without error. After running diff on several broken downloaded files with their scp'd counterparts, I'm pretty sure I know why it's breaking:
Somewhere after the "download the .cap file" code, all instances of the string are being prepended with . Obviously this really only pops up while capturing a lot of HTTP traffic. I'm no expert on the pcap format, but I imagine blindly lengthening fields in a binary file is probably going to make it a little angry.
On a related note, while poking around in /usr/local/www/diag_packet_capture.php, I notice that the "Packet Length" input field is being populated using the value of $snaplen, which is set to 0 at the start of the file and never updated again. $packetlength is the variable that actually comes from $_POST and affects the capture – the two seem like they should be reconciled together.
Oh, and one more thing: Maybe I'm getting a little paranoid here, but isn't it a bit dangerous to take the $detail variable directly from $_POST and feed it into system() without any sort of sanitization? Granted, you'd need to be authenticated with the webgui to exploit it, but it still seems a little wrong.
-
Possibly useful:
It seems that the script line is added via an ob_start() callback function in /usr/local/www/csrf/csrf-magic.php. Apparently it can be disabled by setting $GLOBALS['csrf']['rewrite'] to something that evaluates to false before csrf-magic.php is require_once()'d in /usr/local/www/guiconfig.inc, but I don't know the innards of pfSense well enough to know if that's the correct approach.
-
Try this:
https://github.com/bsdperimeter/pfsense/commit/f257c139312002e38468012137f93eb8230cec38 -
A (very very) quick test seems to indicate the patch fixed the corrupted .cap files. I'll hammer on it some more and see if I can manage to get it to misbehave again. ;)