DMA[2006-0514a] - 'ClamAV freshclam incorrect privilege drop'
DMA[2006-0514a] - 'ClamAV freshclam incorrect privilege drop'
Author: Kevin Finisterre
Vendor: http://www.clamav.net
Product: 'ClamAV freshclam'
References:
http://www.digitalmunition.com/DMA[2006-0514a].txt
http://www.markallan.co.uk/clamXav/
Description:
Tomasz Kojm of the ClamAV team describes the following code snippet from
freshclam as being "for system administrators who know
what they're doing".
/* parse the config file */
if((cfgfile = getargl(opt, "config-file"))) {
copt = getcfg(cfgfile, 1);
}
...
if(setgid(user->pw_gid)) {
logg("^setgid(%d) failed.\n", (int) user->pw_gid);
exit(61);
}
if(setuid(user->pw_uid)) {
logg("^setuid(%d) failed.\n", (int) user->pw_uid);
exit(61);
}
Tomasz feels that since "[there are] no problem[s] in freshclam" making any
changes to the above code would have "... no real
sense from a security point of view". My views on the otherhand are slightly
different. The above code snippet was obviously
put in place to control the uid with which the freshclam binary runs. The
freshclam manual page even makes a blatant claim
that freshclam will drop privileges.
freshclam(1) Clam AntiVirus
freshclam(1)
NAME
freshclam - update virus databases
...
-u USER, --user USER
Run as USER. By default (when started by root) freshclam drops
privileges and works as the 'clamav'
user.
For a program that currently has no problems the ClamAV authors have certainly
went to odd lengths to make sure that freshclam
and aparantly its sister programs do not get run with root privs. Tomasz aptly
pointed out to me that on page 12 of the ClamAV
documentation http://www.clamav.net/doc/0.88.2/clamdoc.pdf that users are
warned to some extent:
WARNING: Never enable the SUID or SGID bits in Clam AntiVirus binaries.
Given that freshclam should aparantly never be run as root I do not exactly get
the point of going through the trouble of
dropping privs. In the context of complete non privileged use there is no point
for the above code at all. It seems as if it
should simply be removed.
In the event that you are either A) a user on a system with an administrator
that doesn't know what he is doing, B) someone that
has gained access freshclam via sudo or C) a user on a system with clamXav
installed, you may notice the following behavior:
As you can see freshclam actually does attempt to drop privs for some unknown
reason.
kfinisterre@animosity:~$ sudo freshclam --on-update-execute=/usr/bin/id
ClamAV update process started at Fri Mar 17 22:41:06 2006
SECURITY WARNING: NO SUPPORT FOR DIGITAL SIGNATURES
See the FAQ at http://www.clamav.net/faq.html for an explanation.
Downloading main.cvd [99%]
main.cvd updated (version: 36, sigs: 44686, f-level: 7, builder: tkojm)
Downloading daily.cvd [100%]
daily.cvd updated (version: 1337, sigs: 1897, f-level: 7, builder: ccordes)
Database updated (46583 signatures) from database.clamav.net (IP: 67.18.105.98)
uid=1001(clamav) gid=1002(clamav) groups=1002(clamav)
Unfortunately if you read the man page and *thought* that freshclam *actually*
dropped privileges you were completely wrong.
It seems that giving a user sudo access to freshclam is a bad idea if you
consider the following example.
kfinisterre@animosity:~$ ls -al /etc/shadow
-rw-r----- 1 root shadow 797 2006-03-17 22:26 /etc/shadow
kfinisterre@animosity:~$ cat /etc/shadow
cat: /etc/shadow: Permission denied
Normally would not have permission to /etc/shadow however the shared config
parser from freshclam helps spit the contents
to the screen in the example which is being run on a linux machine.
./shared/cfgparser.c:303: fprintf(stderr, "ERROR: Parse error at line %d:
Unknown option %s.\n", line, name);
kfinisterre@animosity:~$ sudo freshclam --config-file=/etc/shadow
ERROR: Parse error at line 1: Unknown option
root:$1$Shootthis$shouldntbehere/:12881:0:99999:7:::.
ERROR: Can't parse the config file /etc/shadow
You can see here that the setgid(user->pw_gid) and setuid(user->pw_uid) calls
occur a bit too late to be of use to the getcfg()
functione. I don't quite get why privs would be dropped when using
--on-update-execute but not when --config-file is used. For
that matter I don't get why one would drop privs at all if there was never
intended to be any setuid like activity involved. If
the setgid and setuid calls are to be used at all they should be placed before
getcfg() is called.
As a side note to the bug iteslt, after visiting the clamav binaries webpage at
http://www.clamav.net/binary.html and viewing
the following text Macintosh users may have found them selves installing
clamXav:
MacOS X
* clamXav, a GUI for ClamAV running on MacOS X, is available at
http://www.markallan.co.uk/clamXav (http://www.clamxav.com/).
It includes a slightly modified version of ClamAV engine as a back end.
ClamAV also ships with
MacOS X 10.4 (Tiger) Server.
Although you were aptly warned if you installed either ClamXav + backend -
version 1.0.1 (7.6 MB) - Released 18th July 2005
(Includes ClamAV 0.88 backend) or the ClamAV backend - version 0.88 (5.0 MB) -
Released 14th January 2006 you will find that
clamXav makes the mistake of giving freshclam a setuid bit. (This was also
tested with the most recent version clamXav 1.0.3h).
Even if you followed the old motto "When in doubt always compile ClamAV from
sources" you may have fallen prey to the
documentation from the clamXav installer package in which you are told to
"chmod u+s /usr/local/clamXav/bin/freshclam".
Welcome to Darwin!
k-fs-computer:~ kf$ ls -al /usr/local/clamXav/bin/freshclam
-rwsr-xr-x 1 root admin 224836 May 5 04:25 /usr/local/clamXav/bin/freshclam
k-fs-computer:~ kf$ cat /etc/sudoers
cat: /etc/sudoers: Permission denied
k-fs-computer:~ kf$ /usr/local/clamXav/bin/freshclam --debug
--config-file=/etc/sudoers
ERROR: Parse error at line 19: Unknown option root ALL=(ALL).
ERROR: Can't parse the config file /etc/sudoers
I want to note that this issue is not critical however I wanted to highlight
that one should be careful when running the various
components of ClamAV because some of them contain code that is intended to be
"for system administrators who know what they're doing".
As a workaround anyone who has given non trusted users sudo access to freshclam
should immediately revoke that access. Similarly
anyone with a setuid bit on the freshclam binary should immediately remove the
bit by using the "chmod -s /path/to/freshclam" command.
Happy Mothers Day or something...