| Summary: | <media-libs/libbluray-0.8.1: Missing Java Security Manager sandboxing mechanism / feature in the org.videolan.BDJLoader class | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Kristian Fiskerstrand (RETIRED) <k_f> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | media-video |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://www.openwall.com/lists/oss-security/2015/02/23/7 | ||
| Whiteboard: | C2 [noglsa] | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 604636 | ||
| Bug Blocks: | |||
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. |
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.