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 "se<TAB>conf" 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 <wireshark-dev@wireshark.org> 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