[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 24 Sep 2012 16:03:20 -0400 (EDT)
From: "Steven M. Christey" <coley@...-smtp.mitre.org>
To: oss-security@...ts.openwall.com
Subject: Re: Re: Re: Re: CVE request(?): gpg: improper file
permssions set when en/de-crypting files
FYI, this discussion is an interesting example of what I've called the
"snowball effect" in CVE when new kinds of issues arise that test the
boundaries of what should or should not belong in CVE - allowing one (or a
handful) could open the door to hundreds or thousands of other products
that have the same issue.
Personally, I would expect a security/privacy-preserving product to select
the most conservative file permissions that it knows won't violate the
user's intention; in this case, the permissions of the original "source"
file, as further restricted by the user-specified umask. If the user
calls gpg with a world-readable file and a "promiscuous" umask, then they
deserve what they get. If a product decides to be more restrictive than
even the user specifies, then that's OK, but I would view it as a
hardening measure, which generally doesn't get a CVE.
Note that's a personal view, not any "official" CVE decision. This is
still an ongoing discussion.
There is historical precedent for archivers like ZIP or tar that have race
conditions where they initially create files world-readable (in some
cases, probably inheriting umask) and don't restrict the permissions until
after the extraction is complete. That's a more clear example, however,
because the products have functionality that intends to impose the
required permissions, but don't do it quickly enough.
- Steve
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.
