From ${URL}: 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. From http://www.openwall.com/lists/oss-security/2015/10/12/7 : 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. ... 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. ### At least libblueray 0.6.2 ebuild is still in tree which enable bdjava when java use flag is specified, and as such is vulnerable to this.
All versions in tree are vulnerable. Please advise on how the maintainer or project would like to proceed. This may require removing functionality from the user in a multilib environment.
I am tending to close this as resolved:invalid. Reasons: 1) We don't enable BD-J support per default. The user has to manually enable that feature (that's why I am downgrading from B to C). 2) Users who enabled BD-J support should have known how BD-J works (i.e. that BD-J is basically executing arbitrary JAVA files from unknown sources). There's no reason to expect the feature uses some kind of sandboxing. So having some kind of sandboxing is more like a feature request, see http://www.openwall.com/lists/oss-security/2015/10/12/7 3) So for me this isn't a security bug, therefore closing as "invalid" is the only applicable status for me.
Agree with Thomas.
