Hacking via Accessible Interpreters

Your computer is threatened by interpreted code as well as machine code. And it is no longer just your files at risk -- even your mouse, microphone or keyboard can be hacked.

Computers march to the beat of more than one type of code. The CPU defines the machine language. But today most computers also run interpreters that execute different sorts of script or byte-codes. In addition to Java and C# byte codes, end-user machines may well also support Javascript, Perl, PHP, Python, Ruby and many others. Even Postscript and some image formats are interpreted. All of these become executable code if the right interpreter is available. And all can be dangerous. For example, Javascript recently has been shown to open cross-site scripting vulnerabilities. Javascript is vital to SOA or Web 2.0 implementations using the increasingly popular AJAX techniques. Flash, and CSS, in the right circumstances, facilitate Clickjacking, where a hacker can place an invisible link/button that stays under your mouse pointer as you browse a regular page. You may think you are clicking on a visible button or link that is part of the legitimate page, but the hack morphs your input into a click on something else entirely. These vulnerabilities are often not limited to one operating system. Critical vulnerabilities in Adobe's Flash interpreter can be triggered from within Adobe's Acrobat pdf reader. The first such vulnerability affected Windows, Macintosh and Linux systems in mid 2009. Patches for the most recent Flash vulnerabilities as of this writing were published in June, 2012.

If we are to take seriously a taboo against transferring code, a course that security in the multicellular web world demands, we will need to be better at identifying such code. We must also take more care about allowing new interpreters to be installed. If we can do so, we can perhaps have a strict taboo only against transferring executable machine code while allowing access to interpreted code.

Reexamining "Access Privileges"

Interpreters are dangerous in large part because they may allow unfettered access to the OS’s API set, ActiveX controls, disk storage, the TCP/IP stack, the keyboard, the screen or even the PC's microphone or video camera. All of these can provide exposure to misuse by malware. Access to disk storage would seem too mundane to notice with all the other issues in front of us. But browser cookies and Flash ActionScript Supercookies store data about your browsing on your hard drive. That data, when retrieved later, allows websites to track and often to identify you on the Web (and are not neutered by "Private Browsing"). Trickier uses of the Flash supercookie capability (known as Local Shared Objects, or LSOs) were shown at the 2010 Black Hat conference to potentially allow the complete takeover of your machine.

Access to the TCP/IP stack enables the machine to replicate worms and be hijacked to implement zombie DDoS and other denial of service attacks. Access to the keyboard enables spyware to sniff passwords and credit card numbers as they are typed. Ability to write to the screen can enable phishing or spoofing. Access to the microphone can enable a browser application to capture sounds in the room. For example, Google has experimented with determining what TV shows the user is watching from snippets of the sound captured by the microphone. Access to the video camera opens the possibility of identifying the user's keystrokes by visually tracking finger movements and conceivably may even allow the attacker to read data on the screen in reflections from the users glasses or some other nearby reflective surface.

In the single-cell computing world, the machine's hardware and software facilities were assumed to be under the control of the local user of the machine. In a multicellular world, they can too easily become extensions of a remote multicellular system without our knowledge or consent. We must therefore improve our ability to control (or neuter) interpreters so their behavior cannot compromise the computer. One approach might be to provide better low-level access protection or permission facilities. The familiar Unix “permission” structure, in which applications and users have predefined permission to read, write or execute files, was designed to protect a single-cell world where the disk was the central, key resource. From a multicellular computing perspective, communication traffic between computers and between the computer and its user, not management of its file system, will usually be the most important task the computer does. Hence communication between machines (e.g., TCP/IP) and with the user (keyboard, mouse, screen, microphone and video) should be controlled with a revamped permission structure appropriate to modern attacks on networked computers.

Contact: sburbeck at mindspring.com
Last revised 6/12/2012