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 <[email protected]> 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 <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
