Vulnerability Development mailing list archives
Re: trusting user-supplied data (was Re: FreeBSD Security AdvisoryFreeBSD-SA-02:23.stdio)
From: Syzop <syz () dds nl>
Date: Sat, 04 May 2002 16:53:51 +0200
*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.
Current thread:
- Re: trusting user-supplied data (was Re: FreeBSD Security AdvisoryFreeBSD-SA-02:23.stdio) Syzop (May 04)
- Re: trusting user-supplied data (was Re: FreeBSD Security AdvisoryFreeBSD-SA-02:23.stdio) Paul Starzetz (May 04)
- Finding and exploiting buffer overflows in Windows. John Thornton (May 05)
- RE: Finding and exploiting buffer overflows in Windows. Vlad (May 05)
- Re: Finding and exploiting buffer overflows in Windows. Jose Nazario (May 05)
- Finding and exploiting buffer overflows in Windows. John Thornton (May 05)
- Re: trusting user-supplied data (was Re: FreeBSD Security AdvisoryFreeBSD-SA-02:23.stdio) Paul Starzetz (May 04)