*move to vuln-dev* Paul Starzetz wrote: > I don't think there was enough research on open file descriptor > problems. I was playing with it some time ago after I had read this vuln-dev post: http://online.securityfocus.com/archive/82/217413 from Steve Grubb from sep 30 2001. The problem is known for years (long before this post) but nobody replied even at that post... This problem really needs more attention. > For example, I found this small bug while playing yround with > crontab on Linux: Mmm, I had a look at cron half a year ago but I didn't have a "deny" file so I didn't discover anything suspicious... But now I can: at debian, cron 3.0pl1-72 (latest AFAIK). > So I'm able to read a privileged system file using this technique :-> > Not necessary to mention the consequences of inheriting such a fd open > for writing. More effort must be put to investigate this problem in > current Linux/Unix suid/setgid binaries. Agreed. > have fun with the attached source. I used env_audit, the code from Steve Grubb (note that I never searched for such a tool so there might be better ones)... But that one was slow when "resolving" fd#-> filename, you use a nice /proc trick while env_audit was searching the whole filesystem for a certain inode... I modified that part now and you can find it at http://www.xs4all.nl/~mlhj/stuff/env_audit.c It outputs to /tmp/env_audit.log Output from export EDITOR=/tmp/env_audit; crontab -e; cat /tmp/env_audit.log: -- snip -- Open file descriptor: 3 User ID of File Owner: 0 Group ID of File Owner: 0 WARNING - Descriptor is leaked from parent. File type: regular file, inode: 55513 The leaked descriptor is: /etc/cron.deny/3 File decriptor is read only --- Open file descriptor: 5 User ID of File Owner: 1000 Group ID of File Owner: 1000 WARNING - Descriptor is leaked from parent. File type: regular file, inode: 23293 The leaked descriptor is: /tmp/crontab.XXXXbH1ElC File decriptor is read and write -- (btw I didn't see that last entry with your prog) Then something related: I don't know very much about signals, but... If apache executes a cgi script, the child can send signals to his parent, AFAIK this is normal and can't be denied? What if.. you code a CGI script which sends a kill signal to his parent and you then execute that cgi script XX times. [like: int main() { kill(getppid(), 9); }] Apache would have to create a new child-thread (or whatever its called) on every kill. Just yet another thing I never published (pretty obvious anyway). Bram Matthys.
This archive was generated by hypermail 2b30 : Sat May 04 2002 - 10:56:50 PDT