Introduction
The recent security scare with the Apple Macintosh platform and its exposure to the Flashback malware was centered around the use of Java on this platform, rather than being targeted directly using native code. But there have been similar risks targeted at this platform but this time using the Adobe Flash runtime environment.
Previously the typical computer’s operating system, desktop-productivity software and default Web-browsing environment has been targeted by malware writers. This has been more so with software that is used by many people, like Microsoft’s Windows XP operating system and Internet Explorer Web browsers.
But Microsoft, Apple and the open-source community have been working lately on hardening their operating-system, desktop-productivity and Web-browsing software against malware. This has been done through releasing software patches that fix vulnerabilities as soon as they are discovered and having such patches delivered using automated software-maintenance systems like Windows Update.
So malware authors are now turning their arrows towards the multi-platform runtime environments like Oracle’s Java and Adobe’s Flash and Air environments. These typically have a runtime component that is user-installed on most computing platforms, or this component is rolled in to some computing platforms.
These runtime environments have appealed to mainstream software developers because they can create their software in a “write once, run anywhere” manner without needing to port the software to the different platforms they want to target. This situation also has appeal to malware authors due to the ability to target multiple platforms with little risk as well as finding that these runtime environments aren’t patched as rigorously as the operating systems.
One main problem – Java and how it is maintained on the Macintosh
The Java runtime environment used to be delivered with the Windows platform until 2004 due to a legal agreement between Sun and Microsoft regarding an anti-trust issue. Now Windows users pick up the runtime code from Oracle’s Java website now that Oracle have taken over the Java environment from Sun.
But Apple still delivers the Java runtime environment to their Macintosh users, either with the operating system until “Snow Leopard” or as a separate download from their Website for subsequent users.
For both platforms, the Java runtime survives operating-system updates, even major version upgrades. As well, it, like the Adobe Flash runtime, has to be updated separately.
Windows and Linux users still have the advantage of going to the Oracle Website to install and update the Java Website and they can set up the Java installer software to implement the latest version automatically or let them know of updated Java runtimes. But Apple don’t pass on new updates for the Java runtime to MacOS users as soon as Oracle release them.
What Apple should do is pass on the Java runtime updates as soon as Oracle releases these updates. This could be involving Apple ceding the management of the MacOS X Java runtime to Oracle and writing any necessary integration code to support co-ordinated maintenance of this runtime the the Macintosh platform.
What users can do with these runtime environments
Users can keep their runtime environments for Flash, Java, Adobe Air and other “write once, run-anywhere” platforms by looking for updates at the developer’s Website. They can also enable automatic deployment of critical updates to these environments through various options offered by the installer.
But do you need to keep any of these runtime environments on your regular computer? You could do without it but some vertical, enterprise and home software requires the use of these runtime environments. In some cases, some developers write parts of their software in native code for the platform the software is to run on while using “write once, run anywhere” code that works with these environments for other parts.
For example, YouTube, most browser-hosted games or file-transfer interfaces for Websites implement Adobe Flash Player while programs like OpenOffice, Adobe’s Creative Suite and some enterprise / vertical software require Java.
If you are not likely to running any programs that depend on a runtime environment regularly or can avoid needing that particular environment, you could avoid installing the environment at all to keep your computer secure and stable.
What can the industry do
Use of computer security software to protect against runtime-environment attacks
A question that could be raised is whether it is feasible for a computer-security program to be written so that it can inspect the software that is intended to be run in these environments.
This is more so as these environments become ubiquitous for delivering software to multiple computing environments. In the case of Java, this environment is being implemented as a baseline for the Android platform and as the language for writing interactivity in to Blu-Ray Discs.
This could be achieved through the use of plug-in modules for current desktop and appliance-level security applications; or for modules that connect to the runtime environments, observing for abnormalities in the way they handle computer resources.
Development of enhanced runtime environments that work with the host operating system’s security logic
It can also be feasible for the runtime environments to work tightly with the operating-system’s user access management and prevent the programs that work behind them from using resources unless they are explicitly allowed to. This could involve use of sandboxes or privilege levels that mimic the operating system’s privilege levels thus working at the lowest level unless they have to work higher.
Consistent and responsive updating of the runtime environment across all platforms
Adobe, Oracle and others who develop “write-once, run-anywhere” platforms could implement a consistent and responsive update policy for these platforms in response to any discovered bug or exploitable software weakness. The developers of these platforms have to be sure that the updates are delivered as soon as possible and across all platforms that the runtime environment is targeted at.
This includes development of a strategy so that access to the targeted platforms is guaranteed by the runtime-environment developer. For example, it may include immediate propagation of firmware updates for devices or the use of the developer’s own installation routines for all regular computing environments.
Allow design-time native-binary compiling for desktop Java
Another improvement that I would like to see is for software that is written in the Java language to be able to be compiled to native binary (.EXE) code during development. Here, this could allow a desktop-software project that has routines written in Java as well as routines written in other languages like C++ and targeted to one platform to be able to run quickly and securely on that platform.
It will then avoid the need to require the installation of the Java runtime when a program like Adobe’s Creative Suite software is deployed to the end user. It can also allow the developer to deliver the software to many platforms in a binary form that is native to each target platform, thus allowing for efficient use of system resources.
Conclusion
Once we adopt proper standards concerning the management and maintenance of “write-once, run-anywhere” software-development platforms and make them to the same standard as regular-computer operating systems, this can reduce the chance of these platforms being exploited by malware authors.
