Adobe’s Flash Player software is on 99 percent of Internet-connected desktops, offering up multimedia and video capabilities on a multitude of popular Web sites such as YouTube. But the Adobe Flash platform has been beset by a rash of security problems that give intruders potential access to computers running the software.
Issues have included one recent vulnerability described as “frighteningly bad” by a security expert. Technologists, however, disagree on the severity of Flash’s weaknesses. Some say Flash is merely a victim of its own success, attracting attention from those with bad intentions but being no worse off than other software platforms when it comes to its inherent security. An alternate opinion is that Adobe simply lacks tight security practices in its internal development procedure and so has become a preferred vector for cyberthieves.
A review of Flash-focused security incidents of late raises eyebrows:
- Just last week, Adobe issued a critical patch for both Flash and AIR; the fixed flaws included what Adobe called “a vulnerability in the parsing of JPEG data that could potentially lead to code execution.”
- Foreground Security in November detailed what one company official has described as a “frighteningly bad” security flaw in which an attacker can put a malicious Flash object on a Web site via user-generated content capabilities. Malicious scripts can then be executed.
- Adobe in July confirmed a Flash zero-day bug in its Flash and Reader software had a critical vulnerability on Windows, Macintosh, Linux, and Solaris operating systems that could cause a crash and enable an intruder to take control of a system. Product updates were issued to resolve the problem.
- Adobe also in July issued a patch for 12 vulnerabilities in Flash Player, 10 of which could lead to hijacked systems or hackers executing malware.
- Adobe in February released a bulletin about a potential vulnerability in Flash Player that could allow an attacker to take control of an affected system. The company issued a patch and advised users to upgrade their Flash Player software.
- In October 2008, Adobe warned of a Flash vulnerability that would let hackers use “clickjacking” attacks to secretly turn on a computer’s microphone and Web camera. That vulnerability was later fixed through an update.
Is Adobe immature when it comes to security?
Adobe, says Foreground CIO Mike Murray, suffers from immaturity in its software development processes: “Adobe is just big enough that its issues [are starting] to impact the whole Internet.”
“They haven’t yet developed the security discipline around their software,” although that is changing, he says. He contends that Adobe is only now coming to grips with the fact that its software’s popularity means it needs to be more security-conscious in development practices, noting that Microsoft had to come to the same realization several years back, which resulted in its Security Development Lifecycle processes.
As an example of Adobe’s security naivete, Foreground reported a nuanced issue in which hackers could exploit the Flash and ActionScript same-origin policy for domains, which limits code execution to the domain from which it originated. Through Flash, attackers could disguise malicious code, upload the code to a site, and enable it to steal a password or cause other problems, Murray says.
“[Adobe] could fix it if they changed the same-domain origin policy to be more restrictive, but many sites rely on the laxness of that policy,” Murray says. Thus, a fix could cause incompatibilities on Web sites.
Adobe says its security practices are up to snuff
Adobe rejects the notion that its internal security practices for software development are immature. “That’s flat-out wrong,” says Brad Arkin, Adobe’s director of product security and privacy. The company’s security practices are among the “most mature of any [software developer],” he says.
Adobe’s current approach to security, its Secure Product Lifecycle (SPLC) plan, has been in place since Adobe’s merger with Macromedia in 2005. “[SPLC] defines how we integrate software security into the way that we build software,” Arkin says.
Through SPLC, Adobe starts out a release by examining specifications in design for any potential security problems. Threat modeling and automated and manual code reviews are performed along with security testing, Arkin says. “In Flash Player, every code change and every new feature is evaluated for its security impact to the product,” he says.
“Adobe is vigilant in doing everything that we can to prevent any new vulnerabilities from being introduced and also [in] reacting swiftly to any vulnerabilities that are identified after we ship a product,” Arkin says. “A lot of our practices are similar to what Microsoft does.”
Adobe’s software is targeted by bad actors because it is deployed on so many PCs, Arkin says. The company, he notes, has had regularly scheduled security updates for Flash Player this year. And he says there have been no calamities associated with the security of Flash or Adobe’s Acrobat or Reader technologies.
Arkin downplays Foreground’s issue with the same-origin policy: “There’s nothing new. It’s not news. The same-origin policy is a standard model for Web security,” Arkin says. Allowing uploading of content to a site presents inherent risks, he notes: “If you allow somebody to upload code to your Web site, then it’s not your Web site anymore.”
That’s why Web developers need to make sure they have been careful in reducing risks when it comes to how their apps handle the uploading of “active content,” such as user-generated content, to a Web site. They should perform careful input validation to restrict the types of files that can be uploaded, Arkin says: “If anything is submitted outside the boundaries of what you’re expecting, you would reject it.”
Thomas Kristensen, CTO at security firm Secunia, agrees that the same-name origin issue is not a security flaw by a natural vulnerability. “It is by design, and it is expected for Flash to behave in this way,” he says, and to avoid the vulnerability means the Web site developers need to take the security responsibility, such as by allowing content to be uploaded only to a different domain than the primary one.
Web developers should make sure domain policies are being handled correctly and that their inputs and outputs are being dealt with properly if sensitive information is involved, says Brian Huntley, a Flash developer at Web development and services company WebEnertia.
Flash’s popularity makes it a favorite target
“I don’t know if anything we typically do in Flash is terribly worrisome because we’re generally not handling sensitive information with the Flash side of things, but if we were to, there’s definitely some vulnerability issues that are concerning,” Huntley says.
But “I don’t know if [Flash] is less secure” than any other software platform, Huntley says. Gartner analyst Ray Valdes concurs: “Flash has been around for many years. It’s on 800 million PCs, it’s on 98 percent of Internet-connected devices. Given all those numbers, I think its track record is actually very good in regard to security.”
Flash has the same issues as other software in regard to security, says Secunia’s Kristensen. “The problem with Flash, as well as for a lot of other software, is that there [are] some programming errors in it that can be exploited by the bad guys to conduct malicious actions on end-users’ PCs,” Kristensen says. These errors are what led to many of the Flash vulnerabilities seen this year, he notes.
Flash’s travails are the “nature of the beast,” says Dave Marcus, director of security research at McAfee, which works closely with Adobe. Anything getting a lot of play through a browser — such as the Flash plug-in — attracts the attention of those with bad intentions. “The code is really being strongly looked at by the underground,” Marcus says.
More frequent patching would lessen users’ risks
One way users and businesses can lessen the risks of falling victim to vulnerabilities in Flash is to update the software quickly once updates are released. Secunia’s Kristensen notes that many users wait weeks or months after a patch appears before applying it — leaving them unnecessarily vulnerable. By contrast, users and businesses typically apply Microsoft patches within a few days of their release. He suggests that businesses manage and patch Adobe software as they do Microsoft apps: “I see absolutely no excuse why you shouldn’t patch the day after the patch is released.”
“Adobe, much to its credit, is doing the right thing by going forward with a monthly patching schedule,” says WebEnertia’s Huntley. To adopt those patches quickly, WebEnertia installs code to check for the latest Flash versioning.
“I wouldn’t be overly concerned about running Flash in a corporate network,” says Secunia’s Kristensen—assuming Adobe’s security patches are quickly implemented and site developers appropriately deal with risks such as same-name origin through proper domain policies.
This article, “Adobe Flash’s security woes: How to protect yourself,” was originally published at InfoWorld.com. Follow the latest developments in security and application development at InfoWorld.com.