Take a look at this..
http://www.reversing.org/node/view/5

approach to passive fingerprint of debuggers and tracers

I noticed this problem a few months ago while trying to develop a shellcode that called stat() on a hardcoded descriptor (fd=4). It really took me a while to resolve this problem

Anywayz, I guess you can use env_audit to find out what exactly these descriptors are used for.

Cheers
./hk

Using the program from here, which shows all the information read or written on a fd for that particular program:
http://www.dgp.toronto.edu/~ajr/209/a3/readall.c

I did:
gdbserver TCP4-LISTEN:5000 fdwatch
(fdwatch is the compiled readall.c program)

Then on the same machine:
shell> gdb fdwatch
GNU gdb 6.8-debian
This GDB was configured as “i486-linux-gnu”…
(gdb) target remote localhost:5000
Remote debugging using localhost:5000
[New Thread 21850]
0xb7f79810 in ?? () from /lib/ld-linux.so.2
(gdb) run
The program being debugged has been started already.Start it from the beginning? (y or n) y
Starting program: /home/hinmanm/fdwatch
file descriptor 0 seems to be open
file descriptor 1 seems to be open(I’ll assume it’s open for write, rather than read)
file descriptor 2 seems to be open(I’ll assume it’s open for write, rather than read)
file descriptor 3 seems to be open
file descriptor 4 seems to be open
file descriptor 5 seems to be open
fd 5 says: ild-tree/i386-libc/csu/crti.S00/build/buildd/glibc-2.7/build-tree/glibc
fd 5 says: -2.7/csu00GNU AS 2.18.00001\37777777600\377777776110000000200]0000000401\37777777655000000 000000/build/buildd/glibc-2.7/bfd 5 says: uild-tree/i386-libc/csu/crtn.S00/build/buildd/glibc-2.7/build-tree/glib
… etc etc etc etc for quite a bit …

Perhaps the other file descriptors are being used for remote debugging as well as fd 5?

Suppose I could start lookging through the source

total 0
lrwx—— 1 hinmanm hinmanm 64 2008-05-29 09:44 0 -> /dev/pts/2
lrwx—— 1 hinmanm hinmanm 64 2008-05-29 09:44 1 -> /dev/pts/2
lrwx—— 1 hinmanm hinmanm 64 2008-05-29 09:44 2 -> /dev/pts/2
lr-x—— 1 hinmanm hinmanm 64 2008-05-29 09:44 3 -> pipe:[21982]
l-wx—— 1 hinmanm hinmanm 64 2008-05-29 09:44 4 -> pipe:[21982]

I suppose it is because fd 3 doesn’t have write permission. Still, I’m really interested in what you can do with these pipes.

This bug is in my testing of Fedora Linux 8, and also Debian etch.

gdb version 6.6-45.fc8rh
gdb version 6.4.90-debian

$ cd /tmp
$ cat test.c
int
main(int argc, char *argv[])
{
int ret;
ret = write(atoi(argv[1]), “hi”, sizeof(“hi”));
printf(“ret %i\n”, ret);
}
$ gcc test.c
$ gdb a.out
> run 4
ret 3

> break main
> run 4
^Z
$ ps a|grep gdb|grep -v grep
28798 tty1 S+ 0:00 gdb a.out
$ ls -la /proc/28799/fd
total 0
dr-x—— 2 silvio None 0 2008-05-29 14:48 .
dr-xr-xr-x 6 silvio None 0 2008-05-29 14:47 ..
lrwx—— 1 silvio None 64 2008-05-29 14:48 0 -> /dev/tty1
lrwx—— 1 silvio None 64 2008-05-29 14:48 1 -> /dev/tty1
lrwx—— 1 silvio None 64 2008-05-29 14:48 2 -> /dev/tty1
lr-x—— 1 silvio None 64 2008-05-29 14:48 3 -> pipe:[192216]
l-wx—— 1 silvio None 64 2008-05-29 14:48 4 -> pipe:[192216]
lr-x—— 1 silvio None 64 2008-05-29 14:48 5 -> /tmp/a.out

–
Silvio

#!/usr/bin/env ruby
puts “STDIN: #{STDIN.to_i}”
puts “STDOUT: #{STDOUT.to_i}”
puts “STDERR: #{STDERR.to_i}”
sleep(20) # give time to attach with gdb
i = 3
while (i ruby fds.rb
STDIN: 0
STDOUT: 1
STDERR: 2
trying fd #3..
fd #3 closed.
trying fd #4..
fd #4 closed.
trying fd #5..
fd #5 closed.
trying fd #6..
fd #6 closed.
etc etc etc all the way to 20

I’m very interested in how you found it and if it’s reproducable.
(I tested on Ubuntu 8.04 and Mac OSX)