Client-side browser vulnerabilities, the ones that require the browser software on your computer to make a request to a web site hosting a malicious web page, are on a sharp rise. Sophos reports:

From January to the end of March, Sophos identified an average of 5,000 new infected webpages every day, indicating that this route to infection is becoming more popular with cybercriminals.


Not all of the infected websites were created by the hackers themselves. Sophos has found that the majority, 70 percent, were bonafide websites that were vulnerable to attack because they were unpatched, poorly coded or had not been maintained by their owners.

This means there are 3500 newly infected web pages a day that are on bonafide websites. Couple this with the fact that there are browser vulnerabilities where no patch is available that effect most users and you have to say the bad guys really are winning.

Understanding the attack scenario

It takes two to tango in this devastating exploit scenario. An attacker needs to find a vulnerable website and he needs to craft a browser exploit to plant on it. But the beauty of this attack from the attackers perspective is it is opportunistic and the odds are in his favor. Here are the ingredients:

    1. the set of website vulnerabilities that allows modification of content
    2. the set of bonafide websites unpatched for the modification vulnerabilities
    3. the set of browser flaws that allow attackers to execute code
    4. the set of browsers unpatched for the code execution vulnerabilities


The attacker just needs one ingredient from each set, 1-4, and he can compromise a client machine that visits the bonafide websites. Unless one of the ingredients above is completely eliminated the opportunistic nature of this attack makes it clear that there is always going to be a certain percentage of compromised machines.

So which is the best set above to eliminate? Number 1 doesn't seem like an easy target since there are many web servers and thousands of web applications, including custom web applications. Number 2 isn't a good plan because attackers could just host their own fake web site, which while not as dangerous is still a significant attack vector. Number 3 looks like a good set to eliminate. Even though browsers are very complex there is still only a handful of them which makes the code that needs to be secure reasonable. Number 4 doesn't solve the zero day problem or the problem where a patch hasn't been released by the vendor yet.

Attacking the root cause

We need to get on to solving number 3 in earnest. Vendors who supply browsers or plug-ins that extend browsers such as Apple Quicktime need to do a much better job of software security. You guys are the weak link in the chain for client systems. If client computers can be compromised, the internet security foundation crumbles.

There is some good news. We don't need to find every browser or browser plug-in vulnerability, just the ones that allow code to be downloaded and executed on the client. This is a big category but it is limited. If you look at MITRE's CWE there is only a certain set of root causes that have the consequence of remote command execution:

    1. CWE ID 77 Command Injection
    2. CWE ID 79 Cross-site scripting (XSS)
    3. CWE ID 88 Argument Injection or Modification
    4. CWE ID 121 Stack Overflow
    5. CWE ID 122 Heap overflow
    6. CWE ID 123 Write-what-where condition
    7. CWE ID 124 Boundary beginning violation ('buffer underwrite')
    8. CWE ID 128 Wrap-around error
    9. CWE ID 129 Unchecked array indexing
    10. CWE ID 132 Miscalculated null termination
    11. CWE ID 134 Format string vulnerability
    12. CWE ID 170 Improper Null Termination
    13. CWE ID 190 Integer overflow (wrap or wraparound)
    14. CWE ID 192 Integer coercion error
    15. CWE ID 196 Unsigned to signed conversion error
    16. CWE ID 252 Unchecked Return Value
    17. CWE ID 364 Signal handler race condition
    18. CWE ID 415 Double Free
    19. CWE ID 416 Use After Free
    20. CWE ID 426 Untrusted Search Path
    21. CWE ID 469 Improper pointer subtraction
    22. CWE ID 479 Unsafe function call from a signal handler
    23. CWE ID 590 Improperly Freeing Heap Memory


There are certainly more vulnerabilities that are specific to the designs of the browsers or plugins but this is a good start. Eliminate these and the bar has been significantly raised.

Apple, Mozilla, Microsoft, Opera and all the plug-in vendors, the client side browser vulnerability crisis is yours to solve. We need significantly less remote code execution vulnerabilities in your code.

About Chris Wysopal

Chris Wysopal, co-founder and CTO of Veracode, is recognized as an expert and a well-known speaker in the information security field. He has given keynotes at computer security events and has testified on Capitol Hill on the subjects of government computer security and how vulnerabilities are discovered in software. His opinions on Internet security are highly sought after and most major print and media outlets have featured stories on Mr. Wysopal and his work. At Veracode, Mr. Wysopal is responsible for the security analysis capabilities of Veracode technology.

Comments (2)

Andy | April 26, 2007 12:16 am


While I agree that tackling the browser security, there are really two different categories of attacks/vulnerabilities we're interested in that aren't represented in your taxonomy.

1. Attacks against the integrity of the client machine/environment
2. Attacks against the integrity of the browser itself

Category #1 problems are implementation problems. Category #2 problems are architectural problems.

Attacks against #1 are in a lot of ways easier to fix. Fixing them doesn't rely on any complicated understanding of HTML, Javascript, Java, browser security policy and whether it actually works, etc. Attacks that target these vulnerabilities are reasonably well understood, and while critical, they ought to be relatively straightforward to fix.

Attacks against the browser and its security model itself aren't going to be nearly as easy to fix. First we'd have to actually understand the browser security model, and then we'd need to invent a time machine to stop from ever making the mistakes we did in HTML+Javascript integration that allow most/all of the browser integrity attacks in the first place.

Solving #2 requires changes to the protocols and the overall architecture of the browser security model, which I don't expect to see soon.

cwysopal | April 26, 2007 9:34 am


I totally agree. I guess I didn't make it as clear in my posting. I think that my enumerated list of issues to find falls into your category #1. Your category #2 problems are specific to the design of the browser and what it is trying to do and I mention this :

"There are certainly more vulnerabilities that are specific to the designs of the browsers or plugins but this is a good start. Eliminate these and the bar has been significantly raised."

We are still in the mode of lots of category #1 bugs. You say they are typically easier to fix and I agree. But everyone with Quicktime installed and Java turned on is currently vulnerable and that is a category #1 problem. Let's not throw up our hands that since we can't fix #2 easily that we shouldn't fix #1.


Please Post Your Comments & Reviews

Your email address will not be published. Required fields are marked *

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.