Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 12 Oct 2015 14:50:56 -0400 (EDT)
Subject: Re: CVE request: BD-J implementation in libbluray

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:;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). 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. 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).

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:

has different reports.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1


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.