In the world of computer security, the term attack surface refers to the depth of methods a hacker can use to exploit your system. If you write an application that has a single input that takes an integer value, it’s pretty easy to make that application secure. But if your application adds another interface that takes a jpeg image and renders it to the display, the attack surface has expanded to include the system’s jpeg renderer.
Rendering jpeg images might seem fairly benign today, but this wasn’t the case back in August 2005 when an Internet Explorer vulnerability in JPEG image rendering routines could allow an attacker to remotely execute arbitrary code on your computer. Rendering jpeg images is just the tip of the iceberg.
Recently attackers have used a Java vulnerability to compromise the computers of Facebook and Apple employees. Acrobat Reader has been exploited so many times that Adobe’s Acrobat engineering team is structured around responding to these exploits. Even the major browsers have been known to expose an exploit or two. With the work Armor5 has done across all major browsers and devices, we see how often these applications crash. Every crash is a potential exploit.
Then in 2003 Adobe introduced XML forms into Acrobat, sucking in an enormous code base that needed to be hardened as well. In 2006 3D rendering followed.
It’s an unfortunate reality that software has flaws. And as software grows, so does the attack surface. Addressing the attack surface issue was a major motivator for the founding of Armor5, as I discuss in my next post.
What’s an Attack Surface?