One of the most common features of "secure development" is the ability to avoid functions that are known to be dangerous, functions which have caused major vulnerabilities (such as Internet worms) in the past. These are functions developed in the 1970s, before their risks were understood. Now that we have suffered from these functions and understand the risks, we have come up with safer alternatives. Using these alternatives are cheap and easy, and they can save a development house endless embarrassment and remediation time. More importantly, while verifying that your code is "secure" is an essentially impossible task, verifying that your code contains no banned functions is easy. We call this the "low hanging fruit" of secure development.
One such bad function is "strcat." It copies data from one area of memory into another. However, it does not check that the target memory is big enough. Strcat continues copying beyond the bounds of the target memory, overwriting other parts of memory. Hackers can manipulate the overwritten areas in just the right way to break into the machine. With 48,000 hits on Google for strcat vulnerabilities, some dating back more than a decade, this is a well known potential security issue.
So why doesn't Adobe fix its low hanging fruit? Why does it continue to use these toxic functions? It's strange, hardware vendors are removing hazardous substances (RoHS) from devices, but software vendors aren't being similarly diligent about cleaning up hazardous functions from old code. Errata Security provides a free tool known as "LookingGlass" that helps people see if their software is using these toxic functions. We ran it on Adobe Reader and found extensive use of these toxic functions back in 2008. LookingGlass can easily tell you if your software has these toxic functions, and quckly see what danger you are exposing yourself to. As of today, the danger from Adobe's software is still quite high.