Most system administrators didn’t know it, but they couldn’t be sure what program would run when they entered a command. By naming my malicious program the same as a common utility that I knew a system administrator would run, and strategically placing the program in the right directory, I could get the system administrator to run my malicious code. With this approach you can convert a vulnerability that lets you create a file on the system into full system control.

Before web browsers and even before the graphical user interface, a computer’s user interface (UI) was a command line. With a command-line UI, the user types a text string into the command shell and the shell performs the operation.

For example, when the user types in mail, the shell searches the path -- which is a list of file directories -- for a file named “mail” and then executes it with the privileges of the user. If an attacker, however, can get their commands into a file named “mail”, that the command shell finds before it finds the real mail program, the attacker’s commands will get executed.

The attack works because most operating systems let users write files to directories and folders that contain executables. For example, in the days of the command-line user, an attacker could embed a malicious file named “mail” in a TAR archive and hope that the user would extract it to a place the command shell will find it. If the user changed their current working directory to the location of the malicious “mail” file and then reads their mail, the attacker would own the box.

Clickjacking is a modern twist on the old con. Users need to trust a Web browser’s user interface (UI) in order to correctly issue commands to the computer. If the UI is untrusted, then a malicious actor can trick the user into issuing commands on the actor’s behalf. This problem isn't going away any time soon, but designers can at least up the ante in this new twist on an old cat-and-mouse game.

Imagine an attacker being able to set up a malicious website, or compromising a trusted website, and getting a button to appear that is a actually a button on a banking site or a shopping site but the victim can’t actually see the button because it hovers invisibly below the attacker-generated UI. When the victim clicks on the attacker’s UI he is really clicking on his bank’s website. He just doesn’t know it, because he can’t trust what he sees.

Graphical user interfaces (GUIs) have just changed the details of the attack, not the concepts. Instead of creating a malicious file with a particular name and placing it along the search path, an attacker creates an icon that looks like a document file and tricks the user into clicking on it. Instead of opening a file, the user could end up installing bot software or a keylogger.

Operating systems have added features over the years to warn users that they are really executing code when they perform an action through the user interface and when executable code is not to be trusted.

This is only a partial solution. Trusted typically means not installed by the operating system’s manufacturer or signed by someone the manufacturer trusts. There are, however, plenty of untrusted executable programs that users install, because many users don’t really understand the importance of heeding the operating system’s warnings when they are not sure what their computer is doing. A solution in some cases has been to make the operating system or applications more restrictive. For example, Outlook will not allow you to detach an executable file or visual basic script sent to you.

Now, lets enter the world of the modern web browser, where the UI is largely controlled by a remote Web site that is likely not trusted, or could even be trusted but is compromised and sending malicious content. Modern web browsers have replicated the warnings of the operating system user interface to warn the user when he might be executing a file that is downloaded over the Web. The web interface, however, offers many more opportunities for an attacker to trick a user into issuing command on his behalf.

The untrusted Web site user interface is a much more serious security problem than an untrusted command line or untrusted operating system GUI. A user can simply stumble upon an untrusted website whereas for the untrusted command line or GUI, the attacker needs to get a file onto the user’s system. Moreover, the flexibility in building a Web site’s user interface gives the attacker a lot more possible vectors of attack.

Clickjacking isn’t going to go away any time soon. Every browser or plug-in that can display a flexible user interface will need to be made more restrictive. These programs shouldn’t permit the types of tricks that allow an attacker to fool the user into issuing commands on his behalf.

In the end, browser makers and plug-in developers need to find a way -- even if it inhibits design flexibility -- to let the user trust that what they see is what they will get.