[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20151012185056.0366DB2E069@smtpvbsrv1.mitre.org>
Date: Mon, 12 Oct 2015 14:50:56 -0400 (EDT)
From: cve-assign@...re.org
To: fweimer@...hat.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE request: BD-J implementation in libbluray
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
> It was found that org.videolan.BDJLoader class implementation of
> libbluray, a library to access Blu-Ray disks for video playback, was
> missing Java Security Manager sandboxing. A specially-crafted Java
> application, utilizing the functionality of org.videolan.BDJLoader
> class, could use this missing feature to perform actions as the user
> running the Bluray player application.
>
> Note: libbluray upstream disables BD-J support by default, but some
> downstreams (like Fedora) pass --enable-bdjava at configure time,
> enabling it for their distribution.
This is a situation in which there may be multiple valid perspectives.
What we're going to do is assign a CVE ID to the Fedora package for
the use of --enable-bdjava at a time when there had not been an
upstream release with default support for BD-J. Use CVE-2015-7810.
The upstream default was changed here:
http://git.videolan.org/?p=libbluray.git;a=commit;h=a83104c1c31301c4b2eb593b21e7b43f5480bd64
on 2015-02-03. Default support for BD-J was present in 0.8.0 (released
2015-04-29) but not in 0.7.0 (released 2015-01-27).
https://download.videolan.org/pub/videolan/libbluray/ doesn't list any
releases between these.
In 0.7.0, the configure script has:
--enable-bdjava enable BD-Java support (default is no)
under "Optional Features" but we didn't find any documentation or
comments suggesting that --enable-bdjava was recommended for general
use cases at that time. Apparently, BDJSecurityManager development
came after 0.7.0.
In other words, our perspective is that the primary known mistake is
that the Fedora packaging process chose a non-standard default
behavior, and either didn't investigate or didn't document the risks.
If anyone else independently chose --enable-bdjava for their package
based on 0.7.0 or earlier, then they can have their own CVE ID.
On the question of whether CVE IDs can be assigned for an upstream
BDJSecurityManager error (or omission), we don't currently know.
Certainly if the upstream documentation announced that the product was
intended for arbitrary untrusted Blu-ray content, then any
security-relevant behavior would be a vulnerability. Blu-ray content
is designed to be (in some senses, but maybe not all arbitrary senses)
executable content.
http://www.openwall.com/lists/oss-security/2015/02/23/12 suggests an
original upstream goal of handling trusted content in which the Java
code is trusted Java code. Accordingly, it seems reasonable to
interpret BDJSecurityManager as a work in progress. The existence of
later releases doesn't mean they have announced that they are
finished. For the general case of attacks that use media content, the
CVE assignment process has an expectation that untrusted content may
occur; however, any known upstream goal is always considered (also,
the situation details are unusual here because the attack relies on
Java, not memory safety in handling audio/video data).
Similarly,
https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2015/february/abusing-blu-ray-players-pt.-1-sandbox-escapes/
mentions (among its other findings) "Many physical players have
settings to prevent discs from accessing the Internet for privacy
reasons." If a device's documentation stated that the Internet would
never be accessed, and the observed behavior were that the Internet is
accessed, then there could be a CVE.
Finally, we do realize that:
http://www.openwall.com/lists/oss-security/2015/02/06/9
has different reports.
- --
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
iQIcBAEBCAAGBQJWHAB/AAoJEL54rhJi8gl5OBwQAIDWf0XgzoEaP62hk3ACMnQ1
d6kDh7QHkyCtqwcVAchfirOhGKaTX9mS0MOwxpIiCWAkc51RlK5TjfHk5YByNV9v
TM3cyvfDMmVt0R9hUDZD3OUucJTya/WHWXoKczk/Wt0J7zkSuk8oQn95beLqVSAJ
qs+jFOzBnLyrlx+nZFDxWV+TpelFrhYROdfRTHDQdi6VlcK6qbtOwNO+0AADlO4K
zjbYvNc0PxzC5bO5h1L4rlLBAVVo03IB1lD8b4QfC8dEMgFklj7oN7lGaK+LDCpq
m0eg5rAz3MGhuvTK43TIuRX/32poxbC+o6DX5Cye1mcQGmCFcIXtF11fZl4cdQsg
m2QhrobnUZwDTMHuRTfLhuYKtja95f+/AnDFANBp38jaufGidP8a+OlR2IYcLVjr
E7kI9eznmS5pKp2fCJIGkP4TE++vJoxoTa5PUnqFGJJgRHINTaUJ+qkhh/NjviEJ
P8FxcoyHw06dNVg9HhK433mUtSH0VTMrxbgNA61Yvn6SyZEy76Fsa3Iozdszyl5n
n8jB5/kQuolYKyx/Cwmw1XtWoOdzEU1ccglSwaRDcC30Wwpuca19lGhFjspYY347
raexxjVy7NF++G631T6bY2loNaLIcAds7bmFPzo9KEG3WBPADrIG9VeMCFqSjBLr
bsYTn+migyn5VAM7KUtt
=HNXo
-----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.
