[distcc] Exploit in distcc
khali at linux-fr.org
Fri Aug 27 09:45:23 GMT 2004
> Google finds this attack code
> 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
> - 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
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
More information about the distcc