Re: [Wireshark-dev] External processes in Snort dissector - code execution
On Tue, Aug 29, 2017 at 10:13:04AM +0200, Jakub Zawadzki wrote: > Hi Peter, > > W dniu 2017-08-28 18:50, Peter Wu napisał(a): > > This can especially problematic for services like Cloudshark and > > Webshark (by Jakub). The former is not yet affected since it does not > > use 2.4 code (yet?) but the latter seems theoretically vulnerable as it > > has a setconf API function (I was not able to get it to work though as > > setconf changes are not visible in dumpconf). > > dumpconf now support dumping value of snort.binary > (https://code.wireshark.org/review/23268/), What I meant was that changing a pref like (say) zebra.tcp.port via setconf does not show up in the next dumpcinf command. Today it suddenly works, maybe I was not looking correctly or mistyped the parameter name. > and sharkd setconf requested is blocked from webshark API > (https://bitbucket.org/jwzawadzki/webshark/commits/2687eec6b0413462e072a660af96896ee7cd6c33). I was able to set snort.binary and snort.config anyway (but it seems that your sharkd is built from an older source without these fixes) so it did not show up. For snort.alerts_source it takes some special treatment (use name instead of description), but then it can be changed too. The final roadblock which prevented successful exploitation is that the only entrypoint to open a new file (and trigger the init routine "snort_start") is throug htle "load" command. If you were wondering how to bypass the setconf filter: 1. Use "req=se%09conf" in the URL 2. Which gets interpreted as "seconf" in Python 3. Which is JSON-encoded as "se\tconf" (see ESCAPE_DCT in /usr/lib/python*/json/encoder.py for the mappings) 4. The stub json_unescape_str in sharkd_session.c strips all backslashes, so the original command is interpreted as "setconf" ...which is another lesson that canonicalization should be done well. Maybe you should just check the command for alpha(numeric) characters and reject all others? By the way, the original issue is still open, Snort can execute arbitrary commands when configured. I'm not entirely sure how to handle this nicely... IMO a dissector should not execute external processes. Would it be feasible to split this functionality into a C or Lua plugin? -- Kind regards, Peter Wu https://lekensteyn.nl ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] External processes in Snort dissector - code execution
Hi Peter, W dniu 2017-08-28 18:50, Peter Wu napisał(a): This can especially problematic for services like Cloudshark and Webshark (by Jakub). The former is not yet affected since it does not use 2.4 code (yet?) but the latter seems theoretically vulnerable as it has a setconf API function (I was not able to get it to work though as setconf changes are not visible in dumpconf). dumpconf now support dumping value of snort.binary (https://code.wireshark.org/review/23268/), and sharkd setconf requested is blocked from webshark API (https://bitbucket.org/jwzawadzki/webshark/commits/2687eec6b0413462e072a660af96896ee7cd6c33). Thanks, Jakub. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] External processes in Snort dissector - code execution
Hi Peter, I had not really thought about someone doing this. I have at times had multiple versions of snort installed in the same VM and used the option to switch between them... Its not a solution really, but I had thought I ought to run the snort binary with -V and check that it got a plausible version number back (the problem is that there is no way I can think of to report this (or any other) error back to the user - apart from something like adding expert info to every frame in the capture). Of course an otherwise arbitrary script could be written to respond to -V.. I would have no issue with a run-time environment variable being used to block the dissector (or at least the "From running Snort" option). Or even a build flag - it would be a shame if it had to be disabled by default but I could understand if this was necessary. Martin On Mon, Aug 28, 2017 at 5:50 PM, Peter Wu wrote: > Hi Martin and others, > > I have noticed that the snort dissector (added in Wireshark 2.4) can be > configured to execute external processes, is this desirable? > > When a new pcap is loaded (or when a live capture starts), it will > execute the following init routine: > > static void snort_start(void) > { > GIOChannel *channel; > /* int snort_output_id; */ > const gchar *argv[] = { > pref_snort_binary_filename, "-c", pref_snort_config_filename, > /* read from stdin */ > "-r", "-", > /* don't log */ > "-N", > /* output to console and silence snort */ > "-A", "console", "-q", > /* normalize time */ > "-y", /* -U", */ > NULL > }; > > If one is able to set pref_snort_binary_filename=/bin/sh and > pref_snort_config_filename to an arbitrary string, one can execute > arbitrary shell code. Proof of concept that creates an infinite loop: > > strace -e execve -f \ > tshark -osnort.alerts_source:"From running Snort" \ > -osnort.binary:/bin/sh \ > -osnort.config:'while :;do :;done' > > (After killing tshark, don't forget to kill the shell process, e.g. > identify PID with "ps u -C sh" then kill it.) > > This can especially problematic for services like Cloudshark and > Webshark (by Jakub). The former is not yet affected since it does not > use 2.4 code (yet?) but the latter seems theoretically vulnerable as it > has a setconf API function (I was not able to get it to work though as > setconf changes are not visible in dumpconf). > > Another problem occurs when Wireshark profiles are shared, one might > expect "just" configuration of a custom port or color filters, but to a > lesser extent expect arbitrary code execution. (These are preferences, > not plugins.) > > Perhaps the snort dissector should be configured through an environment > variable, or require other changes to work? > -- > Kind regards, > Peter Wu > https://lekensteyn.nl > ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe