Bug#757438: exposes entire dpkg upgrade log to non-root users

2014-09-11 Thread Michael Vogt
On Fri, Aug 08, 2014 at 03:00:19AM -0400, Joey Hess wrote:
> Package: unattended-upgrades
> Version: 0.79.5
> Severity: normal
> Tags: security

Thanks for your bugreport and sorry for my slow reply.
 
> /var/log/unattended-upgrades/ is readable by all, so when this package is
> run on a multi-user system, non-admin users can trawl the upgrade logs
> for interesting information.
[..]

I totally agree with the concern and fixed the permissions of the dir
to root:adm 0750 (as you suggested) and the dpkg log to root:adm 0640
too. This will be part of my next upload.
 
> Any reason not to make the directory 750 root.adm?

No, fixed.

Do you think this should go out to stable as well? 

Cheers,
 Michael


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#757438: exposes entire dpkg upgrade log to non-root users

2014-08-08 Thread Joey Hess
Package: unattended-upgrades
Version: 0.79.5
Severity: normal
Tags: security

/var/log/unattended-upgrades/ is readable by all, so when this package is
run on a multi-user system, non-admin users can trawl the upgrade logs
for interesting information.

I don't know what they might find.. Which is the concern. When writing a
postinst script, the assumption is probably that only an admin, or
possibly a shoulder-surfer might see its output. So I'd not be surprised
if some of them leak information that is in some way sensative, though
probably not password-level sensitive.

Ah, let's pick on one of my own packages -- when etckeeper is installed,
it makes commits of changes in /etc and allows git to display its usual
summary of changes. So the log can contain something like this:

[master d7acbf4] saving uncommitted changes in /etc prior to apt run
 2 files changed, 317 insertions(+)
 create mode 100644 ssl/private/apache.pem
 create mode 100644 ssl/certs/apache.pem

.. Exposing the contents of directories that normal users
cannot see inside of. I would not worry much if a shoulder-surfer saw that,
but it's worrying to think that a user could extract all such messages from
all the upgrade logs and combine them to facilitate other attacks.

For example, in this case, a wily attacker might notice that I seem to
accidentially have an insecure o+r mode on the apache ssl cert, which is
protected only by the mode of /etc/ssl/private. Now they can look for a
security hole that allows hard linking to arbitrary files as root..

Any reason not to make the directory 750 root.adm?

-- 
see shy jo


signature.asc
Description: Digital signature