Fighting back against exploits

Data execution prevention (DEP) in isolation is weak and relatively easy to bypass, including Permanent DEP, the technology that helps secure Windows 7.

This is according to Dino Dai Zovi, an independent security researcher at Trail of Bits, speaking at the ITWeb Security Summit in Sandton, last week.

He said the exploits have been publicly talked and written about for at least three years. “A lot of things are by-passable; we just need to understand how we run applications on our computer.

“The way to design secure networks and secure applications is to think that anywhere the user can input data will have code executed against it.”

“You can't patch every vulnerability,” said Dai Zovi, adding that writing 100% bug-free code is impossible. He stated it should be assumed there will be code execution on a computer system.

“You can only make the exploitation more difficult. Each mitigation makes it more difficult to attack, which slowly takes out techniques that are no longer exploitable.” Dai Zovi said attackers then have to move on to the next level.

He mentioned that Windows XP service pack 2 was the first widespread operating system to incorporate mitigations for the exploitation of the OS. He added that Microsoft Vista further secured itself by implementing address layout randomisation (ASLR), which was first implemented in the PaX project for Linux.

Dai Zovi highlighted that there exists a lag between the exploitation technique and the fix in the software being spread. He noted that Windows XP had a four to five-year lag.

“Mitigations are additive, requiring the co-operation of the components in the OS.” Dai Zovi stated there are three mitigation areas that need to be worked on, and that the goal of software vendors should be to reside in the sweet spot between the mitigation areas.

He lists the mitigations as OS runtime mitigations, compiler mitigations, and application opt-in mitigations.

According to Dai Zovi, even if an application is thought to be safe, third-party plug-ins are usually the attack route for an exploit.

Dai Zovi said return-oriented programming requires the attacker to attack non-executable memory segments. Instead of overwriting return addresses to return into shellcode, it's returned to a loaded library to simulate a function call. Data from the attacker's controlled buffer on the stack are then used as the function's arguments.

He likened return-oriented programming to a ransom note cut out of letters from a magazine. “Rather than cutting out letters, you are cutting out instructions from text segments.

“First, the attacker must cause a stack pointer to point into attacker-controlled data.” He said this comes for free in a stack buffer overflow attack. “We can also exploit other vulnerabilities, such as heap overflows, which require a stack pivot sequence to point ESP into attack-data,” he added. “The attacker-controlled data contains the return-oriented exploit payload.”

Dai Zovi said these payloads may be 100% return-oriented programming or simply act as a temporary payload stage that ensures payload execution of a traditional machine-code payload.

”Return-oriented techniques are increasingly required to exploit vulnerabilities with non-executional data-memory protections.”

He noted a return-oriented payload can be developed to bypass permanent DEP, and bypassing DEP under ASLR requires at least one non-ASLR module, such as an unsecured third-party plug-in.

“Bypassing DEP under full ASLR requires an execution memory address disclosure vulnerability in addition to memory corruption,” explained Dai Zovi.

He said software vendors should not assume that DEP or ASLR makes applications unexploitable. “It is better to assume that all vulnerabilities yield full code execution. Rather restrict the actions performed by application components that parse and handle potentially untrusted data.”

Dai Zovi mentioned this can be accomplished by implementing privilege reduction, such as running under low integrity on Vista or Windows 7, or ensuring components run in sandboxed environments. He added virtualisation could become a key component in securing applications.

“Preventing malicious actions is more important than preventing malicious code,” Dai Zovi concluded.