ActiveX programs, regardless of who provides them, also have to be run by
someone logged into the system. I don't see how it's relevant though.
> You can convieniently remove users that do this
> sort of thing from the system.
Nothing made it into the syslog when I tried this exploit. Suppose I'd
done it on a system where there were 50 users logged in, and I'd put the
little (<4kB) binary in /tmp, /tmp were on a ramdisk, and I didn't leave
fork.c lying around. Alternatively, suppose that I innocently wrote some
really bad code and ran it from my unprivileged account. I'd feel more
comfortable if it weren't possible to crash the whole system that way.
> Besides, you can allocate resources via
> ulimit in bash to circumvent the problem before it happens.
I'm using tcsh. In /etc/login.defs I have:
ULIMIT 2097152
and the system has 64 MB RAM, no swap. Ideally, the kernel wouldn't need
the insulation of the "right" shell, properly configured ulimits, and so
on.
> Even so, I ran the program on 2.0.27 with unlimited resources in bash
> (in X). I was able to get a console and bring the system dowm. If ps
> hadn't barfed, I could have recovered without bringing down the system.
> I ran the program with process limits set at 100, and was able to kill
> the parent shell and regain control of the system.
Ah yes, 2.0 is the stable series. I'll try 2.0.27 as well.
> You can tell your NT friend; Nice Try - maby Next Time - Not Today...
No one was advocating NT.
___
Trevor Johnson <trevor@jpj..net>