clamav-milter chowns root/arbitrary directory

[Matt LaPlante]

Binary package hint: clamav-milter

A clean install of clamav-milter (0.95.1+dfsg-1ubuntu1.1) causes the root directory to become owned by the clamav user.

This was witnessed breaking ssh chroot environment.

TEST CASE:
- purge any existing clamav-milter installation, make sure you don't have any old /etc/init.d/clamav-milter init script around
- check root directory's owner (should be root:root)
- sudo apt-get install clamav-milter (the last one in Jaunty is 0.95.1+dfsg-1ubuntu1.1)
- after installing the package, clamav-milter will start automatically (at least 'init.d/clamav-milter start' will execute)
- check the root directory's owner:

root@utest-jj:/# stat /
  File: `/'
  Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 801h/2049d Inode: 2 Links: 23
Access: (0755/drwxr-xr-x) Uid: ( 110/ clamav) Gid: ( 0/ root)
Access: 2008-05-06 13:11:06.000000000 +0300
Modify: 2009-04-24 17:50:17.000000000 +0300
Change: 2009-04-27 15:30:07.000000000 +0300

Notice how it changed to clamav:root, this shouldn't happen.

[Scott Kitterman (kitterman)]

Confirmed and not a regression for the SRU. I installed clamav-milter 0.95.1.dfsg-1ubuntu1 (the jaunty-release revision) in a clean chroot and got:

-rw-r----- 1 clamav adm 0 Apr 24 04:21

[Imre Gergely (cemc)]

Confirmed. And not just the /root directory, the /etc too is owned by clamav. Run find by cd'ing to /

root@utest-jj:/# pwd
/
root@utest-jj:/# find . -user clamav | grep -v "/proc\|/var/"
.
find: `./proc/14896/task/14896/fd/5': No such file or directory
find: `./proc/14896/task/14896/fdinfo/5': No such file or directory
find: `./proc/14896/fd/5': No such file or directory
find: `./proc/14896/fdinfo/5': No such file or directory
./root
./etc
./etc/clamav
./etc/clamav/freshclam.conf

Notice how ".", /root, /etc also appear as owned by clamav.

[Imre Gergely (cemc)]

Scratch that... I've just did a --purge on all clamav packages in Jaunty, chown'ed back the root and etc directories to root, and reinstalled clamav-milter 1.1 from -proposed and after that from the main repo (1ubuntu1), but nothing happened, there was no chown'ing of /root or /etc to clamav. Except for the /none file, but that comes from the postinst script.

I also tried to redo the logrotate steps, by running the logrotate on the broken clamav-milter config, nothing happened either.

Matt, if you could add a clear test case to this, if and how it can be reproduced so I can check it again, that would be great.

[Matt LaPlante (cybrmatt)]

Please note by root directory I meant / and not /root. I did have some
additional inexplicably clamav owned directories, but the only one that I
can reproduce with the latest version is /:

root@prizm:~# apt-get purge clamav-milter
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer
required:
  clamav clamav-freshclam clamav-base libclamav6 clamav-daemon libtommath0
Use 'apt-get autoremove' to remove them.
The following packages will be REMOVED:
  clamav-milter*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 528kB disk space will be freed.
Do you want to continue [Y/n]?
(Reading database ... 166111 files and directories currently installed.)
Removing clamav-milter ...
 * Stopping Sendmail milter plugin for ClamAV clamav-milter
[ OK ]
Purging configuration files for clamav-milter ...
Processing triggers for man-db ...
root@prizm:~# chown root /
root@prizm:~# ls -ld /
drwxr-xr-x 21 root root 4096 2009-04-23 20:36 /
root@prizm:~# apt-get -V -t jaunty-proposed install clamav-milter
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
   clamav-docs (0.95.1+dfsg-1ubuntu1.1)
The following NEW packages will be installed:
   clamav-milter (0.95.1+dfsg-1ubuntu1.1)
0 upgraded, 1 newly installed, 0 to remove and 45 not upgraded.
Need to get 0B/262kB of archives.
After this operation, 528kB of additional disk space will be used.
Preconfiguring packages ...
Selecting previously deselected package clamav-milter.
(Reading database ... 166093 files and directories currently installed.)
Unpacking clamav-milter (from
.../clamav-milter_0.95.1+dfsg-1ubuntu1.1_i386.deb) ...
Processing triggers for man-db ...
Setting up clamav-milter (0.95.1+dfsg-1ubuntu1.1) ...
 * Starting Sendmail milter plugin for ClamAV clamav-milter
[ OK ]

root@prizm:~# ls -ld /
drwxr-xr-x 21 clamav root 4096 2009-04-23 20:36 /
root@prizm:~# ls -l /
total 100
drwxr-xr-x 2 root root 4096 2009-04-14 14:32 bin
drwxr-xr-x 4 root root 4096 2009-04-17 09:07 boot
drwxr-xr-x 13 root root 13860 2009-04-23 20:37 dev
drwxr-xr-x 197 root root 16384 2009-04-24 08:57 etc
drwxr-xr-x 5 root root 4096 2008-11-13 13:22 home
drwxr-xr-x 2 root root 4096 2006-05-07 12:03 initrd
drwxrwxr-x 21 root root 12288 2009-04-18 14:46 lib
dr-xr-xr-x 143 root root 0 2009-04-23 20:36 proc
drwxr-xr-x 52 root root 4096 2009-04-23 17:32 root
drwxr-xr-x 2 root root 12288 2009-04-20 20:15 sbin
drwxr-xr-x 12 root root 0 2009-04-23 20:36 sys
drwxrwxrwt 5 root root 140 2009-04-24 08:59 tmp
drwxr-xr-x 14 root root 4096 2008-10-13 10:30 usr
drwxr-xr-x 18 root root 4096 2008-12-05 22:43 var

[Imre Gergely (cemc)]

Uploaded the fixed version to the clamav PPA (clamav - 0.95.1+dfsg-1ubuntu1.1+ppa1 ), please test it after it builds and update this bugreport.

https://launchpad.net/~ubuntu-clamav/+archive/ppa

And here's a guide on activating the PPA:

https://help.launchpad.net/Packaging/PPA#Installing%20software%20from%20a%20PPA

Thank you.

[Scott Kitterman (kitterman)]

There is a proposed fix for this uploaded to the ubuntu-clamav PPA:

https://launchpad.net/~ubuntu-clamav/+archive/ppa/

Once it's built, please test and let us know if it solves the problem for you.

[Matt LaPlante (cybrmatt)]

Looks good to me.

[Martin Pitt (pitti)]

security team, is this something you'd rather see fixed in jaunty-security?

[Jamie Strandboge (jdstrand)]

Yes, this should go through -security. Are other releases besides Jaunty affected?

[Scott Kitterman (kitterman)]

No. This was introduced as part of refactoring the packaging for the new
clamav-milter in 0.95.

[Martin Pitt (pitti)]

OK, unsub'ing SRU team then.

[Imre Gergely (cemc)]

AFAIK the clamav-milter init script was rewritten in Jaunty a bit so it shouldn't affect packages in the other releases. I've checked current packages in Intrepid and Hardy and they don't have this problem. Checked the following:

intrepid-proposed: 0.94.dfsg.2-1ubuntu0.5
intrepid-security: 0.94.dfsg.2-1ubuntu0.3
hardy-backports: 0.94.dfsg.2-1ubuntu0.3~hardy3
hardy-security: 0.92.1~dfsg2-1.1ubuntu0.5

[Martin Pitt (pitti)]

Rejected -proposed upload, needs to be uploaded to -security

[Martin Pitt (pitti)]

Also, the postinst should go through some efforts to fix the damage, i. e. chown/chmod back /, /etc/ etc. on upgrade

[Scott Kitterman (kitterman)]

Fixed in Karmic.

[Scott Kitterman (kitterman)]

The clamav-milter init will chown "." to be owned by clamav. For normal system start, that is "/". If anyone runs the init from a different directory, that directory will get chown'ed.

[Scott Kitterman (kitterman)]

I integrated it with the other fixes and we're almost there. The find/remove of /none didn't work and group owner changed to root, but user did not:

$ ls -la / |grep clamav
drwxr-xr-x 21 clamav root 4096 2009-04-10 22:22 .
drwxr-xr-x 21 clamav root 4096 2009-04-10 22:22 ..
-rw-r----- 1 clamav adm 0 2009-04-23 00:08 none

[Scott Kitterman (kitterman)]

Updated debdiff attached. I think this is progress, so I'm uploading it to the ubuntu-clamav PPA, but as above, we aren't there yet.

[Scott Kitterman (kitterman)]

Updated debdiff attached. I think this is progress, so I'm uploading it to the ubuntu-clamav PPA, but as above, we aren't there yet. Please keep going ....

[Imre Gergely (cemc)]

This should be the final debdiff. Uploaded package to clamav PPA for testing.

[Imre Gergely (cemc)]

Debdiff against -1ubuntu1.1, for jaunty-security.

[Tigerboy (tigersands)]

Run the default synaptic package handler as root from the menu system-- running something as root starts the process in the root directory not in the logged on users directory as I understand it.

This caused the /home/username folder to become owned by clamav. I'm not sure if it was the clamav-milter script although that was part of the broad ubuntu upgrade. This resulted in not being able to boot into standard gnome desktop. Gnome failsafe allows boot where you can take back ownership as the user you log on with and the problem is solved. In this case there was no ownership changes on the root (/) folder.

[Imre Gergely (cemc)]

As far as I can tell by looking at the process tree, Synaptic gets run with gksu. When you click on it in the System menu, you need to enter your password, so it can run as root.
But! it is run by the user, from the user's home directory, and that doesn't change. You can check this by opening Synaptic, then in a terminal switching to root, doing a 'ps ax | grep synaptic', looking up the process ID (pid), cd'ing into /proc/<pid>, and doing a 'ls -la cwd' (which links to the current working directory), this should be /home/<user>.

[Tigerboy (tigersands)]

Thanks for that clarification I should have checked it first. The default and hence most likely way of running Synaptic will yield the users home directory problem and synaptics running with root powers from the user home might limit system-wide damage perhaps.

Yes I see but why would someone run first as root? after maybe about 1999 or so protocol was to operate the workstation/server as a user and that's also ubuntu's default set up.. I was also wondering why an install script or other program would have to take over the ownership of any directory I mean what would be the reason this isn't the first time something like this has happened I've even seen them give critical directories world rw permissions.. some sort of poorly conceived post install processing phase perhaps.

[Scott Kitterman (kitterman)]

In this case the init script makes sure that the directory for the pid file
exists and is owned by the clamav user (this is necessary). The bug is
that the variable that defines the path to it is incorrectly left unset, so
"." gets chown'ed instead of /var/run/clamav.

[Launchpad Janitor (janitor)]

This bug was fixed in the package clamav - 0.95.1+dfsg-1ubuntu1.2

---------------
clamav (0.95.1+dfsg-1ubuntu1.2) jaunty-security; urgency=low

  * SECURITY UPDATE: clamav-milter.init changes current directory owner
    to user 'clamav' when run, potentially breaking ssh chroots, user's
    home directories (LP: #365823)
    - debian/clamav-milter.init: fixed pidfile chown on startup from Debian
      clamav git repo
    - debian/clamav-milter.postinst.in: added cleanup code to search for
      and restore clamav-owned directories to root and remove rogue /none
      file (LP: #363796, #363804)

 -- Imre Gergely <email address hidden> Fri, 01 May 2009 18:23:20 +0300