[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20150324165100.E40C342E091@smtpvbsrv1.mitre.org>
Date: Tue, 24 Mar 2015 12:51:00 -0400 (EDT)
From: cve-assign@...re.org
To: ppandit@...hat.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE request Linux kernel: fs: btrfs: non-atomic xattr replace operation
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> Linux kernel built with the Btrfs Filesystem support(CONFIG_BTRFS_FS) is
> vulnerable to a race condition which leaves the extended attribute(xattr)
> empty for a short time window. This could be leveraged to bypass set ACLs and
> potentially escalate user privileges.
>
> An unprivileged user could use this flaw to potentially escalate privileges on
> a system.
>
> https://git.kernel.org/linus/5f5bc6b1e2d5a6f827bc860ef2dc5b6f365d1339
We would like to restate the security issue somewhat. The commit
mentions two separate concerns: (1) "This leaves a time window where
readers (getxattr, listxattrs) won't see any value for the xattr" and
(2) "Deleting the old xattr value without verifying first if the new
xattr will fit." In both cases, apparently the underlying problem is
that the code is attempting to accomplish a transition between a
previously acceptable state of an object and a new acceptable state of
an object, but does this in a way that an intermediate state becomes
visible. Because the intermediate state is, for a security-relevant
reason, not known to be acceptable, the transition code has a
vulnerability (related, in general, to CWE-371). We feel that (1) and
(2) are therefore the same type of vulnerability, even though the
attack methodology might rely on a race condition only in case (1).
Use CVE-2014-9710 for this vulnerability involving improper management
of xattr state.
> Returning -EEXIST when the flag XATTR_CREATE is given and the xattr
> doesn't exist
We don't know whether this third concern is a vulnerability. Presumably
it would depend on what callers do after the -EEXIST.
- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJVEZW6AAoJEKllVAevmvmsk44IAKLgwGa2CnmZn+gN53zdhkSX
3RguwbKRz4QbOri829ByHoqo5wpGfsNKi+KHfz77d895w0SbqEoosStqhgXErQy7
bGCVxjf1PwDRthffptsDtwT+NrP2d8uWVcGM1U9dDlBD40VU4a7fRCzYxoReJaAp
eyy1aA96gyxFoGZm1vENuMrgDJmMp6EajV3292Acg6cJ/UoPJ7QxNpPtYI8tua/V
zXqMprms2jyba7v37+HW6zQ0zELDCWfzSeYkyCOAgGI5oBc1RsKeOyHfWpS1A3sr
f5pqfNfUu75+38+xl0Ic+GKxO1reqCkZe6iFu9OkdGtAHXIMMkxLMHpQfP4J9v8=
=op6Y
-----END PGP SIGNATURE-----
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.
