Re: [patch 7/8] fdmap v2 - implement sys_socket2

From: Ulrich Drepper
Date: Fri Jun 08 2007 - 22:11:27 EST

Hash: SHA1

Al Viro wrote:
> Any real-world examples of exploitable holes based on that?

Return to libc exploit, calling dup2, where some privileged data is
redirected from the normal file descriptor to one of the attackers
choosing. The latter could be an outgoing socket connection which would
result in leaking the data to the outside.

normal code intruder

so = socket()

fd = open ("local-file")

dup2(so, fd);

write (fd, privileged data)

It's just a little function call. If the arguments of dup2() are known
this is not a big issue to construct.

>> You're confusing the problems.
> No, I'm not. The entire argument for having a separate set of descriptors
> is based on programs behaving in similar fashion, working correctly now but
> limiting what libraries can do with opening files for internal needs.

It's completely different.

The reason why runtime libraries cannot keep descriptors open unless it
is explicitly part of the API (e.g., opendir) is that POSIX and Unix
forever guarantee that descriptors are allocated sequentially. Linus
already showed a code sequence:

.. something else ..
if (open("myfile", O_RDONLY) < 0)

This occurs in the real world and it is guaranteed to work.

- --
â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â
Version: GnuPG v1.4.7 (GNU/Linux)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at