On Mon, 17 May 2021 13:32:31 +0100 Dominic Raferd <[email protected]> wrote:
> > > The default setting for the clamav socket is to be world-readable and > world-writeable. In Ubuntu (and Debian?) this is set explicitly (but > presumably unnecessarily) in clamd.conf thus: > > LocalSocketMode 666 Shudder ! > Do you have mode 660? > Of course I have. I say "of course" because, IMHO, giving world access to (a socket that controls) a virus scanner daemon is a disaster waiting to happen. For example: any local user can now do: echo SHUTDOWN | ncat -U /run/clamd/clamd.sock And down goes the daemon. For more fun, (DO NOT!) try a RELOAD command, preferably in a "while true" loop, and watch the effect of a one-line DoS attack. Disclaimer: assumption of mine, I didn't test it myself <g>. But current releases of ClamAV do a "non-blocking reload" by default, i.e. they spawn a separate thread to read the signature files. If they'd do that each time a command comes in, at 2 Gig apiece, any box will run out of physical memory in no time and start thrashing like crazy. Anyway, if this doesn't "help", try an unending stream of "SCAN /" commands. Unless the entire file system is on a tiny and super-fast disk, this would probably keep the poor daemon pretty busy as well. A more determined intruder may shutdown the real daemon (as above) and take its place: read from the socket and give an "all clear" reply to any scan request that comes in. It would be cool if the intruder could "call home" and trigger a flood of virus-infected mails. They will all pass. Or it could falsely raise the alarm on every single mail and have everything quarantained or - with some luck - discarded, depending on the policy in amavisd.conf. And that's only the documented commands (man 8 clamd). I don't want to think what happens when our uninvited visitor sends garbage down that unprotected socket. An exploitable buffer overflow, anyone? Or, since we're walking on the wild side anyway, what about a little spyware, taking the place of the real virus scanner (as above) and sending a copy of every mail to its bosses? Or - why not - to the Amavis user list? Wouldn't that be fun? If the little critter should have problems getting at the content of the mails, it just has to cry "permission denied" into the logs and a helpful administrator will come running and "fix" that "problem" as well <g>. Sure, one can make "permission denied" problems go away by lifting all access restrictions, so yes, it is a "solution". But what good is it to have the concept of fine-grained ugo/rwx permissions if it has to be disabled to be able to run amavisd ? So, instead of sweeping the dirt under the carpet, it would be better to go after the root of the problem, and that is that amavisd can't handle multiple group memberships when dropping privileges. If a distro doesn't want to patch the code, there are a few (less adventurous) alternatives to a wide-open socket. One could: a) run clamd under the same user account as amavisd (e.g. "amavis"), by shipping the clamd.conf file with "User amavis" in it; b) or ship a systemd service file (or whatever suits the init system on duty) that doesn't start the amavisd program as root, but rather as the "amavis" user directly. That way it doesn't have to drop privileges itself. Both methods are suggested in the Amavis INSTALL file, BTW. Just my 2 cents.
