[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#606543: clamav-freshclam: affected by privilege escalation vulnerability in logrotate



Hi,

> [...]
> > 
> > These lines from this package's maintainer scripts suggest that it likely
> > is affected by the vulnerability:
> > 
> > ---------------------------------------------------------------------------
> > chmod 640 $FRESHCLAMLOGFILE
> > chown "$dbowner":adm $FRESHCLAMLOGFILE
> > ---------------------------------------------------------------------------
> > 
> 
> What is wrong about these two lines? And even from ...

I'm not sure anything is wrong about those (though they very well may
be dangerous as well, that depends on the permissions of the directory
that file is in--namely, whether an unprivileged user can create entries
in it). The point of mentioning them was to make transparent why I think
your package likely is affected by logrotate's vulnerability.

Looking at it now, this package may actually be a false positive,
assuming that the directory is writable by root only?!

> [...]
> 
> > For some further details please see my announcement of this mass
> > filing on debian-qa:
> > 
> > http://lists.debian.org/debian-qa/2010/11/msg00024.html
> > 
> [...]
> 
> ... I don't quite understand why this would be problem specific to one of the
> packages you did the MBF for. If I get the idea of your exploit right, you

It's not specific. It's just that logrotate as a matter of fact doesn't get
fixed even though that would be the sane way to go about it.

> replace the log file by a symlink to a root-owned file, and in some mysterious
> way you then seem to be able to overwrite the root-owned file. Well, it will
> suffice for the evil person to be in adm group, you don't need to be $package
> user for doing that.

Well, in a rather non-mysterious way, that's what logrotate does, yes.

> But ok, you don't even claim there's a specific bug in our package, it's all
> logrotate's fault. Assuming clamav uses logrotate in a sane way (I wouldn't no
> of anyone claiming it does not), what should we do? Drop log rotation? Cool,
> thanks, then the security-tagged bug report against clamav is actually justified
> because it'll soon fill up your disk, possibly resulting in a DoS. Come up with
> it's own cron-job for log rotation? No, thank you.

I don't suggest any fixes (beyond fixing logrotate, which as a matter of
fact does not happen though). I just wanted to make maintainers aware that
their packages as a matter of fact are vulnerable because I assumed that
some maintainers would not necessarily like the idea of their packages
being vulnerable.

> At present, the only thing I'd plan to do is to either reassign this bug to
> logrotate or simply close it.

That's up to you, obviously (well, and in this particular case, assuming
it's a false positive, closing it may actually be the only sensible thing to
do ;-).

Florian


Reply to: