Guy Harris wrote:
> Note that these changes could, I suspect, allow a process to rename a
> capture file in between the point at which the capturing child process
> creates it and the point at which the parent opens it after being
> given the pathname by the child. This might not be possible on
> Windows, as it doesn't allow renames of open files, but it *is*
> possible on UN*X, and runs the risk that the parent could be tricked
> into reading a file it's not supposed to read.
Hmmm, that sounds *really* strange to me.
We open the capture file with the permission 0600. This means no one
else than the owner can read/write it.
Has someone the possibility to rename a file that belongs only to me???
If yes, I would consider *this* to be a security hole in general!
If no one else than me (well, and root) is able to rename this file,
there's no security problem I see. It's the same as opening any other
capture file that belongs to me.
>
> This might not be an easy exploit
Well, yes.
> - but, a long time ago, the reason why Ethereal was changed to pass a
> file descriptor for the open file to the capturing child process was
> that the OpenBSD folk considered this a hole and "fixed" it in the
> version in the OpenBSD ports database in such a way that broke it.
Unfortunately, the *reason* why this file descriptor was used wasn't
mention anywhere throughout the whole capturing code :-(
While doing redesign, I haven't got a clue what it's all about and
thought that it was a leftover of some other fix a long time ago and
just removed it.
>
> On many UN*Xes, the capture child could pass to the parent a file
> descriptor for the file it opened. However, as far as I know, not
> *all* UN*Xes support this, and the way it's done isn't the same on all
> UN*Xes (on UN*Xes where pipes are implemented as UNIX-domain sockets,
> you'd use the mechanism in UNIX-domain sockets to pass file
> descriptors; on UN*Xes where they're implemented as STREAMS
> connections and you can pass descriptors over STREAMS connections,
> you'd use that mechanism; on other UN*Xes, you might not be able to do
> it).
Why do you think passing the fd isn't possible, as it was in the code
before, just the other way round?
In the former implementation the parent opened the fd and handed it over
to the child. Now the child opens the file and could hand this fd to
it's parent.
We still have the fd in the capture loop (child) and could easily pass
it to the parent. Unfortunately, I don't really know what to do with it
at the parent side.
For the reasons above, I don't think this is a problem here. However,
I'm not a security expert.
Regards, ULFL
