Juergen Keil
2002-10-19 18:52:58 UTC
Hi,
With the release of Solaris 9, a change in the solaris "vol" driver was
introduced, that is supposed to fix a security vulnerability: A user
without root credentials isn't able any more to execute SCSI commands
from userland using the USCSICMD ioctl on a "vol" device
("/vol/dev/aliases/cdrom0" for example).
This breaks the libdvdread / libdvdcss combo used for playback of
encrypted video dvds in xine and mplayer (probably videolan / ogle
as well).
On Solaris 9, you now have to run these player applications as "root"
for DVD playback. Of cause, that's not a nice and ideal solution.
A usenet thread discussing the problem can be found here:
http://groups.google.de/groups?threadm=wyvg45125q.fsf%40tools.de&rnum=1
See also Sun BugID 4317053 for this issue (for those with sunsolve
access).
Is anyone working on this problem already?
At this time I see two possible ways to fix this:
Idea 1:
=======
The solaris removable media manger software runs "rmmount" whenever
media is inserted / removed from a drive. "rmmount" runs as "root"
(because it's main job is to mount/unmount filesystems found on the
removable media), and "rmmount" can be extended using shared libraries.
So, a way to fix the issue would be to write an "rmmount" "action"
shared library for solaris, that identifies an encrypted dvd video disk
on media insertion. This "rmmount" action library could perform the dvd
disk authentication, extract all all title keys from the disk and save
the keys to a file on disk.
Later, when a non-root user runs a DVD player, the title key cache on
disk would be checked and if found, it's contents would be used to
initialize libdvdcss's internal title key cache.
Problems I see with this idea: libdvdcss has no support to extract
*all* title keys from a disc in advance; dvdread, on the other hand,
already contains code to fill libdvdcss's title key cache (by trying to
open all *.VOB files on the video dvd). But dvdcss has no API to get
at the title keys, or to prime libdvdcss's internal cache. For that
reason libdvdcss's API must be extended, for example with two new
subroutines:
/*
* returns a a poiner to an opaque memory block in |cache|, of |cache_len|
* bytes, containing some representation of libdvdcss's internal title key
* cache. This data can be used in a subsequent |dvdcss_set_titlekey_cache|
* call to prime a dvdcss_t object's title key cache.
*
* Caller is responsible for freeing the memory returned via the
* |cache| output parameter.
*/
int dvdcss_get_titlekey_cache( dvdcss_t dvdcss,
void **cache, int *cache_len );
/*
* Prime |dvdcss|'s title key cache with the data from |cache|, which
* was obtained by a previous |dvdcss_get_titlekey_cache| call.
*/
int dvdcss_set_titlekey_cache( dvdcss_t dvdcss, void *cache );
libdvdread (i.e. a solaris rmmount action library added to libdvdread)
could then use these subroutines to "externalize" the title key cache,
and to restore the cache on a subsequent "DVDOpen".
MPlayer already comes with a similar "on disk" cache feature for the
title keys, and could probably be changed to use this new API as
well.
Idea 2:
=======
Just move the USCSICMD ioctls into a separate setuid-root process, and
add code to libdvdcss's ioctl.c file to use that new setuid-root
process to perform the USCSICMDs for drive authentication and title key
access.
The libdvdcss.so library could use pipes (or maybe "door"s on solaris)
to talk to the setuid-root program. Some internal protocol would be
used to pass requests and results between the dvdcss library and the
setuid-root program.
Other ideas?
Does anyone know if other platforms suffer from the same problem?
(It seems HPUX requires root permission or write access, so this
could be a problem on HPUX as well)
With the release of Solaris 9, a change in the solaris "vol" driver was
introduced, that is supposed to fix a security vulnerability: A user
without root credentials isn't able any more to execute SCSI commands
from userland using the USCSICMD ioctl on a "vol" device
("/vol/dev/aliases/cdrom0" for example).
This breaks the libdvdread / libdvdcss combo used for playback of
encrypted video dvds in xine and mplayer (probably videolan / ogle
as well).
On Solaris 9, you now have to run these player applications as "root"
for DVD playback. Of cause, that's not a nice and ideal solution.
A usenet thread discussing the problem can be found here:
http://groups.google.de/groups?threadm=wyvg45125q.fsf%40tools.de&rnum=1
See also Sun BugID 4317053 for this issue (for those with sunsolve
access).
Is anyone working on this problem already?
At this time I see two possible ways to fix this:
Idea 1:
=======
The solaris removable media manger software runs "rmmount" whenever
media is inserted / removed from a drive. "rmmount" runs as "root"
(because it's main job is to mount/unmount filesystems found on the
removable media), and "rmmount" can be extended using shared libraries.
So, a way to fix the issue would be to write an "rmmount" "action"
shared library for solaris, that identifies an encrypted dvd video disk
on media insertion. This "rmmount" action library could perform the dvd
disk authentication, extract all all title keys from the disk and save
the keys to a file on disk.
Later, when a non-root user runs a DVD player, the title key cache on
disk would be checked and if found, it's contents would be used to
initialize libdvdcss's internal title key cache.
Problems I see with this idea: libdvdcss has no support to extract
*all* title keys from a disc in advance; dvdread, on the other hand,
already contains code to fill libdvdcss's title key cache (by trying to
open all *.VOB files on the video dvd). But dvdcss has no API to get
at the title keys, or to prime libdvdcss's internal cache. For that
reason libdvdcss's API must be extended, for example with two new
subroutines:
/*
* returns a a poiner to an opaque memory block in |cache|, of |cache_len|
* bytes, containing some representation of libdvdcss's internal title key
* cache. This data can be used in a subsequent |dvdcss_set_titlekey_cache|
* call to prime a dvdcss_t object's title key cache.
*
* Caller is responsible for freeing the memory returned via the
* |cache| output parameter.
*/
int dvdcss_get_titlekey_cache( dvdcss_t dvdcss,
void **cache, int *cache_len );
/*
* Prime |dvdcss|'s title key cache with the data from |cache|, which
* was obtained by a previous |dvdcss_get_titlekey_cache| call.
*/
int dvdcss_set_titlekey_cache( dvdcss_t dvdcss, void *cache );
libdvdread (i.e. a solaris rmmount action library added to libdvdread)
could then use these subroutines to "externalize" the title key cache,
and to restore the cache on a subsequent "DVDOpen".
MPlayer already comes with a similar "on disk" cache feature for the
title keys, and could probably be changed to use this new API as
well.
Idea 2:
=======
Just move the USCSICMD ioctls into a separate setuid-root process, and
add code to libdvdcss's ioctl.c file to use that new setuid-root
process to perform the USCSICMDs for drive authentication and title key
access.
The libdvdcss.so library could use pipes (or maybe "door"s on solaris)
to talk to the setuid-root program. Some internal protocol would be
used to pass requests and results between the dvdcss library and the
setuid-root program.
Other ideas?
Does anyone know if other platforms suffer from the same problem?
(It seems HPUX requires root permission or write access, so this
could be a problem on HPUX as well)
--
This is the libdvdcss-devel mailing-list, see http://www.videolan.org/libdvdcss/
To unsubscribe, please read http://www.videolan.org/lists.html
If you are in trouble, please contact <***@videolan.org>
This is the libdvdcss-devel mailing-list, see http://www.videolan.org/libdvdcss/
To unsubscribe, please read http://www.videolan.org/lists.html
If you are in trouble, please contact <***@videolan.org>