Ethereal-dev: Re: [ethereal-dev] Security race in ethereal leading to root access
> I see now. Don't use the pcap_dump_open() routine, but rather, have
> wiretap receive the callback from pcap_loop, and have wiretap write
> the data to a file. I like that.
Well, I have some code to do that...
...unfortunately, it works only if the process doing the capture is the
same process as the process that calls "mkstemp()" to create the capture
file...
...and that's not the case if you run Ethereal with "-F" or "-S".
One possible fix would be to pass a file descriptor number, rather than
a file name, in the arguments to the instance of Ethereal doing the
capture. This is probably a relatively simple change, but, unless the
ability to write the capture to a specified file descriptor is useful if
you're *not* a child Ethereal run in a "-F" or "-S" capture, it kludges
up the command-line interface a bit, and in any case it kludges up the
implementation a bit.
"-F" and "-S" have some other problems. For one thing, if you put a
syntactically invalid filter expression in the "Capture/Start" dialog
box, you get a *second* Ethereal main window. Forking and execing a new
instance of Ethereal means the new instance, at least with the current
code path, creates its own main window; if it does a normal capture,
that window doesn't pop up, but if it doesn't actually do a capture, it
pops up.
Another fix might be to:
1) fork, but not exec, the child process (so that it has the
file descriptor number handy);
2) do *no* UI work in the child process - instead, have it send
messages up a pipe to the parent, reporting either errors or
counts of packets captured - including the counts of
different subtypes of packets, and have the parent send a
signal to the child when the "Stop" button is pressed,
causing it to stop the capture and exit.
(This is the way "tcpview" does things, although it doesn't send any
packet counts to the parent - which is a bit annoying, as the parent
doesn't display any captured packet counts, so you have no clue whether
your capture has seen any traffic yet.)
That's a bit more work, and requires that we have code to handle the
running-capture dialog box in both the "capture and UI in the same
process" case and the "capture and UI in separate processes" case.
A third possibility would be to use two processes even if you're not
using "-F" or "-S"; this means we wouldn't need two versions of the code
for the running-capture dialog box, *and* it'd probably let us clean up
the capture handling somewhat - we wouldn't have to have the capture
loop handle GTK+ events, we'd just tell GTK+ to add the pipe file
descriptor as an input descriptor, and update the display
(running-capture dialog box and, for "-S", packet display window) when
we got input on that descriptor (the "only update once a second" stuff
would be done by the child process - it'd send messages up to the parent
only when it wanted the parent to update the display).
That has the disadvantage of doing context switches even if you're not
doing a "-S" capture, though.
