j2me

Today Hongli pointed me to an OSNews op-ed on whether UNIX gives security against spyware, as many people unfortunately claim it does. The conclusion is that it does not provide any useful security against malicious software, which is no news to anybody in the autopackage project as we’ve been discussing these issues on and off for a long time.

It turned into a long discussion over operating system usability, Linux on the desktop and how to design a spyware-proof OS. I’ve lately become a big fan of the [J2ME approach](http://java.sun.com/j2me/index.jsp) to platform security and we talked a bit about how practical it would be if implemented on a generic PC. I think it’s worth discussing these things, but I can’t put the whole discussion here. Instead I’ll summarise how exactly what J2ME platform security is and how it works.

## java gets it right, at last

J2ME is *Java 2 Mobile Edition*, a nearly de-facto standard (in Europe at least) for extending your mobile phone with downloadable applications. Usually these are little games but they can be anything from media players to IM programs. Nearly every modern consumer phone supports Java although I have no idea how widely it’s used. I suspect at some point somebody will produce a killer app that everybody just has to have on their phone, after all, the potential of a mobile internet-connected camera-enabled computer is just too huge to ignore.

J2ME is in fact an open specification, and although Sun provide a Java implementation that they license to phone manufacturers there’s no obligation to use it. All you have to do is implement the Java APIs and standards. At least that’s the theory – in practice mobile phones are usually quite buggy and the “write once, debug everywhere” mantra holds here just as much as on the desktop. But today is not about slagging off Java, I do that enough the rest of the time. Today is a time to talk about the security system it has, and why it’s cool.

NB: I’m going to talk about J2ME as it’s implemented in my own phone, a Sony Ericsson W800i walkman phone that I bought last September. It’s pretty new, has a generally excellent implementation of Java and as phones go has a stylish and easy to use interface. So we’re looking at close to the best case scenario for this sort of technology.

## why it’s cool

Put simply, it works. Java phones are everywhere. Worldwide, they probably outnumber PCs by now as they often have high penetration in developing countries where desktop computers do not. There are over 700 million Java enabled phones in the world now. Walk down the street in any large western city and you’ll walk past people with programmable, internet-connected radios that support micro-payments (people can charge you for sending them text messages, and Java programs can trigger SMS transmission). You’d think this would have turned into a security disaster zone by now, wouldn’t you? Yet it has not.

Why is this? How have the mobile phone manufacturers managed to produce an incredibly enticing platform for criminals (it’s easier to simply drain users bank accounts with a mobile virus than a PC virus) yet keep it secure? And what lessons can we in desktop land learn from this?

(NB: The Cabir virus is not a J2ME virus so we won’t consider it here – being mobile doesn’t mean your phone necessarily gets this right, but some do!).

## how it works

J2ME platform security is enforced via several different mechanisms:

* Type security/bytecode verification
* Interpretive installation
* Handle security
* On-demand granting of priviledges
* Code signing
* Tracable effects

Type security means that in Java you can’t access objects you don’t have a reference to, because there’s no pointer arithmetic. This means the API the program can access is defined entirely by the objects it can access, which can be precisely controlled. Contrast this with C++ in which security must be enforced by hardware, as C++ code can do anything within its address space (including manufacturing other code, making static analysis worthless).

Note that type security doesn’t imply a just in time compiler – my W800i phone actually runs Java bytecode directly on the chip, as Sony have licensed [ARM Jazelle](http://www.arm.com/products/esd/jazelle_home.html) which means the hardware can run JVM opcodes just like its own native instruction set. The VM is still present to provide garbage collection and interfacing the Java code with the phones native OS (written in C++), but it doesn’t run the software itself.

## interpretive installation

Interpretive installation is a term I just made up for the system in which software does not have an active installer, instead the package is read by the OS and all integration is done by parsing metadata from the package. Linux RPMs/DEBs aren’t like this, because they can contain scripts that run with maximum priviledges – they have to allow this as the entire OS is managed by the same system as apps. MacOS X bundles *are* like this, but MacOS doesn’t require that apps are distributed this way, and even provides a crude installer/package type service for programs to use. Apples own apps often don’t use bundle installation directly. Worse, the implementation in OS X turned into a security hole when an over-eager LaunchServices started integrating packages that a web page download had triggered.

In my own phone, you can install software directly from the web, but unlike OS X there’s no service sniffing out software in the background. If you want to use a program, you must install it from the JAR file first. JARs are just zips that contain special files in certain locations, and the installation process is simply extracting it to some private location within the phones filing system. I do not know where this is on my phone, because neither users nor apps have access to it. But this system is the only one, and it has some important consequences:

* You cannot make a program that does not appear in the menu, and therefore, which the user does not know exists
* You cannot make it hard to uninstall your application like Windows/Linux/Mac apps can.
* Whilst JARs can define “hooks” into the OS, so it gets called when a text message that matches a certain pattern arrives for instance, these hooks are acted upon by the OS deliberately. The same task in Windows would be done by editing the registry which the OS may use itself for internal tasks, meaning Windows cannot reason about the correct contents of that registry key. Because there’s a clean and hard OS/app divide in J2ME that problem doesn’t exist.

The process of installing software is simple enough – open a URL in the phones web browser, or click a link, to a JAD descriptor file. This just contains some simple metadata about the app and a URL to the actual JAR file. On opening a JAD file, the phones operating system says “Do you want to install FooApp?”, and if you click yes, it will download and install it. It then asks if you want to run it. You can also install JAR files directly from the phones filesystem (ie via bluetooth or PC upload). So this isn’t quite like the OS X system, because there is an explicit install step, but it’s close.

## handle security

Handle security is another term I just made up. It means that rather than accessing a resource directly, you ask for a handle to that resource, which you then use to perform operations on that resource. The handle limits your access to it. It’s a simple idea that’s well implemented:

* J2ME apps, by default, cannot access the whole phone book. But they *can* access individual records – to get one, you have to put a magic widget onto a form that when clicked by the user gives the phone book user interface. They select the person, and then the app has access to that persons information alone. In a PC you’d have to use RPC to implement this, type security makes the underlying implementation irrelevant.
* The same principle is applied to the file system. By default J2ME apps cannot read or write users files, but they have their own private database. They can access individual files by using an OS-provided file picker. This mechanism was later extended so apps can read/write to their own private filestore and, when granted the right permission by the user, can read/write to the users filestore as well. At no point can the app ever access the operating system filestore (though it does exist).

This idea has a lot of mileage in it. Hongli asked how to stop a program popping up a message box saying “Please enter your email address and password”. Firstly, in J2ME the operating system is allowed to do things that the apps cannot – in my phone this means using slick OS X style transitions and visual effects. I can’t make a window that looks like the OS one, but I *can* ask the OS to display a message for me. As it happens, my phone cannot multi-task, but if it could the OS could therefore ensure a message boxs origin could always be identified allowing the user to make sane trust decisions.

But how to stop a potentially untrusted email program from knowing your login details? Handle security can be used again – the email program can ask a trusted OS component for an authenticated IMAP connection. The component gets the password from the user, or alternatively, a private keychain that the user already gained access to, connects to the IMAP server, sends the authentication details and then hands the connection over to the app. Because in most protocols there’s no way to get the password back in the clear once you authenticated this is a simple and secure way of letting people run email programs they may not trust with their login details.

Likewise, for sending mail apps can be preventing from using their own SMTP engine as some viruses do by blocking them from making outgoing connections on port 25 and requiring that they obtain a pre-setup connection from some other OS component.

Essentially, handle security lets you hide a potentially sensitive operation behind a trusted “safe for scripting” barrier.

## on demand granting of privs

I covered this in a previous entry. It’s annoying for the end user, so IIRC signed apps don’t generate these prompts and instead get the set of privs they need granted at startup. But you don’t need to get your app signed to write J2ME apps if you’re OK with it prompting the user to allow net access. Some phones can remember trust decisions – mine for some reason cannot (bug in the phone? there is ui for changing it…).

## code signing

This is something like the “last resort” of security. Ultimately, having another human figure out if software is bad or good is going to be the most reliable way to do things, but the scalability issues and centralisation it introduces is why most vendors have shied away from requiring mandatory code signing.

## tracable effects

This just means that there’s no way for a program to pretend to be another program. Firewalls like ZoneAlarm offer a feature whereby you individually grant apps net access, but this feature is worthless because any app can choose the name it appears as. There’s no correlation between any given EXE and where it came from either, so there’s no way for the user to know that the trojan calling itself “Windows Plug and Play Services” was in fact installed via an Internet Explorer exploit and not via an explicit action on their part.

J2ME prevents this, as any piece of running code can be traced back to the application in the apps menu that started it. As a result you can’t pretend to be somebody you’re not (because you can’t know what the OS UI looks like anyway even if you could draw fake windows).

## conclusion

I have no idea if the J2ME model could be applied “as is” to existing desktop systems. I talked with Hongli a bit about the problem of legacy apps and we concluded that this was a totally solvable problem – bigger issues are whether granting privileges scales and whether code signing eliminates smaller organisations from the game. A lot of J2ME security relies on the fact that Java is a safe language, but most desktop software is written in C++ which is not. FastRPC, my dissertation project, is about solving this problem in an efficient and easy to use way.