IO plugins for libpcap

[raybellis]

This replaces #578 which I messed up when performing a second rebase.

With this patch deployed, libpcap checks the environment variables PCAP_IOPLUGIN_READ and PCAP_IOPLUGIN_WRITE for dynamically-loadable plugins that replace the file I/O routines, e.g. for automatic decompression or compression of pcap files.

Plugins use fopencookie or funopen (O/S dependent) to create a virtual FILE* handle which is then returned to existing libpcap functions. A sample plugin with gzip support is at https://github.com/raybellis/libpcap-gzip

If the plugin is not found or does not initialise properly the system falls back to generic stdio-based functions that are provided in pcap-ioplugin.c and which now handle the use of - to indicate stdin or stdout there instead of in savefile.c (simplifying the code in the latter).

[mcr]

Ray Bellis <notifications@github.com> wrote: With this patch deployed, `libpcap` checks the environment variables `PCAP_IOPLUGIN_READ` and `PCAP_IOPLUGIN_WRITE` for dynamically-loadable plugins that replace the file I/O routines, e.g. for automatic decompression or compression of pcap files. I'm really anxious about this! libpcap gets embedded in other code bases, which might be setuid, etc. I know that I said that we didn't want to create new dependancies, but I'm not sure that this is a better. Plugins use `fopencookie` or `funopen` (O/S dependent) to create a virtual `FILE*` handle which is then returned to existing `libpcap` functions. A sample plugin with gzip support is at https://github.com/raybellis/libpcap-gzip If the plugin is not found or does not initialise properly the system falls back to generic `stdio`-based functions that are provided in `pcap-ioplugin.c` and which now handle the use of `-` to indicate `stdin` or `stdout` there instead of in `savefile.c` (simplifying the code in the latter).

[raybellis]

With the plugin model in this (much) later version of the patch the dependencies end up in the plugin, not the main library, so (for example) libpcap-plugin-gzip.rpm could be the package that pulls in the zlib dependency.

(this differs from my first attempt at this where I didn't use dynamically loadable modules and just hooked zlib into the main library).

The setuid concern is valid, though, and we should certainly talk about that further. Would it be sufficient (and appropriate) to disable the mechanism if getuid() != geteuid() ?

[guyharris]

The setuid concern is valid, though, and we should certainly talk about that further. Would it be sufficient (and appropriate) to disable the mechanism if getuid() != geteuid() ?

Ideally, it should be disabled if the program is running with special privileges or was started with them, has relinquished them, but could reclaim them, or was started with them but relinquished them in favor of privileges other than those of the user running the program.

OpenBSD introduced an issetugid() call that indicates whether "the process was made setuid or setgid as the result of the last or other previous execve() system calls". Somebody's complained that other OSes that have picked it up have changed it so in ways that are inappropriate; from a quick read of his document, I infer that it would mean we'd disallow plugins when not necessary on those OSes.

That document also mentions another mechanism that Linux provides.

[mcr]

Ray Bellis <notifications@github.com> wrote: The `setuid` concern is valid, though, and we should certainly talk about that further. I think that the central issue is the environment variables. The plus is that you can pass the variables down through pretty much any user of libpcap. The downside... is the same thing :-) 1) First thing I can see, if that libpcap is told about the name of the plugin, but not the path, and that it loads the plugin only from a configured directory. This is not so good for self-builds, and still provides a possible avenue to attack a setuid binary (or at binary with a Linux capability set!!!) 2) Second thing I can think of is that it's not done with an environment variable. So a new pcap library call to load the plugin. This has the downside that it's not transparent to the application, but in many ways that's the goal: make sure the application is ready for this. 3) Third thing I can think of, is that libpcap has a map (internal or maybe in /etc) of file extensions to plugins, and when the savefile matches, then it dlopens. I prefer internal list initially. In many ways, this is the same as (1) and environment variables, as the file name is controllable by an attacker.

[mcr]

Replaced with #914.