There’s a nasty new security threat making waves on the web. Actually, clickjacking, as this attack is known, isn’t entirely new, but because no one has yet come up with an effective solution, it remains a serious threat. And clickjacking is the worst sort of security risk — it’s transparent to the unwitting user, simple to implement and difficult to stop.

The basic idea is that an attacker loads the content of an external site into the site you’re visiting, sets the external content to be invisible and then overlays the page you’re looking at. When you click a link you see on the current page, you are in fact clicking on the externally loaded page and about to load pretty much whatever the attacker wants.

To complicate matters, clickjacking is also a really cool, potentially effective user design tool. For an example of a benign case of clickjacking, consider the NoScript website, which uses the technique for positive ends.

NoScript is a Firefox plugin that stops JavaScript from running in your browser. The plugin is available through the Firefox add-ons site or through developer Giorgio Maone’s dedicated site. Now, as Firefox users know, when you try to load an add-on through a third-party site, the browser will block the attempt and show you a warning.

In the case of Maone’s site, it means an extra step is required for users to install the NoScript plugin. So Maone simply loads the Firefox add-on page in an iFrame, sets the content of the iFrame to visible:0 and then positions the frame over his own download button. The result is that while the user thinks they are clicking the download button on the current page, they are in fact clicking the download button from the Firefox add-ons page.

Because the Firefox add-ons page is a trusted source, Firefox doesn’t block the download, and users are able to get the plugin installed in a single click. While you could argue that this is still somewhat sneaky, it does make for a better UI experience on Maone’s site.

However, it isn’t hard to see how this could be used for much more nefarious ends. And it’s worth pointing out that an iFrame isn’t the only means of attack, clickjacking can work by loading Flash files, Silverlight, Java and more. To make matters worse, using JavaScript, an attacker could make the invisible target constantly follow the mouse pointer, intercepting a user’s first click no matter where it happens on the current page.

Developer Mark Pilgrim, who has been blogging over at the WHATWG blog, recently posted about clickjacking and outlines a number of possible solutions, none of which is ideal. One option would be to add a cross-domain permissions setup similar to what Flash uses, but even that model has problems. As Pilgrim writes:

This last approach moves us down a slippery slope towards site security policies for IFRAMEs and embedded content, similar to the Flash security model that allows trusted sites to access cross-domain resources. In practice, Flash crossdomain.xml files have a number of problems, and such an approach would still only cover a fraction of the possible use cases.

In the end, there doesn’t appear to be a an easy, or even complete, solution to the issue. As we typically point out when it comes to injection threats, using Firefox with NoScript is one of the best solutions (though in this case, even that isn’t 100 percent). For those using other browsers, Maone recently posted some suggestions for protecting against clickjacking, but unfortunately the usability consequences are pretty severe.

It will require some changes on the part of browser manufacturers to defeat clickjacking, but so far there’s no consensus on how to solve the problem.

Thanks to an ingenious new strategy devised by researchers at University of California, Davis and Intel Corporation, computer network administrators might soon be able to mount effective, low-cost defenses against self-propagating infectious programs known as worms.

Many computers are already equipped with software that can detect when another computer is attempting to attack it. Yet the software usually cannot identify newly-minted worms that do not share features with earlier marauders. When network managers detect suspicious activity, they face a major dilemma, said Senthil Cheetancheri, who led efforts to develop the strategy. "The question is, 'Should I shut down the network and risk losing business for a couple of hours for what could be a false alarm, or should I keep it running and risk getting infected?'"

Cheetancheri, a graduate student in the Computer Security Laboratory at UC Davis when he did the work, has shown that the conundrum can be overcome by enabling computers to share information about anomalous activity. As signals come in from other machines in the network, each computer compiles the data to continually calculate the probability that a worm attack is underway. "One suspicious activity in a network with 100 computers can't tell you much," he said. "But when you see half a dozen activities and counting, you know that something's happening."

The second part of the strategy is an algorithm that weighs the cost of a computer being disconnected from the network against the cost of it being infected by a worm. Results of this ongoing process depend on the calculated probability of an attack, and vary from computer to computer depending on what the machine is used for. The algorithm triggers a toggle to disconnect the computer whenever the cost of infection outweighs the benefit of staying online, and vice versa.

The computer used by a person working with online sales, for example, might be disconnected only when the threat of an attack is virtually certain; the benefit she provides by continuing to work during false alarms far outweighs the cost of infection. On the other hand, a computer used by a copy writer who can complete various tasks offline might disconnect whenever the probability of an attack rises above even a very low level.

The study is published in "Recent Advances in Intrusion Detection, 2008," the proceedings of a symposium that was held in Cambridge, Mass., in September, 2008.

Other contributors to the study are John-Mark Agosta with Intel Corporation; Jeff Rowe, research scientist in the UC Davis Computer Security Laboratory; and UC Davis computer science professors Karl Levitt and Felix Wu.

Electronic implants that dispense medicines automatically or via a wireless medical network are on the horizon. Australian and US researchers warn of the security risks.

Many computers are already equipped with software that can detect when another computer is attempting to attack it. Yet the software usually cannot identify newly-minted worms that do not share features with earlier marauders. When network managers detect suspicious activity, they face a major dilemma, said Senthil Cheetancheri, who led efforts to develop the strategy. "The question is, 'Should I shut down the network and risk losing business for a couple of hours for what could be a false alarm, or should I keep it running and risk getting infected?'"

Cheetancheri, a graduate student in the Computer Security Laboratory at UC Davis when he did the work, has shown that the conundrum can be overcome by enabling computers to share information about anomalous activity. As signals come in from other machines in the network, each computer compiles the data to continually calculate the probability that a worm attack is underway. "One suspicious activity in a network with 100 computers can't tell you much," he said. "But when you see half a dozen activities and counting, you know that something's happening."

The second part of the strategy is an algorithm that weighs the cost of a computer being disconnected from the network against the cost of it being infected by a worm. Results of this ongoing process depend on the calculated probability of an attack, and vary from computer to computer depending on what the machine is used for. The algorithm triggers a toggle to disconnect the computer whenever the cost of infection outweighs the benefit of staying online, and vice versa.

The computer used by a person working with online sales, for example, might be disconnected only when the threat of an attack is virtually certain; the benefit she provides by continuing to work during false alarms far outweighs the cost of infection. On the other hand, a computer used by a copy writer who can complete various tasks offline might disconnect whenever the probability of an attack rises above even a very low level.

The study is published in "Recent Advances in Intrusion Detection, 2008," the proceedings of a symposium that was held in Cambridge, Mass., in September, 2008.

Other contributors to the study are John-Mark Agosta with Intel Corporation; Jeff Rowe, research scientist in the UC Davis Computer Security Laboratory; and UC Davis computer science professors Karl Levitt and Felix Wu.

One of the themes of Dan Brown’s The Da Vinci Code is the need to keep vital and sensitive information secure. Today, we take it for granted that most of our information is safe because it's encrypted. Every time we use a credit card, transfer money from our checking accounts -- or even chat on a cell phone -- our personal information is protected by a cryptographic system.

But the development of quantum computers threatens to shatter the security of current cryptographic systems used by businesses and banks around the world.

“We need to develop a new encryption system now, before our current systems -- such as RSA -- becomes instantly obsolete with the advent of the first quantum computer,” says Prof. Oded Regev at Tel Aviv University’s Blavatnik School of Computer Science. To accomplish that, Prof. Regev has proposed the first safe and efficient system believed to be secure against the massive computational power of quantum computers and backed by a mathematical proof of security.

Secure for Centuries

Prof. Regev stresses it is imperative that a new cryptographic system be developed and implemented as soon as possible. One reason is that current information, encrypted with RSA, could be retroactively hacked in the future, once quantum computers are available. That means that bank and other financial information, medical records, and even digital signatures could instantly become visible.

“You don’t want this information to remain secure for just 5 or 10 years until quantum computers are built,” says Prof. Regev. “You want it to be safe for the next century. We need to develop alternatives to RSA now, before it’s too late.”

New Cryptographic System

Cryptographic systems are used to transmit secure information such as bank and online transactions, and typically rely on the assumption that the factoring problem is difficult to solve. As a simplified example, if the number 3088433 were transmitted, an eavesdropper wouldn’t be able to tell that the number is derived from the factors 1583 and 1951. “Quantum computers can ‘magically’ break all of these factoring-based cryptographic systems, something that would take billions of years for current computers to accomplish,” Prof. Regev explains.

The current gold standard in encryption is the universally used RSA cryptosystem, which will be instantly broken once quantum computers are a reality -- an event predicted to happen as early as the next decade. To replace RSA in this new reality, Prof. Regev combined ideas from quantum computation with the research of other leaders in the field to create a system that is efficient enough to be practical for real-world applications.

Prof. Regev’s work was first announced in the ACM Symposium on Theory of Computing and will appear in the Journal of the Association for Computing Machinery. His work has now become the foundation for several other cryptographic systems developed by researchers from Stanford Research Institute, Stanford University, and MIT. Its potential real-world applications are extensive, ranging from banking transactions to eBay and other online auctions to digital signatures that can remain secure for centuries.

If you want to make sure your computer or server is not tricked into undertaking malicious or undesirable behavior, it’s not enough to keep bad code out of the system.

Two graduate students from UC San Diego’s computer science department—Erik Buchanan and Ryan Roemer (picture)—have just published work showing that the process of building bad programs from good code using “return-oriented programming” can be automated and that this vulnerability applies to RISC computer architectures and not just the x86 architecture (which includes the vast majority of personal computers).

Last year, UC San Diego computer science professor Hovav Shacham formally described how return-oriented programming could be used to force computers with the x86 architecture to behave maliciously without introducing any bad code into the system. However, the attack required painstaking construction by hand and appeared to rely a unique quirk of the x86 design.

This new automation and generalization work from graduate students and professors from UC San Diego’s Jacobs School of Engineering will be presented on October 28 at ACM’s Conference on Communications and Computer Security (CCS) 2008, one of the premier academic computer security conferences.

“Most computer security defenses are based on the notion that preventing the introduction of malicious code is sufficient to protect a computer. This assumption is at the core of trusted computing, anti-virus software, and various defenses like Intel and AMD’s no execute protections. There is a subtle fallacy in the logic, however: simply keeping out bad code is not sufficient to keep out bad computation,” said UC San Diego computer science professor Stefan Savage, an author on the CCS 2008 paper.

Return-oriented Programming

Return-oriented programming exploits start out like more familiar attacks on computers. The attacker takes advantage of a programming error in the target system to overwrite the runtime stack and divert program execution away from the path intended by the system’s designers. But instead of injecting outside code—the approach used in traditional malicious exploits—return-oriented programming enables attackers to create any kind of nasty computation or program by using just the existing code.

“You can create any kind of malicious program you can imagine—Turing complete functionality,” said Shacham.

For example, a user’s Web browser could be subverted to record passwords typed by the user or to send spam e-mail to all address book contacts, using only the code that makes up the browser itself.

“There is value in showing just how big of a potential problem return-oriented programming may turn out to be,” said computer science graduate student Erik Buchanan.

The term “return-oriented programming” describes the fact that the “good” instructions that can be strung together in order to build malicious programs need to end with a return command. The graduate students showed that the process of building these malicious programs from good code can be largely automated by grouping sets of instructions into “gadgets” and then abstracting much of the tedious work behind a programming language and compiler.

Imagine taking a 700 page book, picking and choosing words and phrases in no particular order and then assembling a 50 page story that has nothing to do with the original book. Return-oriented programming allows you to do something similar. Here the 700 page book is the code that makes up the system being attacked—for example, the standard C-language library libc—and the story is the malicious program the attacker wishes to have executed.

“We found that return-oriented programming poses a much more general vulnerability than people initially thought,” said computer science graduate student Ryan Roemer. He and Buchanan chose to study return-oriented programming for a class project after they heard Shacham outline a series of open questions in a guest lecture he gave in Savage’s computer security course last winter.

Living with Return-Oriented Programming

“The threat posed by return-oriented programming, across all architectures and systems, has negative implications for an entire class of security mechanisms: those that seek to prevent malicious computation by preventing the execution of malicious code,” the authors write in their CCS 2008 paper.

For instance, Intel and AMD have implemented security functionality into their chips (NX/XD) that prevents code from being executed from certain memory regions. Operating systems in turn use these features to prevent input data from being executed as code (e.g., Microsoft’s Data Execution Prevention feature introduced in Windows XP SP2). The new research from UC San Diego, however, highlights an entire class of exploits that would not be stopped by these security measures since no malicious code is actually executed. Instead, the stack is “hijacked” and forced to run good code in bad ways.

“We have demonstrated that return-oriented exploits are practical to write, as the complexity of gadget combination is abstracted behind a programming language and compiler. Finally, we argue that this approach provides a simple bypass for the vast majority of exploitation mitigations in use today,” the computer scientists write.

The authors outline a series of approaches to combat return-oriented programming. Eliminating vulnerabilities permitting control flow manipulation remains a high priority—as it has for 20 years. Other possibilities: hardware and software support for further constraining control flow and addressing the power of the return-oriented approach itself.

“Finally, if the approaches fail, we may be forced to abandon the convenient model that code is statically either good or bad, and instead focus on dynamically distinguishing whether a particular execution stream exhibits good or bad behavior,” the authors write.