Re: privilege escalation and potential data loss in logrotate

[Florian Zumbiehl <florz@florz.de>]

Hi,

> On Sat, Nov 20, 2010 at 08:23:44AM +0100, Florian Zumbiehl wrote:
> > The short summary:
> > 
> > 1. There is a privilege escalation vulnerability in stable's logrotate,
> >    verified to work for switching from the postgres user to root, probably
> >    affecting the system users of about 40 packages. A fix for this has
> >    been in testing for about a year now, the original bug report and a
> >    first patch have been in the bug tracker for about four years now.
> 
> It has never been verified, and no proof was ever given.

If "no proof was ever given", I wonder what hypothetical security problems
you fixed with those security patches in testing, if I may quote your own
changelog:

| + security-388608.patch: A race condition in the creation of
|   compressed and copied log files makes it possible to overwrite
|   arbitrary files by generating a link or symlink during a window
|   of opportunity between logrotate renaming a log file and creating
|   the copy of the next. (Closes: #388608) Once again, many thanks to
|   Florian Zumbiehl for forcing me to think.

Also:

| Date: Wed, 19 Aug 2009 11:03:03 +0200
| From: Florian Zumbiehl <florz@florz.de>
| To: team@security.debian.org
| Cc: pm@debian.org
| Subject: logrotate vulnerability (bug #388608, kindof)
| 
| [...]
| In 3.7.8-4, finally, a fix was applied that's mostly functionally
| equivalent to the patch I submitted three years ago, which fixes
| privilege escalation in cases where an unprivileged user can create
| directory entries that get rotated by the cron.daily-logrotate.
| In this case, again, you can put a link in place, that this time causes
| logrotate to overwrite the referenced file. Using /etc/shadow as
| the target, I successfully elevated my privileges from postgres to
| root using this vulnerability.
| [...]

I'm not sure what qualifies as "verification" or "proof" if that
does not.

> > First of all, it's bug #388608. Unfortunately, quite a bit of the
> > interesting communication was private, either with the maintainer, or
> > with the security team, or both, so I can't reference it in some public
> > location, and just pasting my own text fragments into this mail probably
> > would not be particularly enlightening either.
> 
> Please feel free to make public any of the communication from me, with
> the proviso that I can also make public any communication from you.

I don't currently see the use (fragments out of context aren't all that
helpful and just quoting the whole thread would be a bit tedious to
follow, I suppose)--but I'm fine with you quoting what I've written
if you think there is any use for it.

> > Regarding the regression in the fix: With previous versions, it was
> > guaranteed that unless you used the copytruncate option, you would not
> > ever lose log messages due to rotation. With the fix, this guarantee
> > does not exist anymore in cases where the program writing to the log
> > file as well as logrotate may create the log file when it doesn't exist
> > (which is a common setup, and which cannot even be avoided in many
> > cases).
> 
> The problem is that your suggested fix is worse then the purported
> vulnerability, causing potential data loss, and there is no way of
> avoiding that due to the lack of any atomic filesystem operations that
> would generate the file, check that it isn't vulnetable and set the
> permissions and ownership simultaneously.

Sorry, I can't follow you. You mean that the fix you have applied in
testing is worse than privilege escalation to root for (probably numerous)
system users, because it introduces the potential for data loss under
some rare circumstances, which could be fixed by applying the patch that
I sent you over a year ago?

> > If I don't see any solution emerging in a reasonable time frame, my next
> > step would be a more-or-less mass filing against all those packages that
> > some rough analysis suggests are affected by either the vulnerability
> > or the regression so that their maintainers can take measures to work
> > around the problem if they want to.
> 
> You are, of course, free to send me a working patch or pursue the
> upstream authors (at Red Hat) for a fix.

If you were so kind to point out what part of my fix is not working?

Florian