The good old "permission denied", the ignored group memberships, and a proposed solution

[Luc Pardon]

On Mon, 17 May 2021 13:32:31 +0100
Dominic Raferd <dominic at timedicer.co.uk> 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.