Hacking via Accessible Interpreters

Even your video camera, microphone, mouse or keyboard can be hacked using rogue interpreted code.

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 accessible. All can be dangerous. For example, Javascript is vital to SOA or Web 2.0 implementations using the increasingly popular AJAX techniques.  But it may may open cross-site scripting vulnerabilities. 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. Many critical vulnerabilities in Adobe's Flash interpreter have been discovered since 2009. The most recent Flash vulnerability as of this writing was identified in April 2014.

Security in the multicellular web world may demand that we take seriously a taboo against transferring code. If so, 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 that effectively, we may only require a strict taboo against transferring executable machine code while allowing access to interpreted code.  So far, however, interpreted code, and additional interpreters have too many places in which to hide.

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 on your hard drive about your browsing. That data, when retrieved later, allows websites to track and often to identify you on the Web (and are not necessarily 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.

Read more on The Evolution of Computing


Last revised 5/25/2014