Re: trusting user-supplied data (was Re: FreeBSD Security AdvisoryFreeBSD-SA-02:23.stdio)

[Syzop <syz () dds nl>]

*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.