Re: [Wireshark-dev] External processes in Snort dissector - code execution

2017-08-29 Thread Peter Wu 
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

2017-08-29 Thread Jakub Zawadzki 

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

2017-08-28 Thread Martin Mathieson via Wireshark-dev 
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