Side-channel attack

I learned a new term the other day: Side-channel attack

While the term was new to me, the concept I was familiar with. It made me remember one of the smaller problems on Java applet security I had studied.

Untrusted applets have limited rights. There are lots of things they can't do. However, there is a ton of information about the execution environment that the applet does have access to, such as: Memory utilization, timing information, etc.

Consider, for example the method freeMemory of the Runtime class. The method can be called from an applet. Basically this method tells you how much free memory there is in the JVM. Garbage-collector and threads complicate, but basically you can use it find out how much memory a piece of code used. You'd do this by calling freeMemory before a block of code, and then immediately after the block of code, hoping the garbage collector didn't run and no other thread created objects, etc.

Consider now, a piece of privileged system code that you can execute, but it's been carefully crafted not to leak any privileged information to you.

But, in some cases, even the path that the code traverses is privileged information. You have no easy way to find out the path in a sandbox environment, but memory and timing information could be enough for a really good approximation.

Let's see a practical example:

import java.applet.Applet;
import java.util.TimeZone;

public class TZlet extends Applet {
 public void start() {

     for (int i=0; i < 1000; i++) {

         long frees = Runtime.getRuntime().freeMemory();

         TimeZone tz = TimeZone.getTimeZone("../../../../../../WINDOWS/notepad.exe");
         long freee = Runtime.getRuntime().freeMemory();

         System.out.println(frees-freee);
     }
 }

}

The getTimeZone method of the TimeZone class takes a String ID of a timezone. But, if there is no TimeZone object cached with the given ID, it reads and tries to parse a file named ID in java.home/lib/zi. So if we pass the ID "foo", it'll try to open java.home/lib/zi/foo, read the whole file into memory and then try to parse it.

From the example above, you might have guessed that it just concatenates the ID to a String which represents the path to the zi folder and does no sanity check for the ID. So we can pass ../../... until we get to the root of the drive and then put any path we please. In the case of the example: notepad.exe.

The parsing will most probably fail if you're not pointing to a zoneinfo file, so nothing useful will ever ever be returned from the method. But judging from how much memory was allocated, you can get a good approximation of the file size and test for file existence.