[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4F3D8BB6.2040409@redhat.com>
Date: Thu, 16 Feb 2012 16:05:26 -0700
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
CC: Ludwig Nussel <ludwig.nussel@...e.de>, Vincent Untz <vuntz@...nsuse.org>
Subject: Re: CVE request: mumble local information disclosure
On 02/16/2012 07:35 AM, Ludwig Nussel wrote:
> Vincent Danen wrote:
>> It was discovered that mumble created its database file
>> (~/.local/share/data/Mumble/.mumble.sqlite) with insecure world-readable
>> permissions. If the user had (non-default) permissions on their home
>> directory, another local user could obtain password and configuration
>> settings from the database file.
>
> It certainly makes sense for cautios applications to make sure sensitive
> settings have restricted access permissions. Question is whether it is
> actually a vulnerability if they don't. Quoting the XDG spec¹
We can't rely upon file permissions being done safely/properly, just
like we can't rely upon proper firewalls/etc for network services that
"should" be internal only but sometimes are not (e.g.
SMB/CIFS/NFS/etc.), There are often very legitimate cases for not having
a firewall, world readable home dir, etc. The whole onion (multi-layered
security) approach and so forth means we classify a lot more things as
security vulns than is perhaps strictly necessary, but in the long run
leads to safer and more robust systems.
> | If, when attempting to write a file, the destination directory is
> | non-existant an attempt should be made to create it with permission
> | 0700. If the destination directory exists already the permissions should
> | not be changed.
>
> So it could be argued that mumble just relied on the specification that
> already mandates restrictive permissions on ~/.config.
The specifications might be wrong, they might be incomplete, they might
be interpreted incorrectly, they might be implemented incorrectly, etc.
> The program that is supposed to create ~/.config on login had a bug that
> made the dir 755 in violation of the spec². Fixing the permissions is
> not allowed according to the spec though ...
>
> cu
> Ludwig
>
> [1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
> [2] https://bugs.freedesktop.org/show_bug.cgi?id=36773
>
--
Kurt Seifried Red Hat Security Response Team (SRT)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
