On Fri, 2008-06-20 at 14:24 +0100, Anton Altaparmakov wrote:
> Hi,
>
> The autofs 5.0.2 package that comes with opensuse 10.3 has a nasty
> denial of service attack in the automount daemon. I can only assume
> that the code comes from the actual autofs source rather than being
> introduced by opensuse but I could be wrong (I haven't checked).
>
> The bug is that automount searches /proc/*/cmdline for a substring
> that matches "automount" and refuses to run if it finds such a thing.
>
> So any user that just does:
>
> cat > automount.c <<EOD
> int main(void)
> {
> sleep(10000);
> return 0;
> }
> EOD
> gcc -o automount.c
> export PATH=.;$PATH
> automount
>
> And now no-one can run the real automount including root!
>
> Even if this was not a DoS waiting to happen, why do you have this
> check in the code? There is no reason whatsoever to try and restrict
> people from running multiple instances of the automount process...
Really, the fact that you think no-one will ever attempt to run
automount again, perhaps by accidentally starting the application when
it is already running, using the same configuration shows you haven't
really thought about this issue.
>
> We in fact run one automount instance for each logged in user on our
> Linux distribution for Cambridge University. - We now have to play
> silly buggers with running automount in such a way as to replace its
> argv[0] with a different string so we can run multiple instances.
>
> But that still leaves the DoS attack that any user can run a program
> as above and no-one else will be able to log in any more as the
> automount process will find the literal string "automount" from the
> user's executable...
>
> So we would really like the complete abomination that is autofs/daemon/
> automount.c::is_automount_running() thrown away or at least made
> optional with a command line option if you insist on having it, pretty
> please with sugar on top?
The tone of your mail is lousy, given that your asking for something and
haven't offered a patch to support your request and haven't really
thought about the issue and haven't even offered any suggestions about
alternative approaches.
Ian
_______________________________________________
autofs mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/autofs
