> Google finds this attack code > > http://www.metasploit.com/projects/Framework/modules/exploits/distcc_exec.pm > > You can see it is more a matter of malice than genius.
This specific one could be defeated easily. Notice how argv[N] is set to "#". If nothing else, distcc could reject any command where any argument starts with '#', since this looks suspicious enough and I can't think of any regular use of it. > I'd like to make it safer by default; but the protocol probably needs > to use plain TCP for performance. Here are some ideas. What do > people here think? > > - Make --allow mandatory; you have to say which networks are trusted Yes. Very good idea. As a side effect it'll make users realize how careful they have to be when running distccd. > - Use a cleartext shared password; not much protection against > local attackers but it might have helped in this case. Could be done, although it looks somewhat redundant with making --allow mandatory (unless you don't trust your neighbours). > - Work on making SSH more useful, though it will probably never be > really fast Distcc is not meant to be efficient on non-local networks anyway. I wouldn't spend too much time and energy in enhancing something that should rarely, if ever, be used. > - Add weaker built-in encryption; this feels wrong Pointless. > - Encourage people to choose nonstandard ports This isn't distcc specific. Besides, once --allow is mandatory, better keep the port standard and let the intruders take their chance (and fail). And log before rejecting. We want to know our enemies. > - Try to vet the command line; allow only particular commands. It's > not enough to just say "only run gcc" because an attacker might > try to send output to a file. This couldn't give total protection > but it might help. I wouldn't analyze the whole command line, since it can differ significantly from comiler to compiler (except for the comment trick as noted above). But a built-in, command-line-overwritable list of known compilers would make things way safer. Among other things, it would prevent an entire local network from being compromised just because one machine was compromised. And again, log before rejecting (both for attacker-tracking and debugging purposes). As far as using the output to overwrite a file, this may indeed be a problem. I would hate it is an intruder would have *me* compile the binary "ps" or "top" he will use to trick me. However, as long as the daemon is run by a fake user, it shouldn't be exploitable, unless file permissions are bad, but this then isn't a distcc-specific problem (and the attacker can probably not know that). So, I think we should implement, in order: 1* --allow is mandatory 2* compiler name checking 3* no '#' in commands And it should be fine and rather safe then. -- Jean "Khali" Delvare http://khali.linux-fr.org/ __ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc