Re: CVE request: mumble local information disclosure

[Kurt Seifried <kseifried () redhat com>]

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)