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 > >  http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html >  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.