Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Blu-ray Disc (BD-J) runs Java code calls XLets for menus and bonus feature functionality. Since the Blu-ray player's manufacturer doesn't trust the disc's code, it runs in a Java sandbox. XLet can render menus, use its own memory and talk to other apps. It cannot do things like read or write files to the hard drive and many other things.

A core component of the sandbox is the Security Manager. Whenever a sensitive operation is required on Java internal APIs, a privilege check is performed. If it's rejected, then the code fails.

The code describes two vulnerabilities. The first one has to do with a bypass of vulnerability 3 discussed here. The Security Manager performs a check to ensure that classes under com.sony.gemstack.org.dvb.io.ixc.IxcProxy cannot call invokeMethod. An attacker can write a subclass of the target class to perform this operation anyway. To fix this, the code now checks the call stack to see if the class is included or not.

There are still instances where this code needs to be triggered, requiring a whitelist of sorts. By calling allowed classes that call the invokeMethod, it's possible to perform the same attack. An attacker can extend IxcRegistryImpl and create a remote proxy for it. By calling bind at the privileged location, verification is not performed. This allows registering arbitrary classes, that shouldn't be possible.

The function com_sun_xlet_execute is called via a wrapper of remoteMethod in a doPrivileged block that is accessible to the sandbox. This can be used to overwrite important functions and objects within the runtime. They use this to create a custom security manager that does nothing. This leads to a complete sandbox escape. Neat!