Re: [gamin] Re: gamin library



On Tue, 27 Jul 2004, Daniel Veillard veillard-at-redhat.com |nautilus| wrote:
...
>   That's not clear to me. the path is only used for a connect() call at the
> library level in gamin_connect_unix_socket() this should not destroy data
> in any way.
>   On the server side the code does the following in gam_listen_unix_socket:
>     if (stat(path, &st) == 0 && S_ISSOCK(st.st_mode)) {
>       ...
>       ret = unlink(path);
>
> so I believe the current code would not override or modify a symlink.
> At worse the given /tmp/fam-<username>- link or resource would get removed
> but certainly not overriden since man 2 unlink states
>
>    "If the name referred to a symbolic link the link is removed."
>
> I don't see a path for data loss so far.
This is a classic race condition so the check is useless. Nothing
prevents an attacker from recreating the link after you remove it, but
before you open it (or only creating it after you check).

In the case of opening normal files, this would be fixed by first opening
the file, then checking the file descriptor (using fstat instead of stat)
so you are sure you are checking the same thing as you are using. I don't
think you can do that with sockets though.
>
> > > > Creating temporary files without unpredictable names is very hard to do
> > > > securely and is the source of many security holes. I don't know the
> > > > semantics of the unix socket system in this regard but I think it is
> > > > not defined what will happen.
>
>   I think in that case trying and checking the code is a good idea,
The behavior is undefined, so for all you can say for sure, it may work
one time and not work the next time.

Even if you have the source and can say for sure that it works now, there
is no guarantee about future releases. Unless you have a crystal ball you
cannot know what would happen. Undefined means: do not rely on this.

Perhaps this might illustrate the issue at hand:

>From Sun's security research results:

http://lists.gnome.org/archives/desktop-devel-list/2004-July/msg00385.html

  - Totem has its own IPC system that is used to send messages from
    the client to the server.  It uses a user writable socket in /tmp.
    This does make the socket vulnerable on systems that do not honor
    file permissions for sockets.  It unfortunately uses a predictable
    file name and does not use a subdirectory of /tmp.  No protection
    against someone else creating a socket with the right name in /tmp
    before it gets set up.  Fortunately this is socket is only used
    for message parsing that does not cause code to get executed.
    However this could be vulnerable to Denial-Of-Service attacks or
    buffer overflow.

Martijn Vernooij




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]