[Martin Mathieson <martin.r.mathieson@xxxxxxxxxxxxxx>]

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 <peter@xxxxxxxxxxxxx> 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